Keybinding proposal

[paradigm]

From vimorg.txt: "Keybindings are still a moving target. I'm happy to hear from people who think they've found better command bindings."

I put some thought into it, and since the help made you seem so open to ideas I figured I'd pipe up.

The primary difference in philosophy between Emacs and Vim is that Emacs makes heavy use of the modifier keys while Vim determines what keys based on what mode it is in. The default bindings some of the core aspects of VimOrganizer - specifically OrgMoveLevel() and OrgNavigateLevels() - are slightly Emacs with their usage of modifier keys (plus, they don't work on terminals). The solution you've got in place for those who won't or can't use that aren't good for repeated use; hitting ,zu,zu,zu,zu is far more awkward than necessary. Plus, while u/d/l/r make sense in a vacuum for navigating up/down/left/right, they do clash a bit with Vim's h/j/k/l. Having the l key go right in one context and right in another is a bit disorienting.

I propose you create your own mode from which more accessible, simpler keybindings can be used for OrgMoveLevel() and OrgNavigateLevels(). Maybe use o, for example, to enter/start the mode. naturally should be used to return to normal mode. From within org-level-mode (or whatever you would like to call it), h/j/k/l (and the arrow keys without any modifiers) could be used to OrgNavigateLevels() and H/J/K/L could be used to OrgMoveLevel(). Or perhaps f/b/n/p ("forward/backward/next/previous", already used in Vim for other movements) could be used for OrgMoveLevel() to avoid the shift key. Or maybe just have both sets of H/J/K/L and f/b/n/p.

Sadly I'm not sufficiently familiar with orgmode or VimOrganizer to propose what else could be made more accessible with this mode, but there's plenty of keys to spare if you or someone else has other ideas. Anything that would naturally be done in directly before or after OrgMoveLevel()/OrgNavigateLevles() or just be used several times in a row would become much more accessible if made available here.

While this makes sense for doing repeated, sequential actions, it is clearly more typing than your current setup for just a single action in that mode. I figure there should also be a mapping for doing one action in that mode. It could be the z stuff you've got set up; just change u/d/l/r to h/j/k/l and j/k/L/R to f/b/n/p or H/J/K/L. Of course, there's also no reason to remove the bindings you've got for those who do like the arrow keys and modifier keys.

If you don't get to it, but don't hate the idea, I can try and see about coding it up myself and throwing a pull request at you. There's a few more weeks of academics that will be eating my time before winter break, but once mid-december hits I should have the time to dig through your code base and write something up in a similar style which accomplishes this.

That was really the main thing I wanted to say, but a couple of other minor things:

Why is hardcoded in there? I thought the whole idea of the leader key was to allow end-users to pick what to use as a prefix rather than the plugin writers. It wasn't hard to dig into and change to my preferred leader key, but I feel it should be made configurable without having to dig into the source code. Maybe have a check to see if maplocalleader is set, and if not than set it to "," - thus allowing the end user to set it to something else in his/her vimrc easily enough. Or, if you'd prefer, you could just make the script grab the value from a global variable and have the end-user throw let g:org_mode_leader="," in his/her vimrc.

Is Emacs' orgmode picky about whitespace and indentation? If not, I figure << and >> would be natural keybindings for promotion and demotion of headings. Perhaps map them to the appropriate OrgMoveLevel() calls.

[hsitz]

On Mon, Nov 21, 2011 at 3:15 PM, paradigm < reply@reply.github.com

wrote:

From vimorg.txt: "Keybindings are still a moving target. I'm happy to hear from people who think they've found better command bindings."

Thanks for all your good thoughts on this. I'll keep them in mind as I get back to redoing the keybinding stuff.

Not a huge help, but the up-down level-moving operations both allow a count prefix, so you can move a tree up four items with 4,zk. Or just put a 99 in front to move it to top/bottom of siblings, since excess is ignored. I suppose I should add those on for promotion/demotion, though they're less useful there.

Also, you may want to check into refiling as an alternative to using the move functions. For some moves it makes more sense and for some it doesn't. I'm going to be pushing up some changes/additions to it to make it easier to use, but right now you can do ,r and chose 'refile', then press enter on to get tab-completed list of headings in current doc. . .

--- Herb

[paradigm]

I'll definitely take advantage of counting and refiling for the time being, until you get to redoing the keybinding stuff.

[f0086]

+1 for the h/j/k/l keybinding! The arrow keys is not an option for me.

[odabrunz]

My thoughts on this:

+1 for short / easy to type key sequences +1 for less usage of modifiers (to sum up: a number of terminals do not support a number modifier + key combinations (C-RET, S-RET, C-., C-,, ...); also, there tend to be collisions with window managers, which tend to embrace modifiers + key combinations, because it has a kind of "less often used by apps" and "modifiers take me up to a meta-level" feel)

Separate mode:

A separate mode for VimOrganizer using it's own short key sequences may be an alternative. But only if it is clear in which mode the buffer currently is. (AFAIK, you cannot just define another "-- MODE --" string to display at the bottom.) Iff displaying the current mode is possible, I would prefer something like a special "move sections around" mode. This reduces the number of occasions where you want to enter and leave the mode. You enter the mode just to re-file / move around headings and leave it when you are finished.

Having this in a separate mode also means that no key bindings for these functions are needed in normal mode. This frees up more of the available keys for functions that I would use more often while editing, such as moving around to other headings.

Mode-changing can then use a multi-char sequence (such as ',zm'), as it is not needed that often (at least not before every other keystroke). (A single-char binding is likely to override some existing normal mode key, or at least would steal one of the rare keys that can be used as prefixes for sequences.)

Moving headings could then be bound to h/j/k/l and <Left>/<Right>/<Up>/<Down> directly.

That being said, I still doubt that it is easy to display the current mode. (Unless you are willing to change syntax highlight colors when in the "special" mode, and/or you offer a mode-showing function to add to the statusline, as in %{OrgModename()}.)

Other:

I prefer bindings such as both of the following for moving between headings:

<prefix>[hjkl]
<prefix>{<Left>,<Right>,<Up>,<Down>}

Finding a short <prefix> is the challenge here. A two-char prefix like <Leader>z may have to do, as I believe that any one-char prefix is already in use (either as a normal mode operator or as a <Leader> or candidate for a <Leader>).