[dev] dwm bug: mouse click not working on statusbar with Lithuanian keyboard layout
Hello. I have been using dwm for about two years and undergone many version changes, but one bug always persisted. I am using the following section in my xorg.conf to switch between English and Lithuanian keyboard layouts: Section "InputClass" Identifier"Keyboard0" MatchIsKeyboard "yes" Option"XkbLayout" "us,lt" Option"XkbOptions" "grp:caps_toggle,grp_led:num" EndSection Whenever I am using the Lithuanian keyboard layout, mouse click on statusbar does nothing. That is, tags do not change as well as window layouts when I click on respective places in statusbar. Everything else in dwm and X works normally. That's also a bit surprising, since dwm uses number keys to switch tags, and in Lithuanian layout numbers are replaced by special Lithuanian letters. Even so, keyboard shortcuts DO work, while mouse click on statusbar does not. Thanks for help, -- Julius
Re: [dev] dwm bug: mouse click not working on statusbar with Lithuanian keyboard layout
> Whenever I am using the Lithuanian keyboard layout, mouse click on > statusbar does nothing. Running xev I saw that when the grp_toggle is active, the button events report a mask of 8192 (instead of 0). So something like this helps: diff -r 5248279b9601 dwm.c --- a/dwm.c Tue Jun 14 05:51:21 2011 +0100 +++ b/dwm.c Wed Jun 15 11:22:26 2011 +0200 @@ -42,7 +42,7 @@ /* macros */ #define BUTTONMASK (ButtonPressMask|ButtonReleaseMask) -#define CLEANMASK(mask) (mask & ~(numlockmask|LockMask)) +#define CLEANMASK(mask) (mask & (ShiftMask|ControlMask|Mod1Mask|Mod2Mask|Mod3Mask|Mod4Mask|Mod5Mask)) #define INRECT(X,Y,RX,RY,RW,RH) ((X) >= (RX) && (X) < (RX) + (RW) && (Y) >= (RY) && (Y) < (RY) + (RH)) #define ISVISIBLE(C)((C->tags & C->mon->tagset[C->mon->seltags])) #define LENGTH(X) (sizeof X / sizeof X[0]) I couldn't find a #define in the X header files that would represent the 8192 mask. Using a list of expected masks breaks the numlockmask behavior somewhat, but I'm not sure what numlockmask tries to fix anyway. If it is important, one could use (mask & (ShiftMask|...|Mod5Mask) & ~numlockmask) -- Eckehard Berns
Re: [dev] Experimental editor
[2011-06-12 18:55] Martin Kühl > > [...] command-quasimode [...] > [...] mostly modeless. [2011-06-12 22:38] Connor Lane Smith > > For substitution I'm tempted to just add a keybind to switch to and > from the command pane, which appears at the bottom of the view > (`Quake-like', as Paul says). That means we can do this just with a > raw command, like vi does with `:'. > > So that's pretty much modeless, then. What's the difference between a mode and a ``quasimode''? Almost none! It appears as if you just *want* modes. ;-) I have followed this editor discussion, only reading. Still I wonder why you try so much to stay modeless. Modes are a real advantage because each mode offers a separate editor. Take vi: You can edit in normal mode (= the actual vi mode) or in ex mode or in insert mode (e.g. with ^W, ^U). You have the choice which editor (mode) you use for some editing task. Ed has modes, too: Command and insert mode. Surely, the problems are knowing in which mode you're in and switching modes. But in return, each mode lets you re-use your keyboard keys (the optimum) and for each mode you can design a new editor that's best suited for the kind of editing this mode is intended to do. Am I missing some big disadvantages of modes? I simply don't understand your strong dislike. meillo
Re: [dev] Experimental editor
> Still I wonder why you try so much to stay modeless. Modes are a real > advantage because each mode offers a separate editor. Take vi: You can > edit in normal mode (= the actual vi mode) or in ex mode or in insert > mode (e.g. with ^W, ^U). You have the choice which editor (mode) you > use for some editing task. Ed has modes, too: Command and insert mode. > > Surely, the problems are knowing in which mode you're in and switching > modes. But in return, each mode lets you re-use your keyboard keys > (the optimum) and for each mode you can design a new editor that's > best suited for the kind of editing this mode is intended to do. Why would you want several editors? The problem with vi and mutt is that they have all these keybindings; hence you can on occasion find yourself in some crazy dark key combination that you didn't mean to be in. A simple editor probably shouldn't have any more keybindings than, say, surf; in fact one or two less: page up/down, up/right/left/down, and find. One doesn't need modes for that. If you want to do something wacked out to your file (like go to the third word on the 4th sentence and delete every vowel), that should probably be done *outside* the editor. Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 1:12 PM, Peter John Hartman wrote: > A simple editor probably shouldn't have any more keybindings than, say, > surf; in fact one or two less: page up/down, up/right/left/down, and find. > One doesn't need modes for that. If you want to do something wacked out to > your file (like go to the third word on the 4th sentence and delete every > vowel), that should probably be done *outside* the editor. I've got a long comment queued up (restricted internet situation at work), but just to respond to the comment about moving stuff "outside the editor". One big disadvantage of doing everything "by hand" is that such stuff isn't in an undo history that you can execute. I tend to use undo a certain amount, mostly immediately (which could be simulated by just keeping one copy) but a reasonable amount undoing several sets of changes. -- cheers, dave tweed__ computer vision researcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dev] Experimental editor
On 15 June 2011 12:26, markus schnalke wrote: > What's the difference between a mode and a ``quasimode''? What's the difference between shift and caps lock? > Surely, the problems are knowing in which mode you're in and switching > modes. But in return, each mode lets you re-use your keyboard keys > (the optimum) and for each mode you can design a new editor that's > best suited for the kind of editing this mode is intended to do. This is the sort of argument, imo, which led to the modal soup that is emacs. I want there to be just a collection of buffers, and typing into command buffer is what gives you `command mode', sam style. We always use the same keys, because all we're doing is editing text, so it becomes muscle memory. On 15 June 2011 13:12, Peter John Hartman wrote: > Why would you want several editors? The problem with vi and mutt is that > they have all these keybindings; hence you can on occasion find yourself in > some crazy dark key combination that you didn't mean to be in. This. I want keys to always mean the same thing. Too often they don't, and you end up not knowing what on Earth is happening. With this approach, all you need to keep in mind is where your cursor is. On 15 June 2011 14:01, David Tweed wrote: > One big disadvantage of doing everything "by hand" is > that such stuff isn't in an undo history that you can execute. Yeah, this is one of the benefits of having a command buffer: the shell is just a special case of text editing. You can run editor commands, like mass selections, replacements, etc, and you can also call Unix commands with `!'. (`!sh' basically gives you a shell in your editor for free.) My view of that kind of editing is, you select the third word in the fourth sentence (either by leaping or with the mouse), hop over to the command buffer (Ctrl-Tab?), and run `x/[aeiou]/d'. If you want something weird like sorting a file, just use `|sort'. Thanks, cls
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 02:47:55PM +0100, Connor Lane Smith wrote: > My view of that kind of editing is, you select the third word in the > fourth sentence (either by leaping or with the mouse), hop over to the > command buffer (Ctrl-Tab?), and run `x/[aeiou]/d'. If you want > something weird like sorting a file, just use `|sort'. > > Thanks, > cls This makes sense. I love sam, but always wished there was a way to switch to the command window (~~sam~~) using the keyboard.
[dev] Re: Experimental editor
Josh Rickmar writes: > This makes sense. I love sam, but always wished there was a way to > switch to the command window (~~sam~~) using the keyboard. I think sam together with the "common" discussed keybindings (which are partly implemented in p9p already), up/down-cursor keys for line movement(!) and shift-cursor selection would be a very usable and powerful editor already. Next step would be to drop its windowing system and use X11 windows. I'd also kill for a console samterm. ;) -- Christian Neukirchenhttp://chneukirchen.org
[dev] [dwm] fullscreen apps losing focus
it's kinda annoying to lose focus in a fullscreen app if a new one is started in the background, eg: fullscreen mplayer running in `chat` tag. it's a bug or a feature!?
Re: [dev] Re: Experimental editor
On Wed, Jun 15, 2011 at 04:42:27PM +0200, Christian Neukirchen wrote: > Josh Rickmar writes: > > > This makes sense. I love sam, but always wished there was a way to > > switch to the command window (~~sam~~) using the keyboard. > > I think sam together with the "common" discussed keybindings (which are > partly implemented in p9p already), up/down-cursor keys for line > movement(!) and shift-cursor selection would be a very usable and powerful > editor already. > > Next step would be to drop its windowing system and use X11 windows. > > I'd also kill for a console samterm. ;) Why not just keep the underlying sam the same (sam -d) but write a different samterm for it which does one window per buffer? This would also make it easy to switch to any buffer you wanted since it would just be part of the window manger.
[dev] Re: Experimental editor
Josh Rickmar writes: > Why not just keep the underlying sam the same (sam -d) but write a > different samterm for it which does one window per buffer? This > would also make it easy to switch to any buffer you wanted since > it would just be part of the window manger. That's how I'd do it if I had the time, but note that samterm contains some nontrivial logic itself, too. -- Christian Neukirchenhttp://chneukirchen.org
Re: [dev] Re: Experimental editor
On 15 June 2011 15:54, Josh Rickmar wrote: > Why not just keep the underlying sam the same (sam -d) but write a > different samterm for it which does one window per buffer? That question is where my editor started. The answer to "why not" is, sam is ugly. A common misconception is that samterm just speaks the same language as sam -d. It doesn't, it uses a custom binary protocol and contains a lot of caching logic and so on. The protocol wasn't designed before implementation, I think, and it was not designed with writing an alternative samterm in mind. It's just a de facto protocol, and imo it is quite broken. After starting a few samterms over the past year I decided the protocol is just too obscure, and we can make it a lot simpler just by writing something from scratch. That way we can also take advantage of the new back-end, allowing us to use interactive structural regular expressions and so on. It's easier to write a new sam-inspired editor than restrict ourselves to the samterm protocol. And that's what I'm going to do, rolling in a few ideas from other editors as I go. cls
Re: [dev] Experimental editor
- Original message - > > Still I wonder why you try so much to stay modeless. Modes are a real > > advantage because each mode offers a separate editor. Take vi: You can > > edit in normal mode (= the actual vi mode) or in ex mode or in insert > > mode (e.g. with ^W, ^U). You have the choice which editor (mode) you > > use for some editing task. Ed has modes, too: Command and insert mode. > > > > Surely, the problems are knowing in which mode you're in and switching > > modes. But in return, each mode lets you re-use your keyboard keys > > (the optimum) and for each mode you can design a new editor that's > > best suited for the kind of editing this mode is intended to do. > > Why would you want several editors? The problem with vi and mutt is that > they have all these keybindings; hence you can on occasion find yourself > in some crazy dark key combination that you didn't mean to be in. > > A simple editor probably shouldn't have any more keybindings than, say, > surf; in fact one or two less: page up/down, up/right/left/down, and > find. One doesn't need modes for that. If you want to do something > wacked out to your file (like go to the third word on the 4th sentence > and delete every vowel), that should probably be done *outside* the > editor. > > Peter > > > -- > sic dicit magister P > PhD Candidate > Collaborative Programme in Ancient and Medieval Philosophy > University of Toronto > http://individual.utoronto.ca/peterjh I own a keyboard that has no pgup/pgdn, or arrow keys. My 2 cents. Jon.
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: > I own a keyboard that has no pgup/pgdn, or arrow keys. Did you steal it from a museum? --Andrew Hills
Re: [dev] Experimental editor
> > A simple editor probably shouldn't have any more keybindings than, say, > > surf; in fact one or two less: page up/down, up/right/left/down, and find. > > One doesn't need modes for that. If you want to do something wacked out to > > your file (like go to the third word on the 4th sentence and delete every > > vowel), that should probably be done *outside* the editor. > > I've got a long comment queued up (restricted internet situation at > work), but just to respond to the comment about moving stuff "outside > the editor". One big disadvantage of doing everything "by hand" is > that such stuff isn't in an undo history that you can execute. I tend > to use undo a certain amount, mostly immediately (which could be > simulated by just keeping one copy) but a reasonable amount undoing > several sets of changes. I can't wait. As to revision control, just use software made to handle revision control. The editor doesn't need to do this. Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Experimental editor
* Andrew Hills [2011-06-15 11:51:17 -0400]: > On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: > > I own a keyboard that has no pgup/pgdn, or arrow keys. > > Did you steal it from a museum? you don't have to go to a musem for that http://en.wikipedia.org/wiki/File:T-Mobile_G1_launch_event_2.jpg
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 4:02 PM, Szabolcs Nagy wrote: > * Andrew Hills [2011-06-15 11:51:17 -0400]: >> On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: >> > I own a keyboard that has no pgup/pgdn, or arrow keys. >> >> Did you steal it from a museum? > > you don't have to go to a musem for that > > http://en.wikipedia.org/wiki/File:T-Mobile_G1_launch_event_2.jpg That keyboard also doesn't have Ctrl... and I'm guessing no one here will bother porting the editor to an Android app. --Andrew Hills
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills wrote: > That keyboard also doesn't have Ctrl... and I'm guessing no one here > will bother porting the editor to an Android app. Nokia n900/n810 have no pgdn or pgup, but do have ctrl and arrows. -- # Kurt H Maier
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 05:03:23PM -0400, Kurt H Maier wrote: > On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills wrote: > > That keyboard also doesn't have Ctrl... and I'm guessing no one here > > will bother porting the editor to an Android app. > > Nokia n900/n810 have no pgdn or pgup, but do have ctrl and arrows. Whether or not your keyboard has a page up/down key is a bit moot; the point is that an editor should have under 10 keybindings: up, down, left, right (C-hjkl), page up and down (C-uv), save and quite (and search and search-and-replace (if you are feeling luxurious)). peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Experimental editor
plus mark, cut and paste. On Wed, Jun 15, 2011 at 2:11 PM, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > On Wed, Jun 15, 2011 at 05:03:23PM -0400, Kurt H Maier wrote: > > On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills > wrote: > > > That keyboard also doesn't have Ctrl... and I'm guessing no one here > > > will bother porting the editor to an Android app. > > > > Nokia n900/n810 have no pgdn or pgup, but do have ctrl and arrows. > > Whether or not your keyboard has a page up/down key is a bit moot; > the point is that an editor should have under 10 keybindings: up, > down, left, right (C-hjkl), page up and down (C-uv), save and quite > (and search and search-and-replace (if you are feeling luxurious)). > > peter > > > -- > sic dicit magister P > PhD Candidate > Collaborative Programme in Ancient and Medieval Philosophy > University of Toronto > http://individual.utoronto.ca/peterjh > >
Re: [dev] Experimental editor
On 06/15/11 21:24, Andrew Hills wrote: On Wed, Jun 15, 2011 at 4:02 PM, Szabolcs Nagy wrote: * Andrew Hills [2011-06-15 11:51:17 -0400]: On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: I own a keyboard that has no pgup/pgdn, or arrow keys. Did you steal it from a museum? you don't have to go to a musem for that http://en.wikipedia.org/wiki/File:T-Mobile_G1_launch_event_2.jpg That keyboard also doesn't have Ctrl... and I'm guessing no one here will bother porting the editor to an Android app. --Andrew Hills I use G2 as an emergency when I need to edit via SSH. it works well with vi. zalun
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 1:40 PM, Piotr Zalewa wrote: > I use G2 as an emergency when I need to edit via SSH. > it works well with vi. I have a Motorola Droid on which I use vi over SSH on a regular basis. It is extremely painless. --Andrew Hills
Re: [dev] Re: sbase
On 11 June 2011 00:40, Connor Lane Smith wrote: > Why not just edit the individual files' main() functions (in a build > directory) and generate a main.c, compile them, and link the object > files together? Don't have to worry about anything except main(), > then. An update: I've done this, and added it to the Makefile. It's a little simpler than doing it by concatenating all the sources, since we don't need to worry about statics or anything. Currently sbase-box comes out at 69K statically linked against musl, or 23K dynamically linked against glibc. So next I'll carry on with the items in TODO. Any contributions are welcome. ;) Thanks, cls
