[implementations-list] h/j/k/l keys in Info mode (was: How important is a Vimpulse user manual? ...)
On Wed, Feb 10, 2010 at 3:18 PM, Vegard Øye <[email protected]> wrote:
From: [email protected] Date: Wed, 10 Feb 2010 03:52:13 -0500
[snip]
I think people can just use the arrow keys and Enter in Info mode. :)
Yes. But to the seasoned Vim user with his hands at the home row, the annoyance will be there. (If you're going to use Vim keys in Emacs, you're probably somewhat seasoned. :)
Fair.
Anyway, I added some utility code to vimpulse-misc-keybindings.el in changeset [58] to address this in time. The idea is that there are two forms of vi navigation: the "core" commands, like h/j/k/l, and the rest. The core commands should, in general, be available in every mode, even if this means overwriting the mode's own bindings for these keys. On the other hand, the rest of the vi navigation commands -- w, e, b, f, etc. -- are optional: they are only added if their keys don't already do something else. Thus w may move forward by words or it may not, while h always moves one character to the left, no matter what.
[snip] Interesting. I see, looking at the changeset[*], that this doesn't yet affect Info mode unless you uncomment the several lines of commented-out code starting with eval-after-load 'info in vimpulse-misc-keybindings.el. If you uncomment those lines, then in Info mode, what can you press to go back to the last Info node you read before? Surely "l", the "Last node" key, won't work. Cheers, -Jason ^ [*]. http://my-trac.assembla.com/vimpulse/changeset/58
From: [email protected] Date: Wed, 10 Feb 2010 20:40:15 -0500
If you uncomment those lines, then in Info mode, what can you press to go back to the last Info node you read before? Surely "l", the "Last node" key, won't work.
Indeed. In Vim's help system, CTRL-T is the key for that. I have bound it accordingly in changeset [80]. `Info-help', the old command for h, is bound to M-h. I have also created a `vimpulse-want-vi-keys-in-Info' variable to make the vi scheme toggleable. http://code.assembla.com/vimpulse/subversion/changesets/80 What do you think? These changes should be documented, of course. Vegard _________________________________________________________________ Windows 7: Du får hjelp til gjøre mer. Utforsk Windows 7. http://windows.microsoft.com/windows-7
On Thu, Feb 11, 2010 at 1:03 PM, Vegard Øye <[email protected]> wrote:
Indeed. In Vim's help system, CTRL-T is the key for that. I have bound it accordingly in changeset [80]. `Info-help', the old command for h, is bound to M-h. I have also created a `vimpulse-want-vi-keys-in-Info' variable to make the vi scheme toggleable.
http://code.assembla.com/vimpulse/subversion/changesets/80
What do you think? These changes should be documented, of course.
I haven't tested your code, but it sounds like it's very useful. Two nitpicks: * 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. :) * 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. 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? :)
From: [email protected] 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. 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. 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
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. Vegard _________________________________________________________________ Windows Live™ Mail. Flere kontoer på ett sted. http://download.live.com/wlmail
On Wed, Feb 17, 2010 at 5:18 AM, Vegard Øye <[email protected]> wrote:
From: [email protected] 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
From: [email protected] Date: Wed, 3 Mar 2010 15:43:02 -0500
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? :)
I haven't thought of a better name, but I've replaced the "vimper" prefix with "viper-imm".
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.
They tend to follow the convention of using , as a prefix key in Visual mode (viper-in-more-modes' is SPC). Come to think of it, I do the same myself. In my .emacs I have the line (vimpulse-vmap ",c" 'comment-dwim) which lets me comment and uncomment selected text very comfortably. Compare with the following VimTips: http://vim.wikia.com/wiki/VimTip369 http://vim.wikia.com/wiki/VimTip271 But, yeah, we should make viper-in-more-modes emulate existing Vim plugins as far as possible. Probably a bit of work, though.
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?
[...]
This explanation is now outdated. I changed the code so that Info-mode et al. come up in vi state by default, but their own maps still have presedence over the vi maps. This is done by copying the mode's keymap into the major mode extension keymap. We're ready for release. Any last-minute changes? Vegard _________________________________________________________________ Windows 7: Du får hjelp til gjøre mer. Utforsk Windows 7. http://windows.microsoft.com/windows-7
On Fri, Mar 05, 2010 at 07:36:58PM +0000, Vegard Øye wrote:
We're ready for release. Any last-minute changes?
IMO vimpulse-utils.el should be removed. It only contains three trivial definitions, none of which is actually used; and one of them (`vimpulse-region-command') would not even work, as `vimpulse-visual-start' is no longer defined (probably renamed to `vimpulse-visual-beginning'). I'm also not quite sure (global-set-key "\M-o" 'open-line) is a good idea (the key is bound to facemenu- commands' prefix by default), but have no alternative proposal either (I use neither facemenu nor `open-line', and have commented out the above definition in my vimpulse.el). One more random nit I noticed in a comment: ;;;; Using text objects as motions in visual mode is (still) not supported. That is no longer true AFAICS (there is also a typo "acheiving" in the same paragraph). Furthermore I think it's a pity you removed the sexp text object code from vimpulse-modal after inclusion in Vimpulse proper (it was probably supposed to be only an "example", but seemed to work fine and I still plan on using it (it's just I'm too used to native Emacs sexp-handling commands, so I usually forget the possibility is there)). While I know about (and disagree with, BTW) the rhetoric of Vimpulse not including any features not found in Vim, it makes perfect sense, indeed is *expected* from an editor like Emacs to have s-expressions as first class text objects. Best regards, Štěpán
Date: Fri, 5 Mar 2010 23:43:18 +0100 From: [email protected]
IMO vimpulse-utils.el should be removed.
It only contains three trivial definitions, none of which is actually used; and one of them (`vimpulse-region-command') would not even work, as `vimpulse-visual-start' is no longer defined (probably renamed to `vimpulse-visual-beginning').
Ah, yes, this file hasn't changed in 57 revisions. And, yes, `vimpulse-region-command' is clearly obsolete: it converts an Emacs region command to a Visual selection command, but the difference is now moot (all selection commands are region commands, and all region commands work with the selection). Furthermore, the `vimpulse-is-whitespace' function is trivial and unused. It's not obvious why it's an "utility". The last function, `vimpulse-set-movement-keys-for-map', adds h/j/k/l navigation to a specified map. More flexible functions for this are in vimpulse-misc-keybindings.el. Could these be useful for the end user, though? If so, maybe they ought to be moved from vimpulse-misc-keybindings.el to vimpulse-utils.el, replacing the old function. Otherwise, the file is empty of actual content and should be removed, unless we decide to keep it as a placeholder for future utilities. But if Jason doesn't object, I'll remove it.
I'm also not quite sure
(global-set-key "\M-o" 'open-line)
is a good idea (the key is bound to facemenu- commands' prefix by default), but have no alternative proposal either (I use neither facemenu nor `open-line', and have commented out the above definition in my vimpulse.el).
I have rebound it to C-c C-o in changeset [126]. This key sequence is normally unbound, but if it isn't, it's left alone.
;;;; Using text objects as motions in visual mode is (still) not supported.
That is no longer true AFAICS (there is also a typo "acheiving" in the same paragraph).
Fixed in changeset [127].
Furthermore I think it's a pity you removed the sexp text object code from vimpulse-modal after inclusion in Vimpulse proper (it was probably supposed to be only an "example", but seemed to work fine and I still plan on using it (it's just I'm too used to native Emacs sexp-handling commands, so I usually forget the possibility is there)).
I have written a custom extension for myself which rebinds the word movement keys in Emacs Lisp modes. dw deletes to the end of a S-expression, daw (and dae) deletes the whole expression, w and b jump to the beginning of every expression about point, e jumps to the end. The large-letter equivalents W, B and E respect nesting. gj goes down an expression level, gk goes up a level, gl moves out of the current expression by its right side and gh moves into an expression by its right side. cx and cX transpose S-expressions. There are also commands for splitting the line about point or after the S-expression following point, but I haven't settled on a definite keybinding scheme yet. There are a lot of rough edges and the code is ugly as sin, but it does the job for my day-to-day coding. E-mail me if you want it. I'd like to release it at some point, but the change/delete/yank code of Viper/Vimpulse needs some serious rewriting first. Viper inherits this part from vip (an earlier emulation package), and it is very convoluted and inflexible, partly contributing to my extension's ugliness. Michael Kifer, Viper's author, acknowledges the problem and outlines a better scheme in Viper's code comments. Fixing this will tie up a lot of loose ends, and will probably be the main goal of the next release.
While I know about (and disagree with, BTW) the rhetoric of Vimpulse not including any features not found in Vim, it makes perfect sense, indeed is *expected* from an editor like Emacs to have s-expressions as first class text objects.
I see your point, and can think of similar cases. For example, to copy a paragraph, you can type "M-h y", "vap M-w" or any other unholy melding of Emacs and Vim keystrokes. (Or just "yap", of course.) Muscle memory being what it is, there's good reason for this, even if it's somewhat outside Vimpulse's emulation target. Faithfully imitating Vim /is/ the main priority here, but where Emacs and Vim meet, we inevitably enter terra incognita. Another example is the gd command (go to definition), which in Vim is a stupid macro which jumps to the beginning of the text and highlights the first occurrence of the symbol. The first occurrence isn't always the definition, of course, rendering the whole thing useless (go to definition. No, not that one. No, not that one either. Ah, there it is ...). Long story short: in Emacs, gd does what it /says/, by (gasp!) analyzing the buffer a little before jumping around in it. That intelligence is provided by imenu.el, a nifty little library which lists all the definitions in the current buffer. (Try imenu with Ido!) There are other and way older examples of Vimpulse deliberately overlooking Vim's quirks, but I think I have enough to make the point: expections matter. Sometimes the /ideas/ that Vim implements are more important than the implementations themselves. Consistency matters also, of course, and the strict policy helps to give Vimpulse some focus. As a developer, I appreciate that. As an end-user, on the other hand, I just want something that /works/, and I'm not really too concerned with how it's arranged. Jason, what do you think? Is this one of those rare exception cases? Vegard _________________________________________________________________ Windows Live™ Mail. Flere kontoer på ett sted. http://download.live.com/wlmail
On Sat, Mar 06, 2010 at 04:23:37PM +0000, Vegard Øye wrote:
I have rebound it to C-c C-o in changeset [126]. This key sequence is normally unbound, but if it isn't, it's left alone.
Yeah, that's quite reasonable.
I have written a custom extension for myself which rebinds the word movement keys in Emacs Lisp modes. dw deletes to the end of a S-expression, daw (and dae) deletes the whole expression, w and b jump to the beginning of every expression about point, e jumps to the end. The large-letter equivalents W, B and E respect nesting. gj goes down an expression level, gk goes up a level, gl moves out of the current expression by its right side and gh moves into an expression by its right side. cx and cX transpose S-expressions. There are also commands for splitting the line about point or after the S-expression following point, but I haven't settled on a definite keybinding scheme yet.
There are a lot of rough edges and the code is ugly as sin, but it does the job for my day-to-day coding. E-mail me if you want it.
Thanks; I think I'll wait -- I'm actually quite satisfied with the current possibilities (Emacs native sexp handling + Paredit and occasionally the example stuff from pre-merge vimpulse-modal). Nice to hear you're working on something like that (and planning on sharing it), though.
I'd like to release it at some point, but the change/delete/yank code of Viper/Vimpulse needs some serious rewriting first. Viper inherits this part from vip (an earlier emulation package), and it is very convoluted and inflexible, partly contributing to my extension's ugliness. Michael Kifer, Viper's author, acknowledges the problem and outlines a better scheme in Viper's code comments. Fixing this will tie up a lot of loose ends, and will probably be the main goal of the next release.
Hm... do you mean you're going to (try to) improve Viper itself? Sounds great, good luck (I'm serious)! Štěpán
On Sat, Mar 6, 2010 at 11:23 AM, Vegard Øye <[email protected]> wrote: ...
Jason, what do you think? Is this one of those rare exception cases?
I don't know. The ideal would be if gd gave imenu-like behavior in both Vim and Vimpulse. But for now, I'm not sure what would be best. BTW, the reason for the slow replies is that I'm about a month behind on my email. :) -- 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
On Thu, Apr 08, 2010 at 03:26:21PM -0400, Jason Spiro wrote:
BTW, the reason for the slow replies is that I'm about a month behind on my email. :)
Cool; looking forward to hear from you again next month! Štěpán
Date: Sat, 10 Apr 2010 02:16:53 +0200 From: [email protected]
BTW, the reason for the slow replies is that I'm about a month behind on my email. :)
Cool; looking forward to hear from you again next month!
I hope we'll hear from him sooner. :) Jason, have you read the thread on distributed version control? I'm eager to hear your thoughts. http://lists.ourproject.org/pipermail/implementations-list/2010-March/000260... Vegard _________________________________________________________________ Windows 7: Se direkte-TV fra den bærbare PCen. Finn ut mer. http://windows.microsoft.com/windows-7
participants (3)
-
Jason Spiro -
Vegard Øye -
Štěpán Němec