Hacker News Reader

> Modern editors can do 99% of what a 3+ year expert in vim can do, but you can get to that 99% in a month or less. Just because you had to spend three years of your life to get to your current level of productivity doesn't mean you should haze new developers the same way.

I don't begin to believe this statement, not least of which because 99% of what you can do with vim or emacs is make vim or emacs do what you want by heavily scripting them. That eliminates most "modern editors" right off the bat.

Agreed. But though I'm a vim user, in day-to-day coding, my colleagues using say sublime don't see to suffer all that much. I occasionally see them doing something a bit inefficient with the mouse that could have been a few keystrokes in vim, but it's not that big of a deal really. Now, there are definitely a lot of things I could do in vim with macros and such that would be impossible to do efficiently in sublime. But I rarely have to do such complex text manipulation, so does it matter all that much?

As far as scripting your editor, most IDEs have some sort of plugin system, which you may not use yourself, but you'd use to find something that already roughly does what you want. To be honest, that's pretty much what I personally do with vim myself, relying on others' vimscripts to get me the functionality I so crave, whether it be indentation-based text objects, or in-editor s-expression evaluation.

I use vim macros frequently. It's not that I'm doing something complex, but that I'm doing something repetitive. Having such an easy way to create macros on the fly means that I never have to do repetitive editing. (How important that is depends on the language; in SQL, for example, it's a huge help.)

:norm is a lesser-known trick that also helps quite a bit.

I use Visual Slickedit, Notepad++, and Visual Studio macros frequently. I typically map them to ctrl-f11 (record/stop recording) and ctrl-f12 (playback). In all three editors, I can just record, hit keys, stop, and playback (as many times as I hit the key). Notepad++ and Slickedit both offer you the option of binding the macro to a key more permanently too.

As I mention in this other comment [1], vim and Emacs hardly have a corner on the macro market.

:norm looks powerful, yes. But when I want to do something like that, I create a regex search that matches what I want and then record a macro that includes the "search next" key. Not quite as nice, because I have to keep hitting the "play macro" key, but gets me 95% of the way there.

More complex (or numerous) transforms just become a script that I run on the file. But that's an extremely rare operation for me. For me it comes down to the fact that saving the 5 minutes to set up that script, once a year when I need something that complicated, would take a crazy long time to amortize over the three years it would take me to become that good at vim.

[1] https://news.ycombinator.com/item?id=5696927

I'm not arguing that other editors aren't powerful. I have less experience with others in any case. But vim does work well. A simple example I show off to coworkers:

FirstName MiddleName LastName

converted to:

a.FirstName = b.FirstName, a.MiddleName = b.MiddleName, a.LastName = b.LastName,

To do 20 iterations of that, you can hit qw, do the first with the same commands you use all day, stop recording and hit 19@w for the rest. The whole thing flows into your normal editing so easily you barely think about it. You build macros as you go for tiny little repetitive actions that aren't worth the bother to write a script for, or that you may never use again. I don't bother saving my macros, and I've barely touched vimscript.

I wouldn't say it takes anywhere near three years to learn that either, more like six months. After a week or two you stop going insane, and have basic Notepad-level competence. Then you just gradually add keystrokes, and each one makes you a little more productive.

I can do that pretty trivially in any of three editors as well. I just did it now in about 20 seconds, just as a proof of concept.

I don't get the "repeat count" functionality that I know comes for free in vim, but at the same time, I rarely know HOW many lines I need to apply a macro to, and so just letting key-repeat take over until I'm almost done works for me. There are also times when the macro works on blocks of text, but there are occasional line breaks that would break the macro, and repeating until I get to a line break, skipping it, and then proceeding is easy.

When I AM in vim and I need to, for example, delete some large number of lines, I find myself trying to guess how many lines, but guess on the small size. Then I guess again, until I get close enough to see the exact number.

I probably should use "visual" mode more often for that particular task, but the point is that being able to repeat a macro an exact number of times is (for me) LESS useful than just being able to use key-repeat at 10/second until the task is done.

When I AM in vim and I need to, for example, delete some large number of lines, I find myself trying to guess how many lines, but guess on the small size. Then I guess again, until I get close enough to see the exact number.

That's my biggest issue using vim, the need to count lines before every operation. I keep getting the feeling I'm doing something wrong when I do that. Sometimes I just break down and use visual selection mode to select the text and delete the whole group, much like I'd do in another editor.

Is there something I'm missing about having to count before doing operations in vim?

Usually, yes. I never count.

There's a lot of alternatives depending on what you're counting. If you're deleting a block of lines say, usually it's not just some random block, and so usually you want some more targeted motion. Like e.g. d} or d[m for an exotic example. Or d/stuff if you're lazy, like I often am.

There's also `relativenumber` for when you really do need to count, but I'm ambivalent on whether I like it.

And sometimes you just want `.`. It's dirty, but sometimes it's quicker. I like to basically always be typing every time I have a goal in mind. So I never want to be thinking really for too long once I've decided where I want to get. So I'll do dw... once in awhile.

So yeah, it depends.

    :set relativenumber

shows… line numbers relative to the current line allowing you to:

1. find the last line of the block you want to operate on

2. see the number you need to use

3. use that number

Motions and text-objects are very useful as well:

    dip
    da{
    d{
    d/foo
    d?bar
    d'a
    d]m
    …

Most modern IDE's I've worked with are easily extendable. At least, as easily as learning to use something like vim script and extending that way.

>I don't begin to believe this statement, not least of which because 99% of what you can do with vim or emacs is make vim or emacs do what you want by heavily scripting them. That eliminates most "modern editors" right off the bat.

Every single "modern editor" I'm talking about is scriptable, and they're scriptable in languages that are easier to code in than vimscript (which is infamously awful) or Lisp. Some are even scriptable in positively awesome languages.

Not sure what "modern editor" you're talking about. See:

Notepad++:

http://sourceforge.net/p/notepad-plus/discussion/1290590

Visual Studio: You can record a macro and get code that you can then edit, adding loops and logic and such, and then play back the macro. Or you can extend it in an arbitrary way:

http://msdn.microsoft.com/en-us/vstudio/ff718165.aspx

Visual Slickedit: Half of the app is written in its own custom C-like scripting language. Similar to Visual Studio, you can record a macro and edit the resulting source code, so you don't have to guess how to start creating a script.

TextAdept: Scriptable in Lua.

http://foicica.com/textadept/

TextMate: "Plug-able Through Your Favorite Scripting Language"

http://macromates.com/

Sublime Text: "Sublime Text has a powerful, Python based plugin API. Along with the API, it comes with a built in Python console to interactively experiment in real time." -- This one I haven't used, so I can't be CERTAIN that you can write-and-use scripts immediately and trivially, but it certainly sounds like it.

http://www.sublimetext.com/

NEdit: "NEdit is extensible through a C-like macro language"

https://en.wikipedia.org/wiki/NEdit

SCIte: "In addition, the Lua programming language is embedded in SciTE, allowing the user further customization. One can write Lua scripts that have access to the contents of the buffer and the Scintilla API."

https://en.wikipedia.org/wiki/SciTE

I've been clicking on random ones in the WikiPedia article on text editors [1], and except for the editors that "come with the OS" (Notepad, etc.), every one I checked had scripting. I actually clicked on SciTE to give a counter-example, since SciTE is mostly a proof-of-concept for the Scintilla editor library.

I would have to say, given the ubiquity of scripting languages in editors, that you haven't LOOKED for scripting in other editors. Which is FINE, but You Do Not Know Of What You Speak (TM).

Even if you can point to some that don't have scripting, it doesn't matter. Plenty do, and scripting is important to me as well. The crucial thing for me is the ability to quickly record and play back a macro; I wouldn't use any editor long term without that feature.

You really can't win this argument. I've traded blows with many extremely experienced vim users, and for every transform that's easier in vim than in another editor, I can come up with three more transforms easier in one or more editors I know. And the real win of using a modern editor is that the core keys (arrows, shift-arrow to select, control-arrow to jump by word, etc.) also work in thousands of other GUI apps, so you don't have to mode shift to be reasonably productive in a Firefox text box, for example.

[1] https://en.wikipedia.org/wiki/List_of_text_editors

> And the real win of using a modern editor is that the core keys (arrows, shift-arrow to select, control-arrow to jump by word, etc.) also work in thousands of other GUI apps, so you don't have to mode shift to be reasonably productive in a Firefox text box, for example.

That's key to how I work. In a typical day I jump around between Komodo, IntelliJ IDEA, Visual Studio, UltraEdit, XML Marker, MarkdownPad, Araxis Merge, Word, Google Docs, Notepad, Evernote, and a few other editors. Thank goodness basic editing works the same in all of them!

Quite often I'll have the same file open in more than one editor and do some of my editing in one and some in another. I can save changes in one of the editors, switch to another, and it loads my changes and I pick up right from where I left off in the other editor.

Why would I do this crazy thing? One example: if I've got a file open in Komodo or IDEA or whatever and I'm ready to commit it, I always diff it first in Araxis Merge. I'm likely to make some final changes to the file at that point. (Left in a console.log, anyone?) I can make those changes in Araxis or in the other editor I'm working in - and it doesn't matter which, they both work the same and pick up each other's changes.

So, I don't have to take sides in any editor wars: I use a bunch of 'em! :-)

To add to your scripting list, Komodo is scriptable in Python and JavaScript, with a pretty thorough object model you can use from either language.

You are absolutely correct that "you can not win this argument." But for a reason you are not touching. This is a preference. Almost pure and simple. The idea that someone's preference in editor is enough to make them a good or a bad programmer is borderline laughable.

This is akin to arguing that someone should consider switching to non-stick pans for all of their cooking. Because, think of all the time wasted cleaning a pan. Well... for experienced cooks, this really isn't any time that needs saving.

Only if you define "good" and "bad" user interfaces by discoverability. I would argue that Vim is a tool that explicitly trades off discoverability in favor of enhancing the productivity of an experienced user. And I would argue that in the case of Vim, this is a good tradeoff. It's not a good tradeoff for a microwave or VCR.

No, that's only a piece of the puzzle. See my other comments in this thread.

    Both vim and Emacs have interfaces designed before any
    serious work was done on human interface design, and like
    the microwaves and VCRs designed back then, their
    interfaces are measurably, objectively terrible.

How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus?

Also, when we talk about "measurably, objectively terrible" interfaces, were the measurements made by researchers whose test subjects all had 120+ IQs? Those would be the only measurements that interest me.

>How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus?

Off the top of my head, though my depth of knowledge of Emacs is almost more shallow than that of vim:

1. Discoverability. I had to reverse engineer Emacs' basic key commands, due to a complete lack of documentation on the first system I encountered an Emacs clone on; I was able to do it, but I have a considerably higher IQ than 120, thank you.

2. Key combinations are somewhat random. Some have mnemonics; most don't. Saying "change the keybindings, then!" is beyond the point; I'm talking about the editor UI as a new user would learn it, and by definition a new user doesn't know what keys things "should" be assigned to.

3. LISP, the write-only language. There's a reason the 1950s-designed language hasn't ever caught on. PG forgive me. Languages like Lua grant you 95% of the power of LISP, but are much more readable. And the last 5% is part of the cause of the readability problems of LISP.

4. Sometimes a mouse IS the right answer for some tasks. In an editor, this is MOSTLY not true, but when it is true, it's powerful.

5. Modern standard keybindings DO EXIST, and neither are supported by vim or Emacs out of the box. Ctrl-ZXCV, for example, will be expected by 99% of users to do the standard things. (If someone reading this is so Unix-centric they don't know: Undo/Cut/Copy/Paste.) Shift-arrows for selecting text. Shift-Control-Arrows for selecting word-at-a-time. Etc. Both Emacs and vim are (nominally) terminal-based, and you can't GET those key combos over a terminal.

6. Two-key combos that AREN'T shift keys for important commands (M-w). 'nuff said.

>Also, when we talk about "measurably, objectively terrible" interfaces, were the measurements made by researchers whose test subjects all had 120+ IQs? Those would be the only measurements that interest me.

I already commented on my own IQ, and I find it to be an irrelevant comment. A better UI tends to be better for any IQ. Do you really want to be using your IQ to decode your UI, or would you rather not have to think about it and instead think about the problem at hand?

I'm not talking about a dumbed-down, feature-poor UI. There are very few features anyone can point to in vim or Emacs that I haven't seen, typically way more easily accessible, in modern editors with decent UIs (I don't know of any with a really good UI, but most are better than their ancient ancestors, though I haven't done a complete survey recently, and so I should again).

And remember, I already said this is mostly irrelevant if you already have learned vim or Emacs. You've put in the time, and suffered the pain of their steep learning curves. You're past the hard parts. Enjoy your editors; I'm not trying to get you to change what you use.

To be honest, I'm not really interested in debating particulars. I'm sure you'll find SOMETHING to pick at in the list above; I know you CAN use cua-mode to get some basic standard control keys. But when a new user starts with Emacs, will they know to enable cua-mode?

The killer for me is that LISP just makes my eyes bleed. I've used it (in college) to create research apps, but I never liked it.

> LISP, the write-only language.

Utterly wrong, which discredits a lot of the other things you said. In particular, it discredits any claim you have to objectivity.

Hey, I have opinions, too. I don't claim they're objective fact, which you do.

> I'm not talking about a dumbed-down, feature-poor UI.

Yes, you are.

> "good user interface shouldn't require instructions." (-- Donald Norman)

I assume you are taking Mr. Norman here out of context and vastly simplifying his position because the naive, simple reading of this statement makes him sound like an idiot. Humans require instructions for everything... "The only intuitive interface is the nipple. After that it's all learned." -- origin disputed

Umm...he's clearly not an idiot. Check his CV if you don't believe me.

But he does say that.

There are two possible conclusions:

1. Despite all the evidence to the contrary, he is in fact an idiot.

2. I'm quoting him out of context. I took classes from him at UCSD. Maybe I didn't understand him. But maybe I did.

3. You don't know enough about his philosophy to understand what he means, but he really, really does mean that. Not "in context," but always.

Now despite my respect for him, I think he does gloss over the power user UI when he says that. He has an entire book on how bad the Unix command line is, and yet there are some things I wouldn't want to use a GUI for. But I'm not a typical user; probably very few people on HN are.

Think about the "Principle of Least Astonishment," though. [1] The more things that work as you expect, the better an API or language is, right? The same should be true of an editor.

I know that in vim you can reuse your knowledge in many ways, but it's all restricted to the vim environment. You can hack that environment onto a command line; maybe even hack it into Firefox text entry boxes. But there are dozens of apps that won't have that ability, and you'll be handicapped in all of them. And there are millions of people who know how to use CUA keyboard shortcuts, and for them the PLA says to have the basic controls use CUA standards.

[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

>But there are piles of UI design research studies that show modal interfaces are, in fact, bad.

>Objectively bad. Measurably bad.

Yeah but that's because modes are more or less tautologically defined to be bad. As long as there was a big blinking sign that said "normal" or "insert" vi(m) wouldn't be modal; see the raskin quotes elsewhere in the thread.

Incorrect- don't read quotes to get the meaning of what Raskin wrote. READ HIS BOOK.

1. Objectively bad not by definition, but by MEASUREMENT. and Experiment. Yes, UI quality can be objectively measured. Read the book.

2. That wouldn't fix VIM's problems. it would make them worse. READ THE BOOK.

Curious, is there by any luck a study on veteran vim users in particular? It seems like the quality of execution + the familiarity of the test subjects with the UI and modes available would make a huge different in any such measurements.

Vim definitely sucks when you start, especially in terms of discoverability. You have to learn by either reading the colossal manual, or (as most do) using bits and pieces from external sources. But once you learn enough and gain the muscle memory and understanding of how to use the different modes best (eg in vim's case, normal should be your default state), it becomes wonderful to use.

Depending on which measurements you are talking about, experience is largely irrelevant- as most of the "objective measurements" we are talking about, are about the quality of the UI itself, not the specific quality of the user.

here are some http://en.wikipedia.org/wiki/GOMS http://en.wikipedia.org/wiki/Fittss_law

Regarding modes, I encourage you to read this 1973 study, which spawned the first modeless text editor.

http://www.nomodes.com/Larry_Tesler_Consulting/1973_User_Stu...

I wish I had ready access to the piles of studies that show modal interfaces are bad. I trust they exist. I just haven't seen them myself!

Am sorry, i just have to reply to this. Disclaimer: I use vim. Anti-disclaimer?: I spent two years studying cognitive science and one of my electives was HCI.(though i wasn't excited about it to be honest :P)

By measurement of what? UI quality? what is it's operational/measurable definition. I suspect modes are unavoidable to deliver the kind of power vim does (over text editing )with only keystrokes.

P.S: That said, i think it's a very sad thing that we can't have that joystick at the centre for the keyboard(in the home row, like in thinkpads) for all laptop keyboards.

It's quite a simple matter to measure /rates of error/ in modal interfaces versus non-modal interfaces. This may seem trivial for text editors in particular, but modal errors are a big cause of aeronautical accidents (and deaths), so even one error is too many in that case.

And if you can avoid errors in cases where they are life threatening, why wouldn't you want to avoid errors everywhere else?

I agree low error rates are the most critical quality measure in aeronautical accidents. Am just not sure i would use that measure for text editors. If i have to operationalize my previous comment, i would say, i care about the amount of time i spend hitting the keys compared to the amount of time i spend moving around the mouse.

I suppose that's not what everyone wants and in the examples the OP gives he has a point.I agree completely on the car audio part, not sure about photoshop(not much experience designing), but have some frustrating experiences with photoshop to suspect he's right.

Raskin... wasn't he the one who said configurability is evil and shouldn't be allowed?

Yep. And he was correct when he said that. And he is still correct.

And how did Raskin, who I have never met and who is dead now anyway, know my mind well enough to know how I work best?

Interface design is not an entirely subjective thing as you imply. Humans have way more in common with each other than you are willing to admit.

Also you know, Raskin invented quite a lot of things you've probably never complained about. Like click and drag to select text, dragging and dropping of icons. double clicking. UNDO.

> Like click and drag to select text, dragging and dropping of icons. double clicking.

All idiotic ideas.

> UNDO.

An obvious invention. Not one requiring much thought, only the resources to implement it.

But see, here is the thing. I was not arguing for modes, per se. I was definitely not arguing for vim. Just had to acknowledge that I use it.

I do think that quote is taking great liberties. The best user interfaces came with mentors. I would go so far as to argue that vim sucked for me, as I did not have anyone to ask for help. Indeed, I was a heavy eclipse/idea/various other user for a good 8 years before I really got into vim. Probably the only reason I did so was because I was a remote worker for a while with a connection too slow for any graphical forwarding. Then, eclipse went through a garbage period where it was too slow or just crashed a lot. (My understanding is that it has improved, greatly.)

But, back to my argument. Modes are bloody everywhere. Want the car to go forward, put it in the correct mode for the accelerator to cause that to happen. Backwards? Similar. (And no, I'm not even talking about a manual transmission.)

Consider cooking. Want to make an omelette? Well, start by heating the pan. Depending on the cooktop you have and the pan you have, this will take a differing amount of time. Then, add the ingredients. Make sure to add enough, but not too much, salt. Want to know how much is too much? Well, practice. Experiment. There is absolutely no indicator for this.

Moving over to writing. Make sure you are holding the pen/pencil the correct way. And on the correct surface. (Anyone that thinks these are obvious things hasn't had to teach kids to draw on a piece of paper.) (This goes back to my "mentor" idea.)

Now, move on over to music for a minute. What do you mean the instrument has to be in tune? And you typically have to use both hands? Often with a foot pedal? Clearly humanity should have given up on that endeaver years ago.

(Do I need to even discuss sports?)

Which brings me to what I think is my point. Modes are something that adds difficulty, for sure. But life is not about making all things easier. For many, that challenge can help add appreciation to what they accomplish. The goal is not to eliminate modes, but to make sure users can accomplish what they want. Mainly by addressing the majority case, not the fringe ones.

"Changing the bass" setting of your car stereo is something 99.999% of the populace doesn't give a crap about. It is not that they wish to have no way to do it, they just don't care. Having the interface revert back to "change the station" after an interval of no use makes perfect sense in that regard. Why not bitch that your phone will revert to a "locked" state after a period of no use? You can argue that they just need a screen with more information on it, so they can change bass and station at the same time. Yet, my hypothesis would be that that is exactly backwards. Most people only want in front of them what they need to accomplish what they are doing.

A lot of your examples aren't "modal human interfaces." They are examples of the state of the world, or the state of the human in question.

There's no question that you need to be aware of the state of the world. The position of a pen isn't an interface; the pen itself isn't modal. The "interface" to a pan is its handle. The "tuning" of an instrument isn't an interface; the strings are (the mode of a synth makes it modal, certainly, but I'll get to that).

There are some interfaces that are easily mapped by humans, though. The forward/reverse setting in a car is one of them. I don't doubt that many accidents have been caused by that modal interface, but it's still better than any other interface for that task than any other I can think of. You don't WANT the user to be able to just start driving backward without going through a specific (non-normal-driving) action to put the car into that mode.

The keyboard example is the same: A modal interface that makes sense. You have limited resources there: Most musicians can't afford to have a separate keyboard for every sound they want a synth to make.

Even Photoshop is a "necessary" kind of modal interface, because Photoshop isn't representing a user doing a single task: Photoshop is a simulation of dozens of potential "brushes" or effects, and it's far more economical to use the same interface (the left mouse button) to control them all.

It's all about cognitive mapping: A good UI for a stove has the controls arranged in the same physical orientation as the burners. Four burners in a square? Four controls in a square. No instructions necessary (to anyone with even a rudimentary idea of how stoves work).

But the different "modes" of anything are just the state of the input mechanism. To be clear, my argument is not to use modes for the sake of using modes. More that I do not understand the attitude in computer design where it is assumed that we can get down to no modes in an interface. There is this magical "all context switches to get here do not count." That is, it is a fine guideline, but treated as its own independent rule is missing all of the conflict and tradeoffs that actually go into many decisions where they arise.

Editors are an amusing example, because they come up a lot. But, for many, getting the computer to the damned editor is enough of a mode change that it is hard to do.

With GUI applications, the march lately has been to hide as many of the "buttons" as possible. Which is not really doable while still adding buttons. This is the same problem as faced by car interface designers. Even the iPod did this. "Spinning" back then was either selection or volume control, you know, depending on the mode. :)

So, yes, I agree excessive modes are bad. I even agree that vim is a bad interface for most folks. (Most being everyone else I know that uses a computer, honestly.) I disagree that "modes are bad" is at all a useful mantra by itself. It is only helpful when you take all of the other context into consideration, as well.

That make sense? (As far as the "better" interface for a car, this one is easy to imagine. Come up with an interface where you really just tell the car what it is you are wanting to do. "Take me to the store." "Pick up my daughter from school." ...)

According to this, Vim isn't modal:

> The definition of modes given by Jef Raskin in the Humane Interface (Page 42):

>>"An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state."

> According to this definition an interface is not modal if the user is aware of the current mode at all times.

https://news.ycombinator.com/item?id=5696227

But the real problem here is that the people citing to Raskin are trying to treat their opinions, which are no better (or worse) than mine, as objective fact, and claiming others are stupid for not instantly falling in line.

> But there are piles of UI design research studies that show modal interfaces are, in fact, bad.

Then how do Vim users work? If they're doing something that doesn't let them work, how do they work?

Or is that not what you were saying? Then what the Hell were you saying, and how is it relevant?

It is fully possible for humans to adapt to terrible computer interfaces. That doesn't mean the interface is not terrible, it just means that humans are adaptable.

So humans who do that don't know their own minds? They're too stupid to know what a good UI for their style of thinking is?