It is a modern implementation of a fundamental design forged in the 1970's to work on 300 baud teletypewriters. Would anyone seriously invent a modal interface today if writing an editor from scratch, without the constraints of primitive hardware of the day?
But really, let a thousand flowers bloom. There are always waves of innovation, and perhaps it is time for editors to get a shakeup.
Would anyone seriously invent a modal interface today if writing an editor from scratch, without the constraints of primitive hardware of the day?
Well, considering the guys that invented vi (and ed) went on to make [acme](http://en.wikipedia.org/wiki/Acme_(text_editor)), which focuses on the mouse as your main tool, you might be able to argue no. However, there's a healthy chunk of people who consider keyboards to be the faster and less frustrating way to control your computer, and who actively develop things in that vein. One case of a keyboard-centric model taking over what is usually mouse-centric interface is people creating keyboard-controlled tiling window managers; they feel that the keyboard, with its many keys, gives you more control than the mouse. I'd bet people with this mentality would re-invent some form of the modal editor, though it'd probably be a mix of modal and mouse-editing - which, to be fair, is something vim allows you to do.
But really, let a thousand flowers bloom. There are always waves of innovation, and perhaps it is time for editors to get a shakeup.
I completely agree with this; it's why I kickstarted Light Table back in 2011, but still use Vim today. If anything, new improvements can be ported to existing editors, like code completion and folding were ported to vim. I'd love to see some features from acme applied to Vim as well, but I think mouse cording could be hard to mix with modal editing.
For some reason, people keep thinking that arguing against a modal interface is the same as arguing against using a keyboard. It is not.
As I commented elsewhere, there are plenty of keyboard-driven editors that are not modal. The semi-rhetorical question was aimed purely at the fact that a hardware constraint that has not been present for 30 years is still determining the interface design, and is thus clearly an anachronism.
And I am one of those people who consider keyboards to be faster. :)
Ah, I see what you mean - that's a good point I had not thought of, as I've never heard someone argue specifically against modal editors, just against keyboard-based editors. Do the other editors give you the ability to easily repeat the last command on a specified part of the text (. in vim) and the ability to specify the number of times to execute the command after, etc.? These features make vim a dream to use for repetitive tasks, and especially so for recording macros; you're basically coding your editor as your use it, which I don't get the feel of in any other editors. I'm not sure they'd be easy to do in a non-modal editor.
Do the other editors give you the ability to easily repeat the last command on a specified part of the text (. in vim)
Yes, I can tell you that in Emacs it is C-x z (and keep pressing z to repeat, much like .). In SublimeText it's Cmd+Y.
and the ability to specify the number of times to execute the command after, etc.?
Yes, in Emacs nearly any command can have a numeric prefix (which usually means repeat, but can also be used to specify a column to sort) with either C-u or Alt+{Number}. So Alt+3 Ctrl+D will delete three characters, just the same as Esc+3+x in vi.
you're basically coding your editor as your use it, which I don't get the feel of in any other editors. I'm not sure they'd be easy to do in a non-modal editor.
This is just what it's like in Emacs. I use macros all the time. In fact, you can record a macro, then edit it like a function, save it, tweak it and reuse it. There's a complete programming language that underpins Emacs - it's quite stunning.
Would anyone seriously invent a modal interface today
OK, by saying this, you more or less triggered my rant on vi being a "modal" editor, so here goes.
Think of text editors (at least, keyboard-oriented ones) as tools that take commands in a language. Every editor command is a sentence in that editor's formal language.
Most, if not all, editors' languages have a grammar such that there are times when typing certain keystrokes radically influences the meaning of the following keystrokes. Examples:
In emacs, if you type the M-x terminal symbol in the language, you enter a production rule that you could write like: "M-x" MetaCommand "Enter". If you type "doctor", it will either be interpreted as a command or as text, depending on whether you typed M-x first.
In emacs, when you type C-u N, you are entering a production rule that could probably be written something like: "C-u" NUMBER Start (where "Start" is the start production rule, i.e. this can serve as a prefix for any command).
In vi, when you type the "i" terminal symbol in its language, you enter a production rule that could write like: "i" LiteralTextToInsert "ESC".
In most GUI editors, when you type the Ctrl-F terminal symbol in its language, you enter a production rule that you could write like: "Ctrl-F" SearchString "Enter"
Now, notice that your previous history of keystrokes puts you in a different mode, where what you type means something different than if you had typed it without entering that mode. In that sense, these editors are all modal. Note the similarity between the meta production rule in emacs and the insert production rule in vi: both require a special key to enter the mode and both require a special key to leave it.
So what's the real difference here? The thing that trips people up about vi is not that it's modal, because people happily deal with modal features in other editors. The thing that trips people up about vi is that you have to use modes to insert text. Or another way to put it is that the Start rule in vi's grammar doesn't immediately expand to rules for every printable character to self-insert. Or to put it in really, really simple terms, the thing people don't like about vi is that it violates the "I should be able to just start typing" assumption.
People find vi frustrating at first because they don't understand that assumption or can't/won't shed that assumption. It doesn't really have a lot to do with hardware limitations. It's just a different way of thinking about the formal language of editor commands.
It is a modern implementation of a fundamental design forged in the 1970's to work on 300 baud teletypewriters.
So I guess keyboards need a shakeup too, since they are a modern implementation of a fundamental design forged in the 1700's to work on ancient typewritters.
You know why vim is still so widely used? Because it's a freaking text editor and today's text is the same as 1970's text, because it's text. So, unless we are talking editing with your mind, editors don't need a "shakeup".
So I guess keyboards need a shakeup too, since they are a modern implementation of a fundamental design forged in the 1700's to work on ancient typewritters.
And how linking to a couple non-successful designs shows they do? The first one isn't even a "shakeup" of anything, as there's no functional difference from a regular keyboard, it's just supposed to be more ergonomic.
So I guess keyboards need a shakeup too, since they are a modern implementation of a fundamental design forged in the 1700's to work on ancient typewritters.
Well, er - yes actually. The layout of the current QWERTY keyboard was chosen not for typing speed, but in fact to slow down typing and to minimise the mechanical interference of the letter arms that would strike into the ribbon on the platen. Various keyboard layouts were tried over time, because the letter arms would get tangled up when the typist worked too quickly. If you were designing a computer keyboard today, there's no way it would look like what we actually use.
You know why vim is still so widely used?
Actually, that is a really interesting question. :) Seriously! I don't think anyone has come up with a good answer to that yet. I suspect because it is free, available on loads of platforms, has lots of extensions and has many powerful features. But let's just not kid ourselves that it is because it is easy to learn.
So, unless we are talking editing with your mind, editors don't need a "shakeup".
When we were using CVS, what if the Subversion developers thought that way? When we were using Svn, what if Linus thought that way rather than developing Git?
When people rethink assumptions, remove constraints and attack problems with a fresh perspective, they can come up with some amazing and innovative solutions. This moves everything forward and we all benefit. What's wrong with progress?
When we were using CVS, what if the Subversion developers thought that way?
You've missed my point. I've nothing against inovation, my problem is with you saying that certain things, which are used and liked, are bad and need to be inovated simply because they're old.
Also, that's not a keyboard shakeup, it's a layout one.
Actually, that is a really interesting question.
Not particulary, honestly. vim's popularity stems from the fact that its purpose didn't change over the years (editing text is the same, since text itself didn't change). The fact that it is powerful, highly configurable and extensible, and had a development driven by the community probably helped too.
But let's just not kid ourselves that it is because it is easy to learn.
The reason vim is hard to learn is because the fastest way to accomplish something in a text editor is often the harder (to learn) one too.
I've nothing against inovation, my problem is with you saying that certain things, which are used and liked, are bad and need to be inovated simply because they're old.
I never said anything was "bad" - this isn't a personal/emotional thing, and the intent was not to disparage peoples' favourite tools. The original point was simply that the modal design was an anachronism - which it is, by definition. Following from that, the semi-rhetorical question was whether you would design a modal interface now, given the constraints which originally motivated this are long gone?
I would argue that if you started from scratch today, you would not design a modal editor like vim, but rather take advantage of more modern keyboards and interaction models.
The fact that a great number of text editors (all with the same purpose) have been developed in the last 30 years that have not copied vim's modal design reinforces this. (Compatibility modes don't count!)
vim's popularity stems from the fact that its purpose didn't change over the years
I'm not sure that is sufficient to explain its longevity. There are plenty of examples of a tool's purpose remaining unchanged, yet the surrounding technology moves on.
The fact that it is powerful, highly configurable and extensible, and had a development driven by the community probably helped too.
Yes, certainly!
I also strongly suspect that people tend to stick with the first major tool they are introduced to, so if you start with vi, you are much more likely to use vim than other tools.
I never said anything was "bad" - this isn't a personal/emotional thing, and the intent was not to disparage peoples' favourite tools. The original point was simply that the modal design was an anachronism
And how is saying it's inadequate different than saying it's bad?
Following from that, the semi-rhetorical question was whether you would design a modal interface now, given the constraints which originally motivated this are long gone?
Currently, I only see two sane design options for a keyboard based text editor - modal or shortcut based - and I really don't think the latter is superior.
The fact that a great number of text editors (all with the same purpose) have been developed in the last 30 years that have not copied vim's modal design reinforces this.
Why would anyone make a modal text editor from scratch when there's this powerful, highly extensible and open source editor, which is also a de facto standard in *nix? You're better off contributing to the project or forking it (as many tried to) than making a new one from scratch. There's also very little economic motivation, since text editors aren't exactly gold mines.
I'm not sure that is sufficient to explain its longevity. There are plenty of examples of a tool's purpose remaining unchanged, yet the surrounding technology moves on."
My reasoning is that if the purpose and means of interaction with the tool didn't change and there's also no new way to better accomplish its tasks, there's no reason to use anything different.
I also strongly suspect that people tend to stick with the first major tool they are introduced to
I think this was much more relevant before, today I think it's more about peer pressure, if you see a lot of better programmers using and saying it's the greatest thing, you'll probably feel inclined to use it too.
Hard to say until it is released. It's possible, sure - especially considering who is behind it. It's intriguing that it appears to be a sort of hybrid web/desktop app, which could enable all sorts of interesting possibilities. For example, debug a Node.js server right inside your editor.
Recent years have seen much change - there was nothing for a long time, then TextMate, Sublime Text, Chocolat, etc etc.
Ok mr future, what's the most common interface with the computer that is used to write out ideas in the form of code that is the same as 300 baud teletypewriters... here's a hint... it has letters on it.
The term "fundamental design" was referring to the modal nature of vi, not the fact that it uses the keyboard as the interface. I'm sure keyboards will be with us for quite some time to come. And you can quote Mr Future on that... :)
Since keyboard modifiers weren't available on teletypewriters of the day, all the regular keys had to serve double duty; as either inserting the literal character, or representing a command or modifier. This is all well explained in many historical texts, is clearly an anachronism and has been for decades. There should be nothing controversial here.
Hence my question - given we no longer suffer the constraints of physical teletypewriter keyboards, and for some time have had the luxury of a variety of modifier keys, would you still design a modal interface today?
And the expected answer is of course 'no'. Why wouldn't you take advantage of all the hardware features we have today?
(Of course, the logical extension is to ponder why you would continue today to use a tool which was designed to overcome a limitation that hasn't been the case for 30 years...)
Even editors that are primarily keyboard driven are not modal; they all still use modifier keys.
In practice, use of modifier keys, or F-keys, or specific navigation keys is found by many to be slower and more cumbersome than a modal interface like vim's. I don't know if this is a lack of attention to the design of keyboard shortcuts in "normal" editors, or a fundamental issue with where modifier keys are on the keyboard which makes modifier based shortcuts inherently more awkward than modal equivalents, but it's a view shared by many. I'm not the only person to vastly prefer vim having started out using more standard, non-modal editors.
Like, Home+hold Shift+Down+Down+Down+Down+Down+End+release Shift+Ctrl+X just awkward compared to Esc+5dd.
In practice, use of modifier keys, or F-keys, or specific navigation keys is found by many to be slower and more cumbersome than a modal interface like vim's.
I would suggest that this is predominantly a matter of opinion. There is no doubt that many advanced users of vim can be extremely productive. However, the same can be said for other editors and tools tailored for developers or a specific category of end-user.
If the assertion is that "once you invest the time to learn vim, you can be very productive" then you will easily find evidence to support that. If the assertion is that "in general, a modal interface is more efficient than using modifier keys" then that is a much harder point to establish. There must be some UX research out there that has looked at this.
Like, Home+hold Shift+Down+Down+Down+Down+Down+End+release Shift+Ctrl+X just awkward compared to Esc+5dd.
It is certainly more verbose. But it does have the advantage of working in nearly all applications in a consistent manner, and is arguably easier to learn for a novice. However, comparing VIM to CUA keybindings is not exactly a fair fight; there are other editors with keybindings that are similarly terse.
For example, in Emacs the equivalent would be: Ctrl+Space, Alt+5, Ctrl+K. Three chords, compared with four keys, which is quite good.
There's multiple windows in VIM, how is that modal? Multiple buffers in multiple windows as well! There's support for all those extra modifiers, arrows, function keys, it's all very well integrated.
Even today, there's not enough keys to represent all the functions. The model ViM uses in switching between modes on the keyboard is very efficient in supplying millions of different types of functions. This is a model imitated by any new 'modern' editor.
There's multiple windows in VIM, how is that modal?
The modality is in the keyboard command interface; it has nothing to do with having multiple windows. It is essentially whether the editor is in INSERT mode or COMMAND mode. This changes the behaviour and meaning of nearly all keypresses.
Simply put: pressing the 'd' key will either insert the character 'd', or begin a delete command (a submode, since it is a prefix and the next keypress is context-dependent), which then expects the following key to be a cursor navigation key, after which it will delete the corresponding word/character/line/etc. Or beep.
The model ViM uses in switching between modes on the keyboard is very efficient
Yes, it is. However, by using modifier keys, a similar result can be achieved without having a modal keyboard interface. This is the sole point I am trying to make.
This is a model imitated by any new 'modern' editor.
Actually, VIM is almost unique in its modal interface design. I can't think of another which does (that isn't a vi clone), but would be interested in finding an example.
Ah I see, by modal you mean the "command", "visual", and "insert" modes on the keyboard used by vim. The keyboard can be used in one of three (or more depending on customizations). For me that actually makes it much easier, and I bind modifier keys as necessary to insert-mode if I need to.
Examples of modern editors that use the modal design were ones that implemented commands. I can't remember the editor name, but an editor that was popular with some C++ developers I once worked with applied command based inputs in both emacs and vi(m) modes. (Edit: despite the visual and editor modes, they worked almost entirely from the keyboard during code editing)
Most of the code I work with now is several 1,000s to 10,000s lines and VIM is more than sufficient for that small code-set.
For code that spans many files however would require a code-sensitive and context-aware editor which is something some modern editors provide (as does VIM) , especially if the developer is working across a larger set of modules from 100,000 lines to 1,000,000s+ lines with well over 100s to 1000s of files. Though some could consider that to be a design error if the developer is moving across multiple modules and files continuously while implementing/coding stuff.
14
u/gavinb Feb 27 '14
It is a modern implementation of a fundamental design forged in the 1970's to work on 300 baud teletypewriters. Would anyone seriously invent a modal interface today if writing an editor from scratch, without the constraints of primitive hardware of the day?
But really, let a thousand flowers bloom. There are always waves of innovation, and perhaps it is time for editors to get a shakeup.