Take the 2-minute tour ×

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.

share|improve this question
Make your wiki I am having a few ideas. –  David Raznick Dec 29 '08 at 3:24
shuffling around a few keys is not "re-imagining". Say, do you have an actual problem with vim as it is? –  hop Dec 29 '08 at 4:11
@hop: Even shuffling around a few keys is still important. Defaults matter. That's another important lesson from Python. In addition, there are a few ideas that I have that I'm not sure can be implemented as a simple key remapping... –  bnsmith Dec 29 '08 at 14:52
@David: The new Uservoice site is available at revis.uservoice.com. I have already filled in a handful of ideas. –  bnsmith Dec 30 '08 at 1:52
add comment

closed as not constructive by casperOne Apr 5 '12 at 13:41


15 Answers

up vote 16 down vote accepted

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.

share|improve this answer
You can re-map "non-insert mode" commands in Vim. See vmunix.com/vim/howto/dvorak.html for your particular situation. –  strager Dec 29 '08 at 6:37
One of the main reasons I use Vim is that it works well with GNU screen, thus I can access my sessions over a network without worry of installing Vim, etc. or downloading/uploading files from/to the server (because Vim is ON the server, I edit in-place!). Such sessions are difficult with GUI's. –  strager Dec 29 '08 at 6:40
@strager: That would force me to use dvorak for everything in my system but Vim, and so switch to qwerty when using vim so that I would be able to use dvorak!, because as I said in my first point, Vim is 'letter' oriented, not key oriented and that's exactly what I'd like to change. –  Sergio Acosta Dec 29 '08 at 7:26
@strager: Certainly non-GUI compatibility woulb be an issue. And I'm willing to lose that as it honestly is not one of my use cases. One could keep using the current Vim for that. –  Sergio Acosta Dec 29 '08 at 7:31
Yeah! That's the spirit Sergio! The open-source community is on the move. I've given some thought to this, and I think that we need to start with an idea-storm-like site where we can submit ideas for improvements that can then be voted up/down. Once we get a set of well-accepted ideas, we implement. –  bnsmith Dec 29 '08 at 14:40
show 3 more comments

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.

share|improve this answer
In order to avoid losing all the user-contributed enhancements, a new re-imagining project could begin as an enhancement for Vim that remapped a few keys. The project could continue on like this for a while until it hit something that couldn't be done in vimscript. –  bnsmith Dec 29 '08 at 2:56
About the IDE users, PIDA is an IDE which embeds vim or emacs, so that last statement is not entirely true - some IDE users do use them. –  Ali Afshar Dec 29 '08 at 3:13
@bnsmith - Forgive me for being an emacser instead of a vimmer, but can't you just rebind keys yourself? I know that I took the liberty of rebinding some key-combos in Emacs... –  J Cooper Dec 29 '08 at 4:57
@AliA: also, I use the excellent ViEmu in visual studio. These days I believe there is the opensource VisVim –  sehe Nov 9 '11 at 10:57
To satisfy current emacs/vim users, one could easily add 'vintage' options that would enable a more vim or emacs like behaviour. However, the defaults would be 'new', and thus people are more encouraged to use these. Eventually, support for these 'vintage' options should dissapear. –  Chiel92 Jun 30 '13 at 15:39
add comment

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 Caps Lock is another ESC key.

share|improve this answer
I suggested in another comment that this redesign project could begin as a Vim remapping. Still, I think that you've justified the need for a redesign by saying you keep your Vim mapping your mapping to the default. Most people keep to the defaults, which is why defaults are so important. –  bnsmith Dec 29 '08 at 14:25
add comment

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.

share|improve this answer
I really admire the Cream project, and have used it. The only deal-breaker with it is the inability to open multiple windows. I am an avid user of multiple desktops, and I need to be able to have a Cream window open on more than one. If not for that, I would use it all the time. –  bnsmith Dec 29 '08 at 14:28
Cream used to open in multiple instances each time you launched Cream from the command line. In the latest rev this "feature" is either gone or disabled by default. i havent looked at the docs to see what happened. –  MikeJ Dec 29 '08 at 20:33
I think that it was intentionally removed, due to some difficulties with the way that Vim is implemented. –  bnsmith Dec 30 '08 at 1:55
bummer. i loved it in the old form. sigh. –  MikeJ Jan 3 '09 at 4:08
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
Dont agree that key bandwidth is a reason not to have modal editors. You are after efficiency and mental cogency. Of course there is enough room on a keyboard to do any combination you like but you have to remember them and they have to be in good places. Patterns are good. Modal can help this. –  David Raznick Dec 29 '08 at 2:54
You asked why there aren't more modal editors. You seem to have had several options proposed and don't like any of them. So if you know the answer, why don't you tell us? Right now, we have multiple examples of modal editors that have died out, and one survivor. –  Charlie Martin Dec 29 '08 at 4:39
add comment

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...)

share|improve this answer
That's a good idea! I like it. However, I'm still a relative newbie. Any more experienced Vim experts out there care to comment? –  bnsmith Dec 29 '08 at 14:32
J and k are in the best position for a right hander (under best hand, with two strongest fingers), and I don't think that they should be moved as up/down is to me the most common operation. So I think the debate would be whether to make the keys j<down>, k<up>, l<left> and ;<right>. I have used vim for about 4 years now, and I find I use keys like f, t, w, b, etc for moving left or right rather than h and l. h and l move too slow when compared to those keys. So with that config, I would lose ; as the "f next" key (probably replaced with h), which would be a big hit. Probably not worth it. –  David Miani Sep 16 '09 at 8:21
add comment

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.

share|improve this answer
I certainly agree that it would be difficult to implement this, but I do think the open-source community can make it happen. They--or we--have accomplished amazing things so far, and anyone who underestimates us does so at their peril! –  bnsmith Dec 29 '08 at 2:49
Posting two comments like this is probably bad form, but I can't help myself. Starting the redesign process would be easy. All that would be needed is one specific change to make in the layout. It could be put on a Wiki and once 10 or 20 changes are listed, the ball would be rolling. –  bnsmith Dec 29 '08 at 2:54
If you wanted to start one, I personally think its would be a great idea and I would have my ideas in it. Interface design(human not java) is possibly the most important thing in the future of computing, for programmers and non alike. Implementing stuff is not that hard when you know what you want. –  David Raznick Dec 29 '08 at 3:01
Bad form for me too. However the amount of thinking required to start in decent way would be quite difficult, and we (the open source lot) would have to make our communication channels a lot better then they currently are I think (but its possible) to improve the state of interfaces in general. –  David Raznick Dec 29 '08 at 3:06
As an aside, a guy I work with uses Dvorak and Vim. He reports that the keys make even less sense; for example, the cursor-movement keys are not in any logical position. :) –  mipadi Dec 29 '08 at 3:34
show 2 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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:


share|improve this answer
That's really neat! I'm going to have to spend some time going over your remapping; it seems very different from what I've been playing around with. If either one of us encounters some success, it can only be a good thing for Vim-like modal editing. –  bnsmith Oct 4 '09 at 0:55
add comment

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.

share|improve this answer
I wouldn't call anything a "Vim clone", but there are plenty of other "vi clones", like nvi. –  Paul Tomblin Dec 29 '08 at 2:21
Some of the changes that could be made would likely be a matter of personal preference, but there must be at least a few changes that would get the support of, say, 99% of Vim experts. If a change got this level of support, then it would be reasonable to view it as definitively "better". –  bnsmith Dec 29 '08 at 2:59
add comment

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.

share|improve this answer
add comment
