Comment by dasil003 | Hacker News Reader

Comment by dasil003 | Hacker News Reader

Parent Full thread

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.

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.

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.

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/

  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.

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.

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.

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

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

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.

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.

Reply on news.ycombinator.com