Vimpulse and vim-mode

[Vegard Øye]

On 2011-02-25 17:46, Frank Fischer wrote:

> Because Vimpulse and vim-mode both seem to have the same goal or
> very similar goals, providing more of Vim's features, and somehow
> replacing the old viper-code by more structured core, the natural
> question arises if we should try to join both projects to a common
> one.

I would love to work on a common project. Getting all our users on a
single "platform" will likely give us more user extensions, which is
my main motivation for doing what I do -- the great thing about
sharing code is that others share back, too. :)

> I think both projects currently have their strengths and weaknesses
> and certainly both of us learned a lot about the difficulties when
> trying to make Emacs behave more like Vim, and sharing this
> experience may be a good idea.

I agree. I haven't used vim-mode much, but some of its parts look
very impressive (Ex in particular).

> So, what do you think?

How do you imagine we set up a common project? There is a couple of
technical issues to sort out:

* Version control (Git vs. Mercurial)

The last time I checked (when I made the switch from SVN to Git),
this list was rather Git-partial. (I actually argued for Mercurial
then.) I have since grown to love how Git does a lot of things,
like branching. Also, I have no experience with Mercurial.

How about you?

* Hosting

If we go with Git, I suggest Gitorious as a hosting provider:
it is project-oriented rather than person-oriented. I know
of no project-oriented Mercurial providers.

* Merging

Where do we start? What parts will benefit from a rewrite, and what
parts can be included as-is? Whatever we decide, I think extensibility
should be a prime goal.

In that regard, neither Vimpulse's nor vim-mode's keymap handling
are quite as flexible as I'd like (I want to assign vi/Insert/Visual
bindings to Emacs minor and major modes; this was a lot of work to
accomplish under Viper). My suggestion is to write an extensible core
from scratch, and then "plug" the more mature parts into that
framework.

For what it's worth, I've pushed a sparse starting point to the
"development" branch. The comments explain the keymap issue in
more detail.

http://gitorious.org/vimpulse/vimpulse/blobs/development/vimpulse-states.el
http://gitorious.org/vimpulse/vimpulse/blobs/development/vimpulse-tests.el

* Unit tests

I would really like to have a modicum of test coverage this time
around. I don't how many Visual mode regressions I could have
prevented if I had started writing tests earlier, but from my
experience, some of the issues pertaining to Emacs' region
(among other things) are naturally hairy.

Regarding test frameworks, I hear Christian Ohler's ert.el is now
included with Emacs trunk, so we could go with that:

http://www.emacswiki.org/emacs/ErtTestLibrary

* Name?

Something new? Something catchy? Suggestions?

-- 
Vegard