Hacker News Reader

Comment by eftpotrm | Hacker News Reader

Flame suit on, but I really don't understand the appeal.

I have reams of arcane bits of information to commit to memory already. .Net in two languages plus VB6 for legacy code. SQL in more dialects than I care to list, each with their own quirks and limitations. HTML and JavaScript. XML and various associated technologies like XPath. That's just professionally; once I go home I can add in photography and music straight off with others at different levels.

There's only so many things one can usefully commit to memory (edit - yes, I meant am prepared to dedicate the time to committing to memory); odd bits are just easier to look up. So why, exactly, should I voluntarily use a text editor whose interface was already far behind the state of the art when I started school?

:q!. I've had others try to persuade me of the joys and power of vi; I'm not even slightly convinced and that is the one command I'm committing to memory.

View on HN

"There's only so many things one can usefully commit to memory"

That's similar to not learning English because the dictionary is too large to memorize.

As jvanenk says elsewhere in here, it's muscle memory, not memorization. You don't "remember" how to walk or use a pencil, you just think about the goal (move body over there, write sonnet) and muscle memory takes care of the details.

Most vimmers have had the experience of someone watching over their shoulder and they say "wait, how did you do that." And then you have to pause and think it through, because you yourself don't know anymore, it's just in you.

It would be ludicrous to try to learn all of vim, and it's absolutely unnecessary for using vim (or any other fine grained editor) effectively. You learn what's useful to you at the moment. If you do anything a lot that irritates you, there's almost certainly something in vim (or any other power editor) that will reduce it down to a keystroke or three.

I'm not saying you should learn and use vim, only that your objection (too much to learn) is misplaced.

> Most vimmers have had the experience of someone watching over their shoulder and they say "wait, how did you do that." And then you have to pause and think it through, because you yourself don't know anymore, it's just in you.

I had the interesting experience of learning vim over the course of many shared ssh+screen sessions with an experienced vim user, trying to get work done. "How'd you just do that" represents my primary method of learning for a while, and I definitely got a response of "hang on, let me try it again so I can tell you" more than once.

Most vimmers have had the experience of someone watching over their shoulder and they say "wait, how did you do that."

I agree wholeheartedly. Watching my colleague to code in vim is a turning event of my programming career.

Here's why I switched to vim full-time: Ubiquity across time and platforms.

If you invest the knowledge to learn Vim now, it will still be useful as long as keyboards exist and are used to write programs. You can also use it whether you are on Mac, Windows, Linux or whatever future OS comes out. You can use it over a high latency flaky SSH connection surprisingly effectively.

The notion of state-of-the-art is a red herring. Vim is a reasonably optimal mapping of all the keys on the keyboard to general purpose editing tasks with reasonably optimal internal grammar for combining commands in a logical way. In terms of general purpose editing, I don't think it's possible to make something "more advanced" than Vim, just different.

Of course in the GUI and IDE department there are many advancements, but how much are these worth? The answer is that if you pour millions of dollars into IDEs for constrained languages like Java you are going to get some specialized tools that outperform general tools like Vim or Emacs without similar language-specific optimization. That's great as long as you stay within the approved ecosystem, but not so good if you want to venture off into a new language or DSL that doesn't have IDE support. Personally that feels stunting to me; I want to try out new technologies at will without feeling unproductive until some monolithic software package decides to catch up.

Over the years through all the GUI advancements, the UNIX philosophy has proven that it still provides some of, if not the most fertile ground for creative hacking. I'd rather have 200 CLI utilities than 10,000 special purpose apps with thousands of non-orthogonal knobs and dials. Vim is a similar foundation for text editing. I can get some amazingly powerful plugins for specific uses (Fugitive makes "state of the art" git GUIs like Tower look like Playskool toys), but its bare functionality for manipulating text files is enough to get my comfortable and productive in any new language quickly, and I know I'll never have to learn a new editor for the rest of my life.

I like your comments on the merits of IDEs vs. general utils. The overwhelming majority of people at my school use Visual Studio, they look at me funny when I use vim. I just say: "Linux is my IDE, vim is my text editor." Everything their IDEs can do, I can do with either vim alone or a combination of vim + shell/python utils. (Of course, sometimes this is too hard to do to be worthwhile, and the MS world enjoys a lot of proprietary products that have had years of maturity and don't have OSS counterparts, especially in the gaming industry; it's a seductive environment.)

I use auto-completion when I think it's worthwhile, my vim supports tab completion in python files. My current exception is using Adobe's Flash Builder for Flex development since I needed to make programs now when I started, and didn't have time to learn the language+standard libs (which has consequently meant that I still don't know those things as well as if I had avoided auto-completion). Fortunately Flash Builder is built on top of Eclipse, so the occasional time I need Eclipse's integrated debugger for million line Java projects it's not a foreign interface. Yet I've never bothered to truly get used to Visual Studio, or Dreamweaver, or Delphi. To me those seem like the extraneous pieces of information I don't need since they're useless outside their very specific domains whereas vim is an investment that pays off time and time again in all sorts of areas.

You may want to look into ViEmu to use vim keybindings in Visual Studio

http://www.viemu.com/

Abstracting away from the traditional arguments regarding modality and keybindings, emacs serves the same purpose.

I selected emacs in large part because I was tired of learning different editors, one for each platform.

Ubiquity across keyboards also. You can easily forget where home/page up/page down/delete/backspace keys are, even its existence (as macbook don't have some of them), some keyboards also use them fn combo.My last laptop's left key didn't worked for month and I did not feel its need.

  You can use it over a high latency flaky SSH connection
  surprisingly effectively.

As a GUI editor user and generally vi(m) ignorant person I have a question about that. Flaky connections - that's where I live. Right now my typical MO is to open an SFTP connection to a remote dev server and edit the files on it by using an SFTP-capable editor. Essentially, the editor pulls the file, displays it for modification, and commits it back to the server when I press CMD-S. This works so incredibly well because the editing phase itself has no latency and saving 2-3 kB of (compressed) source doesn't take longer than a few seconds over the worst of connections.

Now, does vi(m) have a similar feature or did you mean (as I expect you did) that editing over a terminal connection to a vi instance that runs on the actual server was surprisingly effective? Because if you did mean that, you haven't seen actual bad connections yet ;-)

Don't get me wrong, I always have a Terminal window open, I love the command line. But I wouldn't use it for remote text editing unless it was an emergency. Also, I kinda like syntax highlighting in my editor.

vim has syntax highlighting.

Not on a command line SSH connection, does it?

Sure.

Whether or not this extends to color depends on the terminal / termcap support at the remote end, but at the very least bolding and reverse-video should be supported.

In most instances, you'll have full color syntax highlighting, though I've found I've got to down-rate my terminal. e.g.: rxvt-unicode isn't known on all systems, but rxvt, ansi, linux, or xterm generally are, and dropping past "rxvt" on that list is very, very rare.

Hmm, I never noticed that during my casual visits to vi-land. I'll definitely look into that, it's probably time to read up on how to massage vi's settings...

If you want syntax highlighting you should be using Vim, not Vi. On many (but not all!) modern systems 'vi' will invoke Vim in compat mode forcing you to manually reenable Vim's additional features. Some modern systems come with a Vi provided by elvis or even busybox, always check what you're actually using.

Alright, I promise I will check it out. I admit I do feel a bit behind the curve for being a programmer for so long while never really having looked into vi in depth.

You do realize that you can compile a termcap an set it up in ~/.terminfo, right? E.g.:

  % tree ~/.terminfo 
  /home/pyre/.terminfo
  `-- r
      |-- rxvt-unicode
      `-- rxvt-unicode-256color

My preference is to work as you suggest: edit locally, transmit the saved version remotely. vim even supports this with its ssh filespec, though I'll generally work, edit, and either rsync or git push these days.

Sometimes, though, remote editing is where it's at for whatever reason, and vi/vim is still probably the least sucky tool for such an instance.

Even if it means doing copy/paste into the remote session:

:r ! cat <paste> EOF

... works surprisingly well too.

By using sshfs (doesn't require any extra setup on the server side) you don't have to use an SFTP-capable editor.

I edit files across a satellite connection on oceanographic vessels a few thousand miles away at sea (often 1000ms+ pings) and sshfs is wonderful

and as the other poster points out, syntax highlighting working fully requires correct terminal settings

  By using sshfs (doesn't require any extra setup on the server 
  side) you don't have to use an SFTP-capable editor.

I know, but that isn't really the point at all. Whether I need to start one program or two in order to make the connection isn't the issue (but I sure prefer it in one package). My post is about avoiding latency when working online with a retrieve-edit-store workflow as opposed to transmitting every single keystroke and screen update over the wire.

And yes, as you already observed, I stand corrected on the point of syntax highlighting.

It is a nice idea and as a Plan 9 user I can attest to its power.

However The Fallacies of Distributed Computing [1] are not just whimsy.

[1] http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...

Actually, VIm has built-in support for editing remote files over ftp, rcp, sep or http:

http://vim.wikia.com/wiki/Editing_remote_files_via_scp_in_vi...

It's not perfect, but I prefer it to using vim inside a remote shell and waiting for cursor to move to the right point after I press a few j's.

I found it easier to grasp vi's 'command mode' versus 'edit mode' when I realised that most other text edits use a modifying key (ctrl+, alt+) to indicate to the editor that you want to run a command rather than enter text.

Command mode in vi is kind've like a Caps Lock, but for commands. "lock" goes on (enter command mode) and you're running commands. "lock" goes off (enter edit mode) and you're entering text.

I realise it's not quite the right way to look at it, but it helped put a big piece of the puzzle in place.

But why optimize for the lowest common denominator? I spend 95% of my time coding on the same laptop, in the same languages. I was a longtime emacs user but there's just no way I would write Java or Cocoa code without the support of an actual IDE now. The benefits of a tool that really understands the structure of my code instead of the surface syntax are just too substantial. If I have to use a generic editor for some new random syntax it's not that painful.

Besides, the basic cursor movement keys are standard across all text-editing widgets, at least on a Mac, and those are the most crucial to have in common. Using a "dumb" editor like Vim or Emacs seems like a premature optimization to me.

>You can also use it whether you are on Mac, Windows, Linux or whatever future OS comes out.

I can use modern WYSIWYG text editor on any unfamiliar platform anyway, my aptitude with computer GUIs is sufficient enough for that. Notepad++, Textwrangler, MS Word, whatever... they're not exactly difficult to pick up.

Yes, but then you're stuck with thte least common denominator.

> a text editor whose interface was already far behind the state of the art when I started school?

And what exactly is this state of the art you talk about? If it's the IDEs you are talking about, saying that they suck at text editing will be an understatement. Code completion, refactoring support etc isn't text editing.

When I am using a language which requires a lot of boilerplate and demands an IDE, I go for some plugin which gives me vim keybindings(eclim for java, don't do much C#).

Code is text at the end of the day, and something which isn't good at munging text isn't going to be my code editor. Eclipse, Visual Studio are both good tools, but they aren't good at munging text, not at all. And the boilerplate code they generate doesn't do anything to mitigate this.

> So why, exactly, should I voluntarily use a text editor

Because it isn't a pain in the ass like the IDEs when it comes to text editing.

> And what exactly is this state of the art you talk about?

Oh, that's easy: Emacs :-)

Yes, but vim doesn't do code completion or have refactoring support, which is something I like in my IDE.

Before someone tells me it does, I've had competent vim users try to get C++ support set up for me before, and it is almost worse than useless in code completion, code refactoring, and even trivial things like "jump to compiler error/warning".

vim does do code completion ...

For example, in my gvim, control-p shows the autocomplete list.

Does it work with the boost headers? Or member functions? Eclipse and VS can handle these both with ease.

If you think it does, I'd be interested to know your setup, as I've never been able to get such a thing to work effectively in vim.

    -   Complete namespaces, classes, structs and union members. 
    -   Complete inherited members for classes and structs (single and multiple inheritance). 
    -   Complete attribute members eg: myObject->_child->_child etc... 
    -   Complete type returned by a function eg: myObject->get()->_child. 
    -   Complete the "this" pointer. 
    -   Complete a typedef. 
    -   Complete the current scope (global and class scope). 
    -   Complete an object after a cast (C and C++ cast). 
    -   Complete anonymous types (eg: struct {int a; int b;}g_Var; g_Var.???). It also works for a typedef of an anonymous type.

http://www.vim.org/scripts/script.php?script_id=1520

(disclaimer: I don't use it, I turn off completion everywhere I go.)

Clang_Complete is another completion plugin, though it is not compatible with OmniCppComplete.

http://www.vim.org/scripts/script.php?script_id=3302

Thanks for the suggestion, but it uses ctags, which simply chokes on boost.

Try uxp's suggestion then, which doesn't use ctags.

I use clang_complete on Mac OS X and it is a dream. It works without issues on the Boost libraries and overall is very fast and efficient.

Both of these tasks are highly language specific. I guess your IDE can do it for your language but can it do it for Python/Haskell/Lisp/whatever?

In Vim, these features tend to be plugins. Vim ships with some of these plugins by default (e.g. C and C++). Autocompletion with C and C++ works using cscope and ctags, which also are very powerful code navigation tools. There are plenty of other tools available.

Vim has excellent "jump to compiler error/warning" support called the quickfix list. Just invoke your compiler using :make (you can configure what it does, by default it runs make) and look at the errors in :copen, browse with :cnext/prev.

All your arguments against Vim were false. Please don't spread such BS that can scare new people away from Vim.

I feel that at least telling them they are in for a hard slog, is a good idea. I've wasted at least a couple of months, using vim as my standard editor, before giving up and going to something else.

Vim's "jump to compiler error" tends to get confused by C++, and gets very confused by clang (this is from experience). There are indeed a huge number of tools available, for code navigation, for C and C++ in vim. Each of them has it's own faults and none of them have anywhere near the functionality of eclipse (although last time I tried vim, clang_complete didn't exist, and might now outperform tools from last time I tried).

I'd say it's an old interface, but that it's still state of the art (there's a reason there's a vi/vim mode or plugin for every major editor except emacs and that you've seen a resurgence of modal editors as the programming world has moved away from boilerplate laden languages). Don't think of it as knowledge competing for headspace for languages and quirks but as knowledge that augments those arcane bits.

For your :q! example, it looks daunting but you really don't end up memorizing it verbatim like that, much like you don't memorize adding semicolons verbatim to the end of your C# lines of code or adding closing tags to markup languages, it's just part of the language, a line end implicitly requires a semicolon so you just do it, vim commands are prefixed with colons so you just do that too.

The q is quit, which is hardly any worse than remembering Cmd-q or Ctrl-q is quitting for OS level shortcuts and the exclamation mark means "force", so it's usually unnecessary unless you're trying to quit without saving your changes, or doing something the command otherwise wouldn't normally allow. The exclamation mark is used in tandem with other commands too, so you don't mentally remember ":q! is how I quit a file without saving changes", you memorize how to build up the command you want, "I want to issue a command, type a colon" then "I want to quit the editor, type a q", then "I want to quit without saving, so force it, type an exclamation mark". And if it really bothers you, you can configure vim to prompt you for an action if it would normally require a ! and you left it off.

> (there's a reason there's a vi/vim mode or plugin for every major editor except emacs

Viper? Vim mode?

That's another story that these vim modes in emacs are hated by both emacs and vim users. I don't know who exactly they cater to.

I agree that they're usually sub-par, but it's telling that someone on every major IDE tries to address the lack of modal editing. Personally, when I'm using .Net or Java, I tend to keep the IDE open and open up gVim along side it, since it's rare for me to need the text-munging capabilities of vim simultaneously with the boilerplate/intellisense features of the IDEs.

I'm someone they cater too. I'm somewhere on the intermediate end of the scale for vim users and I love it's modal editing. But I also like modifying and specializing my editor and VimScript is to put it mildly a really sucky scripting language. And no the {perl,python,ruby} bindings do not improve the situation significantly.

Viper with Vimpulse get me close enough and still allow me to modify my editor in a lisp dialect. I'm willing to sacrifice some of the edge case uses of Vim to have this power.

It's not ideal but it's currently better than vanilla Vim or Emacs. I have hopes for Yi in the future but it's not there yet and development has only recently started to pick up on the project again so it has a ways to go.

VIM is muscle memory to me. I don't usually think about what I'm typing. I just think: 'I want this text over here' or 'I need all these phrases replaced with this new one' and then my fingers do it...like scratching an itch.

That being said, one still needs to learn it to begin with. I'm lucky that I decided to sit down during college and at least learn the basics. I'm not convinced that it makes sense for every one to learn VIM or Emacs if they are perfectly proficient as they are now. For me, it's the right answer as long as I'm not pairing with some one who doesn't know VIM.

I've found that using vi is like driving a manual transmission car after driving an automatic for a long time. There's a brief adjustment period but then it all comes back to me in terms of knowing how to use it.

I tend to be lazy and use keyboard shortcuts as much as possible regardless of the OS I'm using. With vi it's basically heaven since they were able to make it a powerful text editor without a modern GUI.

The cool thing about a good text editor is that you can use it for ALL of those things.

I'm an emacs guy not a vim guy but this fundamental point is similar. Being good at vi means you're good at editing arbitrary text whether it's VB6, SQL, HTML, JavaScript, XML, wiki markup, the output of 'find' or 'ls -l', or some randomly formatted table that someone sent you in an email.

Here's the appeal:

I first learned vi in 1986.

It sucked for about 2 weeks.

Then I got it.

For the subsequent quarter century, I've used iterations of the same tool, as my principle editor since the mid-1990s.

Since then I've used: WP4x+, WordStar, DOS EDIT, EDLIN, TSO/ISPF editor, MacWrite, MS Word in multiple incarnations, AmiPro, EVE and EDT on Vaxen, and a slew of other proprietary editors (as well as Emacs, pico/nano, ae, Lyx, AbiWord, etc.).

vi/vim is a standard you'll find on any 'Nix box, from BSD to SysV4 to Linux to Mac. Ports exist on a great number of other platforms.

As with other 'Nix tools, a key advantage of being a free software program is that it tends not to up and get replaced. The fundamental philosophy of vi (a full-screen curses editor based on ed with its commandset) continues through the modern incarnation (though I've got to admit that going back to old-school, un-featured 'vi' instances sucks).

While the free versions are now generally available, I ended up learning and unlearning a lot of emacs when I switched to a shop that 1) didn't have it and 2) the boss wouldn't allow it to be installed (didn't know enough at the time to realize that was a prime hint to up and leave).

I've saved myself having to unlearn a great deal of stuff by sticking with vi/vim.

Now: if you've got an editor which works for you _and_ can offer the same promise of persistance, bully for you.

But at least now you understand the appeal.

I could have written this. I learned a little vi in the mid-80s and have pretty much used it ever since. No other editor has stuck with me that way and I've seen most of them - ISPF, WordStar and many derivatives, WordPerfect, etc. Except Emacs. I just never got into Emacs because every system that had Emacs also had vi.

I think I spent the first few years getting to the end of a line with shift-A and Esc, copying lines by trying 13dd u 14dd u 15dd P jjjjjj p, etc. (Side note: even as I was editing this text I kept hitting ESC and bbbbbb.) I'll likely never know all the things Vim can do, but it's already enough that it's my fallback editor when I need to do a lot of editing or text manipulation.

I've used vi editors for longer than I remember, I don't remember any of the things I type. They just happen. I'm 30 btw, vi and its arcane "behind the state of the art" interface are only behind if you don't understand the reasons behind the separation. Every single time I login to a ssh server over a slow ssh link, I am imminently thankful I can type and update a file faster than the screen can refresh my changes. One thing for which vi excels at.

Also, don't use :q!, just use ZZ, its quicker.

If you want to learn how to do something vimgolf is a good choice as the goal is to do a task in as few commands as possible.

Think of it as talking to your editor in as minimal a way as possible. http://vimgolf.com/

> Also, don't use :q!, just use ZZ, its quicker.

But ZZ is equivalent to :wq, which is different. If OP finds themself in a text file in vim by accident and started typing a word, they will likely NOT want to save those changes. (Hence OP's :q!, rather than :q.)

If you've made changes then yes its not equivalent, keep in mind I NEVER open a file for editing unless I intend to edit.

That is what view/more/less are for.

Oh, cool! I didn't know about view, actually... I'd been using vim to poke around in files because I'm familiar with the navigation key commands, and was always keen to make sure not to edit something. But opening as read-only is great!

Something that continually surprises me is how a lot of these things are interrelated historically, but people teaching these things either don't know that or don't think it's important to pass on. By which I mostly mean stuff coming through the unix tradition like grep, regex, vi-keys etc.

You meet these things for the first time and think, why would I bother learning all that arcane knowledge just to do this one thing, but then later you realise that you can leverage that knowledge across a wide range of tools. Obviously you mention C# and .Net so you swim in a different pond and are less likely to see the same level of reuse, but that doesn't mean it's not there.

I have been using vim for a little while now (1+ years, so I still consider myself a newbie) and I have found that it has become second nature, I don't think about it anymore I just do.

I learned how to drive a manual car a couple years ago and these days I just don't think about it anymore. I shift completely absentmindedly, it just happens. The response is built into my body, I no longer have to provide it any thought power.

I've become much more productive with vim than I have with any other text editor.

I am but an egg, but . . . - Knowledge of vi keystrokes allows integration of automated text editing with other shell commands, as those keystrokes are scriptable. - Search and replace commands allows fine-grained specification of global texts. Tricks like "delete all lines from the start of this code block to the end" are no big deal. - vi easily incorporates the output of shell commands into the text you're editing.

I really appreciate your comment. Anyway, this comment was not meant to convince non-vi-ers to start using vi. You don't start using vi because it has a great ":" command that you can use from line X to line Y to apply some other command to them and nobody actually expects you to (or should, at least). It was for people struggling while getting started in vi. People like me, on their way to true programming-buddhahood. Not everybody has that goal and not everybody should have. Kudos for following your path. (But also, I think that you don't need to read vi stuff because it will not give you anything, anyway)

re commit to memory. I put forth that a programer's editor is the most important thing to commit to memory. Also, with vim you commit to muscle memory.

Vim is "far behind he state of the art" same way Lisp is. That is it's so far beyond state of the art that it takes most editors/people years to realize what they have is just a weak / limited implementation of vim.

Given that, I STRONGLY believe people's brains work different. And what may be the most awesome editor for us is not the same for you.

Given that, you can not know if vim is for you without using it (daily for programming editing) for at least a year.

> There's only so many things one can usefully commit to memory

Can you refer to any scientific research to back up that statement? My impression is that the more you use your memory, the easier it is to remember new stuff. Memory seems to be more like a muscle, the more you use it the stronger it gets, rather than a bucket that can get filled up.

I think it's sensible if thought of as more time investment rather than how much you can commit to memory. Learning something like vim is going to take some time and is perfectly reasonable to question if there is a whole other stack of things you are also attempting to become proficient in.

It is reasonable, but... I have been using vi/vim for almost 15 years now. Various technologies have come and gone (or persisted), but the underlying tool I use to make them sing has not. Early in my career I made the decision to learn vim, and it is not a decision I have ever regretted. Yes, it meant that in the beginning there were things that took me longer to do. But now? Now I can do so much more so much quicker.

And after a while -- and it is not all that long of a while -- it becomes second nature. The fundamentals become a part of your fingers, just like touch typing. You no longer have to hunt and peck to type out the word "lightning". You just do it. vim's keybindings become similarly engrained. It just takes practice.

I voted you up since I agree with your muscle premise in real world situations with realistic amounts of information, but here you go: http://en.wikipedia.org/wiki/Bekenstein_bound ;)

This is a matter of cost vs benefit, not memory.

Reply on news.ycombinator.com