[implementations-list] Dear readers: We need ten minutes of your time to test Vegard's vimpulse-modal so we can decide if to include it in Vimpulse or not

Fri Jan 29 12:36:30 CET 2010

Sorry for the late reply; I've been busy moving the last few days.

> Vegard, feel free to merge it. Please don't forget to add yourself
> to the Copyrights file if you haven't done so already.

Done. Thanks for the reminder. :)

>> What I miss from vimpulse-modal.el are the unmapping functions
>> to complement the mapping functionality.

Unmapping is done with nil, e.g.,

    (vimpulse-map "cae" nil)

which works exactly the same as Emacs' own functions (global-set-key
et al.). If there is a whole tree of bindings starting with "cae", the
invocation above removes all of them. You can use 'undefined in place
of nil to be less forceful.

Also, the latest versions of vimpulse-map and vimpulse-imap have an
optional third argument for restricting the binding to a major mode:

    (vimpulse-map "cae" 'foo 'emacs-lisp-mode)

The binding above will only be seen in vi state when editing Elisp
code. vimpulse-vmap doesn't have this functionality yet, as Visual
mode currently isn't a Viper state proper, and therefore doesn't have
its own major mode extension keymap. I intend to rectify this soon.

>> Maybe you're going to add them after merging with Vimpulse, as well
>> as the Vim (un)mapping Ex commands?

Viper already has its own :map and :unmap commands, which are used for
keyboard macro purposes. I suppose I could redefine them, but where
would they be of any use? Only Elisp goes into .emacs (and .viper), so
one can't store any :map statements there. Well, there happens to be a
TODO entry suggesting Vimpulse be made capable of grokking .vimrc
files, but after having grappled a bit with the existing
.emacs/.viper/Customize-broken clutter, I don't know if this is such a
swell idea. There are too many ways of customizing Emacs already (and
their hierarchy isn't always clear), and adding another could just
make things more confusing.

The cleanest approach, I feel, is just to point Vim users to the
.emacs file, perhaps along with some Elisp code they can copy and
paste into it. It may be unfamiliar at first, but then again, not too
dissimilar from the way we've also pasted "unfamiliar" lines into our
.vimrc files. :)

Vegard

_________________________________________________________________
Nye Windows 7: PCen som passer for deg. Finn ut mer.
http://windows.microsoft.com/shop