[implementations-list] h/j/k/l keys in Info mode

Wed Mar 3 21:43:02 CET 2010

On Wed, Feb 17, 2010 at 5:18 AM, Vegard Øye <vegard_oye at hotmail.com> wrote:
>
>> From: jasonspiro3 at gmail.com
>> Date: Wed, 17 Feb 2010 02:39:58 -0500
>>
>> I think it would be better for this new code to be in
>> viper-in-more-modes or in Viper itself, not in Vimpulse. Ideally
>> Viper. In fact, I think it would be best if all of
>> viper-in-more-modes and vimpulse were merged into upstream Viper. :)
>
> Well, it seems to me that "viper-in-more-modes" is something of a
> misnomer.

Good point.  That was my mistake; in retrospect, I should've picked a
better name.  Can you or anyone here think of a better name now?  :)

> By default, Viper /is/ in all the modes viper-in-more-modes
> provides code for. Viper lists some modes which should come up in
> Emacs state in `viper-emacs-state-mode-list', and otherwise vi
> (command) state is used. Anyway, all of the modes viper-in-more-modes
> concerns itself with are well supported by Viper.
>
> What viper-in-more-modes provides is additional vi state bindings, all
> of which are prefixed with SPC (the "leader char"). For example, in
> emacs-lisp-mode, you may hit `SPC e' to evaluate the S-exp under
> point. In reftex-mode, `SPC =' brings up a table of contents for the
> document. And so on. All of this is very useful (and Touch-like!), of
> course, but it's not emulation; it's extension. None of the bindings
> are to be found anywhere else, not in Vim nor in any Vim plugin I
> know of.

Do http://vim-latex.sf.net or http://vim-ruby.rubyforge.org provide
any viper-in-more-modes-like features?  I've never tried them.

> Thus, viper-in-more-modes is an original, ground-breaking Viper
> extension in its own right. But it doesn't belong in Viper for the
> same reason it doesn't belong in Vimpulse: it doesn't emulate
> anything. Viper emulates vi and Vimpulse emulates Vim, and the policy
> of both is not to include code which falls outside the emulation
> target. (Therefore Vimpulse, for its part, can only be merged with
> Viper if Michael Kifer, the author, decides to extend Viper's target
> from vi to Vim.)
>
> According to this analysis, the Info bindings belong in Vimpulse,
> since they /are/ emulation.
>
>> May I suggest that CTRL-O should also go back, and maybe CTRL-]
>> should do the same thing as the Enter key does. Both of these changes
>> would make your code work more like Vim's help system works.
>
> Done in changeset [93].
>
> http://www.assembla.com/code/vimpulse/subversion/changesets/93

Excellent.

>> One question out of curiosity: The changeset description explains
>> that "Visual mode exits to Emacs state in [Info] buffers." I haven't
>> tested your code, but I can't figure out: why is this?
>
> Info-mode is one of the modes listed in `viper-emacs-state-mode-list'
> and comes up in Emacs state, which means none of Viper's keymaps are
> active; only `Info-mode-map' is. Vimpulse's code extends
> `Info-mode-map', and allows one to enter Visual state for the purpose
> of copying things. But when Visual state exits to vi (command) state,
> Viper's keymaps become active, overriding Info's commands. With the
> improved code, one goes from Emacs state to Visual state and back to
> Emacs state so that this doesn't happen.

Ah.

-- 
Jason Spiro: software/web developer, packager, trainer, IT consultant.
I support Linux, UNIX, Windows, and more. Contact me to discuss your needs.
+1 (416) 992-3445 / www.jspiro.com