[implementations-list] upcoming release & changes

Sat Mar 6 17:23:37 CET 2010

> Date: Fri, 5 Mar 2010 23:43:18 +0100
> From: stepnem at gmail.com
>
> 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