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 _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
