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