Has anyone ever attempted to re-imagine Vim?

Question

Firstly, I want to state for the record that I am not attempting to be a troll, and I do not intend this question to be flamebait.

I asked an earlier question in an attempt to discover what other modal editors existed besides Vi/Vim. I was fully expecting that there would be at least a couple of other general-purpose editors that were similar to (or inspired by) Vim. To my surprise, I discovered that the only other modal editors out there are either specific to a particular language or restricted to some ancient legacy platform.

My question is: has anyone ever considered re-imagining the commands and keyboard layout of Vim, ignoring all of the history inherited from vi and other earlier programs? Also, would this be a good idea? For example, are there any little-used features in Vim with their own alphabetic key that could be reassigned, freeing up a prominent key for something more useful? I think that the recently released version 3.0 of Python has shown that there can sometimes be value in breaking reverse compatibility. Would a similar process benefit Vim?

(Note: Yes, I do realize that changing Vim's commands around would cause a lot of problems for those that have used Vim for a long time, and have built up muscle-memory for the current layout, so my analogy with Python 3.0 isn't really valid. Still, I hope that the analogy at least helps a little with getting my point across.)

Update: We're moving away from the old uservoice.com site to a new IdeaTorrent site hosted by Sourceforge.net. Unfortunately, uservoice only allowed each user to cast 10 votes. I want each user to be able to vote on each idea, so uservoice clearly won't work when hundreds of ideas have been submitted. Please submit any new ideas to the IdeaTorrent site. I plan on migrating existing ideas over in the coming weeks, and I will try to credit all of the original submitters (please let me know if I forget to credit you).

Update: I have created a new forum at uservoice.com to allow new ideas for our re-imagined Vim to be submitted and voted up/down. For the time being, I have given this project the name "reVIs" (pronounced "revise"), but am completely open to suggestions on a better name. I have entered gkirilov's idea from his answer below as the first candidate modification in the new forum.

Answer 1

Either you like Vim, or you prefer some other editor. If you like Vim, then you probably enjoy its keyboard layout. This is particularly true because Vim is around for a long time. If you prefer some other editor, why would you use, work or pay others to work on something that you don't like?

Sure, you may like Vim's interface but dislike some specific key, but then is that enough to spend a lot of time trying to create a new Vim? So, the answer is people may have considered it, but I doubt anyone has spent serious time with that idea.

I suppose that "benefit Vim" means "the changed Vim would be better". If you preferred the new layout, then of course you'd think it was better. If you preferred the old keyboard layout, then the answer would be "no".

There seem to be few Vim clones, but curiously some newer IDEs try to clone the old layout.

Answer 2

You know, seriously, there are rather a number of examples I can think of, including XEDIT and TECO. But thinking about it, it would seem that the space of possible editors is pretty well covered at this point. An editor needs to be able to insert, display, update, and delete text, the usual CRUD operations; we expect an editor, for programmers at least, to be able to assist in keeping code formatted and indented, and probably to at least assist in language syntax.

There have been a number of attempts at making more visual, not so text-oriented programming tools; these don't seem to stand up well except in the special case of UI coding. And of course there's the "non-modal" model of EMACS and most IDEs, like Eclipse.

So what would a modal, modern editor look like? The basic issue is being able to manipulate the text. In EMACS on old terminals, you do that with key chords -- C-f to move forward a character, so that f can just insert the character f. In vi, instead of using the control characters, you had a modal environment so that f was "forward a character" in command mode, and "insert f" in insert mode.

But on a modern computer, you don't have the sort of "key bandwidth" restrictions you used to have; we have lots of keys and we aren't restricted to just the 6 or 7 bit charset. So it would seem that there is room for a direct interaction model ("non-modal") and if you wanted a modal model, it would be isomorphic to vi up to key remapping.

So maybe there're no new modal editors because there's no room for another one?

Answer 3

I believe it's the same reason that no one has "replaced" Emacs, in spite of some cruftiness. Change anything, and you alienate your main audience (Emacs/vim users) and they just go back to the things they've used for years and know like the back of their hand and have personalized to infinity. Plus you'd likely lose the zillions of user-contributed enhancements that already exist for said editors.

The IDE users won't use your editor anyway.

Answer 4

I have thought the same thing. I find the key bindings in vim to be quite arbitrary, even though I use it pretty much as it comes. A better analogy would be between the Qwerty and Dvorák keyboard (I wonder what vim is like in Dvorák keyboard infact). I should use the Dvorak but am too lazy to learn. The open source community does not have enough power to do real usability testing of the like needed to make an editor that is so cleverly subtle in helping you edit the way you need BEFORE you realise what you need (not even microsoft or apple can do it and they spend loads on usability testing). Nor is their any attempts to make configuring the editor itself as natural as using it. It always takes too much time and a lot of self reflection on your practices, to even know what you want and when you do a fair while to implement it (even in vim or emacs). Vim goes closest to that in my eyes. It would take anyone months to come up with a better design and even longer to design a system to cater for everyones individual spins on it. I am sure its possible, but I am not the one to do it. The future may be different we may just get nintendo to design something that we can just wave our hands at and magically what we think appears syntax highlighted, indented correctly and all we have to do to debug it is bash our heads against it. Till then I am keeping with vim.

Answer 5

You should look at Cream. it's built on top of the VIM editor. from the site it is a modern configuraiton of VIM. I have been using it for years as my quick and dirty editor. Never got to liking notepad++. Maybe this will give you some inspiration.

Answer 6

I think Cream is the closest to what you are asking - it aims to be a "modern configuration of the powerful and famous Vim"

There are other more "modern versions" of vim, for example gvim/MacVim. There is also a "Vi Input Manager" for OS X which adds Vi key-bindings to any Cocoa text-input box, and similarly ViEmu does the same for Visual Studio/Word/Outlook/SQL Server. The author of ViEmu has also mentioned writing a modal text editor.

That said, editing text really hasn't changed much in the last decade or two.. Lots of people still use vi (or vim, rather), and it still works great. There just isn't much reason to write a new editor, much less a modal one. The answers to a question I asked here a while ago, "Why are there so few modal-editors that aren’t vi*?" may be of interest.

Answer 7

Breaking backwards compatibility will never be an option for vim - consistency across all versions and platforms is one of its primary features. However, if I had ridiculous amounts of spare time then I would love to help Bram re-engineer vim to allow me (and everyone else) to customize all of the hard-coded behaviours.

Answer 8

I have also dreamt about this several times, and I think there would have to be two main architectural differences:

1. Physical-key based mappings for 'non-insert' modes:

I find that most keyboard layout problems in Vim are due to the fact that we have to think of the keys in terms of their characters (their function in 'insert' mode) even when we are not inserting text.

I am a Dvorak/Vim user and I know that for people that use layouts other than QWERTY, the character-based shortcuts are in fact an annoyance, especially those that are not mnemonics like 'i'=insert, for example: the cursor movement keys.

In fact, the Vim documentation states that the keys 'h', 'k', 'j', 'l' were chosen for cursor movement not because those letters mean something, but because of the convenience of where they are placed. But as everyone knows, as soon as you switch to any non-qwerty layout one can see that it is in fact the letter what it is important to Vim's implementation, not the key.

In all modes other than insert, what we should be worrying about is not the key char, but the key position, or finger.

A 'new generation' editor should let the user map commands to physical keys, or fingers, not to letters. That way, the keyboard layout wouldn't matter and everyone would be able to enjoy the same productivity and usability benefits no matter what 'layout' they use for inserting text.

Honestly, I don't know if this issue has any practical solution other than working directly with keyboard scan codes, which can get messy very soon.

2. The use of modern graphical UI elements

Why does everything have to be drawn in terms of text chars?. We need to take advantage of modern windowing systems for things like window splits, collapsed regions, status info, marks, etc.

So, in summary, I think it would make sense to have a new-generation modal editor.

Come on, let's do it. I'm in.

Answer 9

Don't forget that vim is highly configurable. If all you are looking for is a different key mapping to vim then you can re-imagine any new keymap you want in .vimrc settings. See:

Vim documentation: map

If you really wanted to, you can use common gaming keystroke "aswd" to replace vim's "hjkl" for left, down, up and right respectively. (Just an example. hjkl is probably the best editor keymap to be invented.)

I try to keep my vim's mapping as default as possible except Ctrl+x, Ctrl+c and Ctrl+v should be cut, copy, and paste. And CAP lock is another ESC key.

Answer 10

Well, Microsoft has reimagined unix, and we have Windows, which seems to be asymptotically converging back.

They and others have tried to reimagine regular expressions, and have, in every case, achieved something less.

Conceptual integrity is a dangerous thing to mess with.

Answer 11

I think the reason there have been few other attempts to re-imagine VIM is that over a very long period of time, VIM/vi have really optimized the command set for keyboards that are still very similar to what were used decades ago. Indeed, over time modern keyboards have actually lost keys from what older UNIX users were used to...

With a modal editor, life is all about the quickest input via the keyboard - adding much interaction via things like the mouse is inherently non-modal, since you are generally choosing a menu item from a large set and acting on something directly. Introduction of modality into a mouse based interface would seem to be a reduction in efficiency, not an enhancement - and so as editors move toward more GUI driven IDE kind of environments, thoughts of modality go to the wayside as they no longer make sense for how people use the editors.

Answer 12

Maybe "jkl;" instead of "hjkl", so it would match the touch-typing home position better?

(Hm, maybe I should gave it a try first. One god knows how many reasons against this there could be...)

Answer 13

Re-imagine Vim? Are you nuts? In a world of graphical pollution via ads, iPhones, 62" HDTVs, commoditized super-graphics-cards, multi-monitor desktops, etc, who could imagine giving up the purity of 1976, with its tiny text-mode screens and uniform keyboard interface? Actually, I'm just kidding here--I am all for your idea, and have been thinking about it for a while too.

To the Vim purists who disagree with GUI additions, I'm totally with you, since I too am a zealot of the One True Editor that remains faithful to Unix. But there's nothing wrong with a sort of extending-wrapper around Vim like MacVim, or changes to Vim itself to be gui/console agnostic. As long as the straight console mode is not compromised. Choice is the goal after all in Open Source is it not?

One example that absolutely nailed mixing a text interface with minimal gui was Quicksilver. If you're "with it" with Macs, then you've probably seen Quicksilver; the code of which is now dead, alas!

Not too long ago on [on the MacVim dev list][1], a guy named Matt Tolton started trying to add a Text-Mate-like drawer for a better file explorer that looks more integrated into the OS. It doesn't look like the project got too far in MacVim, but Brian did offer good insights on how to develop it, so surely capable Vim devs have been thinking about this.

Hopefully a year or so from now we'll all have MacTablets and as we need touch screen versions and other-screen versions of Vim for who knows what future computers, then maybe the impetus behind this kind of re-imagining will grow.

Answer 14

This will be a bit controversial, but I think Ctrl-c and Ctrl-v should be by default copy and paste. These keybindings are very good when using the mouse on one hand and the keyboard in the other. For example, if I am copying text from firefox into vim, I could use Ctrl-c to copy in firefox and Ctrl-v to paste in vim which is very easy to do with one hand.

At the moment, copy and pasting is more difficult. When in insert mode, to paste from the system clipboard you need to do Ctrl-r (harder to reach than Ctrl-v), then + (which requires you to move your hand to the other side of the keyboard, hold down shift and press =. If you use the option where the default register is synced with the system clipboard, then " can be used instead of =, which is a little better, but still not as good as Ctrl-v.

In normal mode, a similar problem occurs. After typing Ctrl-c to copy, you would then have to move your hand other to p in order to paste. No movement is necessary if Ctrl-v worked here.

mswin.vim (I think) addresses these issues, unfortunately it isn't like very much by most vim users.

Answer 15

this is not as comprehensive an endeavor, but i'm trying to come up with a new key layout for vi command mode to minimize chording and maximize efficiency:

http://bayleshanks.com/tips-computer-viperRemap

Answer 16

I have reimagined vim many times. There are a number of major problems I perceive:

1. Scripting vim is very nasty. The language is awful and non-sensical. I try to use bindings these days, but those are worse (or at least the Python binding is terribly incomplete). I'm very jealous of Emacs people who seem to write scripts for half their jobs. This is too hard in Vim.

2. Language support is very bad. CTRL-P only barely works, tags are nasty to use and seldom work properly (and also take a long time to configure close-to-correctly). gD should work consistently, but doesnt. Each language needs a full parser, and all tools and commands should reuse that parser (that's not to say you need to implement the parser, just build around existing open source parsers, possibly even eclipse).

3. Plugins are badly done. You need to download something from vimscripts.org, and cross your fingers.

4. Settings are badly done. I change my setting so rarely that I never remember the appropriate syntax, and the feedback/errors/warnings is pretty bad. I'm reluctant to suggest a GUI, but for simple things a simple GUI (or curses-based if that's your preference) would make things a million times easier.