Juri Linkov writes: >>> (I see there were some unfinished parts in your previous patch). >> >> It's been a while since I submitted it, so I had to re-read the thread, >> but I'm not quite sure what the "unfinished" parts were, aside from the >> missing autoload cookies. Sorry if I missed something :/ > > I don't know, my impression seems to suggest the first version was not > completely tested, for example, windmove-modifiers defcustom called > windmove-swap-states-default-keybindings, not windmove-default-keybindings. > But maybe you already fixed this. You're right, I still had a few local changes. A noteworthy addition is that the user options unbind their previous bindings, before binding the new ones. This should lead to more consistent behaviour when updating the option a few times in the same session. >> Also, the second patch (the one with the user options) depended on the >> previous one in this thread[0], that introduced the "none" prefix. Is >> that fine, or should I just merge both patches into one. > > This is perfectly fine - better to commit two separate patches. Ok. I added both below. But there are a few general issues I noticed: 1. windmove-display-{same-window,new-{frame,tab}} can disturb regular input when the modifier is set to shift or none. Possible solutions could be to prohibit using these modifiers or to add a prefix key and generate a warning when eg. "S-t" or "t" would be rebound. 2. The new function windmove--unbind works with the global-map, so when someone sets a prefix to none, and then changes it to something else, the arrow keys are left undefined. I could either see this being fixed by using a separate map or by somehow memorising what the previous key was (eg. by using the property list of the windmove command's symbol). These are the only edge-cases I found, but I didn't fix them yet, as I'm not sure what would be preferred. So the patches should not be applies yet. -- Philip K.