Hacker News Reader

Comment by southphillyman | Hacker News Reader

I work with several "Vim masters" who do about 50% of their development in Vim and 100% of their file editing there. It's extremely embarrassing to have to sneak and do repetitious file edits by hand in Notepad++ because I never invested the time into learning Vim. I tried reading a Vim book but became bored and quit after a chapter or two. Honestly I never worked with people who use Vim everyday before so it doesn't seem to be THAT common where it's a requirement to know it but I guess it's worth giving it another try.

View on HN

Vim productivity has been overblown by the fanboys of terminal-based text editors, vim et al are sorta on the verge of being irrelevant even deprecated because there are two things that are getting better: modern languages and IDE's.

Vim/emacs existed solely because there wasn't anything better (lookup for ed, that's a real man editor) to develop on the old-days plus old-school languages have this trend of including tons of "ceremony" and "duck-tape" code for handling data that vim was good because the repetitive nature of those things while coding but those days are over, there are less jr's learning vim/emacs and those "Vim masters" you talk are becoming less and less irrelvant with every year, i expected that in the next 5 years vim will be talked as a thing of the past.

To some extent what you write is true of vi (there was nothing better when it was written), and vim exists for folks who are used to vi to get some features of an extensible editor (i.e., vim is an emacs for vi-users, just with a far worse extension language and fewer decades of debugging), but what you write is false when it comes to emacs.

The benefit of emacs is that it is a completely extensible environment for editing text. It turns out that just about everything we do on computers involves text: source code, sure, but also web pages, git, email, shells, configuration, UIs &c. All of that stuff is text, and emacs can handle it all, and it can be extended to handle the next thing which comes down the pike too[0]. emacs is the forever editor: decades after SublimeText and Atom are dead & gone, emacs will continue.

vi & vim will continue, too, because the textual language of vi is still more powerful than any of those GUI editors. It's more powerful than the default keybindings of emacs (although note that with things like evil-mode or viper, emacs takes on vi keybindings). Even GUI apps which try to implement vi(m) bindings generally fall down because they implement so few (in the same way that apps which try to implement emacs-style extensibility fall down because they use insufficiently powerful languages).

I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs.

[0] vim can also be extended to handle anything, but compare:

    function! ToggleSyntax()
       if exists("g:syntax_on")
          syntax off
       else
          syntax enable
       endif
    endfunction
    
    nmap <silent>  ;s  :call ToggleSyntax()<CR>

vs:

    (defun toggle-syntax ()
           (setf syntax (not syntax)))
    
    (global-set-key "\C-cs" 'toggle-syntax)

Which would you rather write?

> Which would you rather write?

I get your point but I don't think this is a good example. This is the kind of thing you write one, put in your .vimrc, and then never have to think about again. Especially if you're putting your .vimrc in source control and pulling it down automatically into new environments.

The problem is that anything written in vimscript is going to resemble that first example, when were it written in elisp it could resemble the second.

Regardless, better to have vim or emacs than anything else.

> I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs.

I have yet to met a developer that blame his inability to "get stuff down/done" because his editor don't let him write fast enough.

Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem.

> Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem.

You're right, and that's the thing: emacs isn't better because it enables one to type more quickly; it's better because it enables one to do more. With emacs, a developer can build out his own environment, and he can share that customisation with others. As an example, magit is by far the best way to interact with git. Another example is org-mode. Another is gnus. Another is notmuch. And on and on.

Indeed, it's this emphasis on extensibility which is why I prefer emacs (which is better-extensible) to vim (which, frankly, has a better text-manipulation language).

There's simply no competitor to emacs when it comes to extensibly interacting with text.

Even if SublimeText, Atom, IntelliJ, Eclipse, Visual Studio got perfect vi keybindings, I do not believe that they'd be as extensible as vim, let alone emacs. Since extensibility is the quality which enables a tool to be used for more than its designer imagines, and since no designer can imagine all his users' use-cases, I think that this means that SublimeText et al. will never be all one needs.

> vim et al are sorta on the verge of being irrelevant even deprecated because there are two things that are getting better: modern languages and IDE's.

I don't spend a ton of time coding any more but do spend a ton of time doing random text editing (properties files, XML, data manipulation, whatever). While I agree that modern IDEs are probably better if you're just doing straight coding I think there will always be a place for a high powered text editor.

Plus, if I'm editing a script on a remote host (random shell script) or just need to make a quick change to something locally then it's much faster/easier to drop into vim than to fire up an IDE.

IMHO vim for editing remote files it's still far too complex, i prefer nano for editing config files and write some tiny shell scripts. I do give you the reason when editing long xml files remotely, vim is superior on that but still i prefer to locally edit the xml file with a IDE because i have the possibility to visually collapse entries and automatically show syntax errors.

I know vim/emacs fanboys are going to say that all that it's possible on vim/emacs but still i have to invest time configuring those options and plugins on vim while on almost every IDE or even some simplistic GUI editor like Notepad++ those things come already configured and ready for work.

> It's extremely embarrassing to have to sneak and do repetitious file edits by hand in Notepad++ because I never invested the time into learning Vim.

Nothing to be embarrassed of. Vim isn't the graal of editing and people are productive with all sorts of editors. Actually, I'm pretty proficient with Vim but I'm starting to wonder if it wouldn't be better to focus on standard mac os shortcuts. And I also believe that the best programmers are those that type the less...

Notepad++ does a few things I really like and haven't taken the time to learn how to do in vim. In particular, double click and highlighting a word and having the word highlight in the entire file, and then scanning the whole file by scrolling with mouse. This is stupid but I do it all the time when working with unfamiliar code bases.

FYI vim mode in emacs does what you describe.

Reply on news.ycombinator.com