Hacker News Reader

Comment by JulianWasTaken | 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.

View on HN

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.

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.

Reply on news.ycombinator.com