A pragmatic decision on GNU Emacs versus Vim for programming | Hacker News Reader

A pragmatic decision on GNU Emacs versus Vim for programming

utcc.utoronto.ca

55 pointszeveb59 comments

I'm pretty happy with neovim nowadays... With Neomake, I get enough "IDE" features that I can stay productive, and it's fast enough that I don't miss Emacs' superior tools.

I don't think I can ever get used to a non-vi editor (I feel uncomfortable even browsing without vim-style shortcuts thanks to pentadactyl/vimfx), but there is one for Emacs so that is not a show-stopper.

I did in fact try Spacemacs for a while, and wanted to like it, but in the end I couldn't get rid of my muscle memory to just start new editors in terminals all the time, and Emacs' daemon mode had stability issues for me, so it wasn't very usable: either it'd crash at times or startup would be unusably slow.

Muscle memory is a powerful thing. I had to alias "vi" to "nvim" just to be able to use neovim...

Neither neovim's or vim's ecosystem is primarily (or even significantly) Lisp, though.

A fully Lisp ecosystem is one of emacs' greatest attractions, and one that neither vim nor neovim is likely to ever achieve.

Not with that attitude ;) https://github.com/adolenc/cl-neovim

Yeah, you can script vim in Lisp (Scheme to be more precise). That's been possible for a long time, with mzscheme. But virtually no one ever does.

The vim ecosystem is overwhelmingly vimscript. Python is gaining popularity, and if anything a mainstream language like that is likely what the neovim ecosystem will eventually wind up consisting of. Not Lisp.

Contrast that with emacs, where it's Lisp, Lisp, Lisp, and will continue to be Lisp for the foreseeable future (with a detour to Scheme possible in the long run).

This guy is completely correct in his decision. If you want magic, use emacs, don't try to shoehorn it into vim. One of the reasons I left vim for kakoune is that the impulse to turn vim into an IDE has led to scope creep. Vim feels huge these days, where kak does a much better job of deferring to other applications what they do well.

Precisely why I use actual vi.. (well.. the nvi rewrite)

Unfortunately many current 'vi' users have never actually seen the real thing, since most linuces simply alias vi to vim.. I realias it back to nvi because every new vim distro package has a new layer of auto indenting shiny garbage I have to unfiddle before approaching actual vi..

If I want fast text hacking, I use vi. If I want fancy stuff in the sweet spot between basic editor and ide, I use emacs, and if I want vi key bindings in that sweet spot, I turn on viper/evil. Done.

^ bitterness resulting from the conflation btw vim and vi :b

also: keep your grubby hands off of my directory mtimes :D

vim still opens in ~250 ms (or less) on my system. I'm not sure what problems it's causing you.

I have 100++ vim plugins and get around 500ms startup because of contextual loading by neobundle.

His problem were with the extensions vim made to vi and which ones were enabled by default with the packages he used. He never mentioned startup time.

I first partook of vi on an Irix box under the tutelage of a crusty graybeard. There are some things I do appreciate about vim in contrast.

* Syntax highlighting

* Unicode

* Visual selection

* Multiple buffers

If I have a task for an editor that doesn't do those things and runs really fast, I usually reach for sed.

Speaking of needless complexity and bloat, I don't know why you stop at nvi and don't just use ed.

Do you find the temptation of the plugins to strong to resist? Plain vim doesn't seem much more bloated than in the past.

How is kakoune in practice? I've been eyeing it as well but was waiting for it to mature a bit.

> Do you find the temptation of the plugins to strong to resist?

In a sense... I kept seeing vim plugins promoted as a way to make my life more awesome, but every time I tried one it was incredibly slow and I bounced back to vanilla vim. Not only that, but I kept getting burned every time I would try what seemed like simple customizations, like adding a few extra pieces of information to the status bar. After the Nth time I went to open a 50M file and had vim lock up on me, I reverted my .vimrc.

> Plain vim doesn't seem much more bloated than in the past.

It's not, and to be fair to vim you can build a pretty lean version of it if you want to. But the fact that all of the creaky vimscript machinery is there behind the scenes was starting to bother me.

That alone wouldn't have been enough to bounce me to kak, but when I tried it, it immediately overwrote 20 years of vim muscle memory and I had a lot of trouble switching back. I had been using visual mode a lot in vim, and I always felt a little bad about it -- like if I'd been better at ex I wouldn't have had to use visual mode as much. Kak's editing paradigm is all about selections anyway, so I'm a lot more comfortable using it than I ever was with vim.

> How is kakoune in practice? I've been eyeing it as well but was waiting for it to mature a bit.

It's mature enough for me -- I've been building it from master every couple of days, and crashes are very unusual. The tmux integration is amazing. I always hated having vim splits inside of tmux panes inside of i3 windows, and now I don't.

Why do so many people only consider Emacs and Vim for programming? There are a plethora of IDEs that have way more features out of the box and even have plugins to make them compatible with Vim and Emacs usage so the switching cost is almost zero.

I can't speak for others, but I do almost all of my text-editing via SSH on remote servers so I basically ignore all GUI options. Also I like to be able to load-up a familiar dev environment on any server that I SSH into, so I don't like a ton of customization.

Give me examples. And I think I will be able to explain to you why I prefer emacs/vim over those. It's not like I didn't try them, it's that I haven't found anything better than vim/emacs!

For vim, at least, those plugins are often highly incompatible with high-intermediate to expert usage; lacking everyday features. Interestingly enough, the only vim plugin I've ever felt comfortable with is evil-mode, which just goes to show that emacs truly is the best ide, even if it comes with a shockingly bad editor.

If you're talking about a statically typed language built for refactoring and static analysis like C# and Java (hopefully one day rust), you're absolutely correct, that's a game changer and you should take advantage of that.

However, the functionality quickly falls off. I do tend to keep around intellij, but mostly for the various debugger integrations, but you can quickly replace any integrations with project-wide search and replace + a decent auto suggest + compile/linting integration. That's not terribly hard to find these days in emacs, vi, vscode, sublime, etc etc, and it's only going to get easier when we start seeing language servers pop up so you can refactor from any editor!

Many people don't like the idea of an IDE. In Unix the whole system is a development environment, the editor is just a part of it. Also having Vim/Emacs-like key bindings is not the same thing as being "compatible" with these editors.

I think it is just a matter of taste. I've never found an IDE that didn't try to be way to magic for my tastes. I prefer combining my choice of lower level tools in ways I find useful. So IDEs aren't the competition for people like me. There is competition though, VSCode, Atom, lime, kakoune, etc. It's just that vim and emacs are the classics, so they get discussed a lot.

I could say that the debate is mostly relevant to "1337" hackers, that are un-pragmatic bordering to religious.

I won't do that, and instead state that the wise person selects the tool appropriate for the task.

I sometimes use emacs, and avoids vi as much as possible because I happened to learn emacs first.

But prefer IDE's and typed languages because I have a unreliable memory in respect to function names and argument order and irrelevant details like that, and I don't want to spend half my life trying to set up either emacs or vi to handle code completion so that it's even halfway-decent.

But that's just me...

I still find myself frequently working on an unfamiliar Linux system, or one where I can't install any SW. For those situations vim or emacs knowledge is still good to keep around.

Plus the vim-emacs debate is fun to keep alive, it's a like a surrogate discussion. Other people might talk about sports or the weather.

Fetishism. For some people it's the only thing that feels like 'real programming'. Ultimately it's an emotional decision rather than a functional one.

I don't think it is the typical case that an Emacs and/or Vim user only considers Emacs and/or Vim. I think the typical case is that Emacs and/or Vim offers more appealing sets of tradeoffs to their users.

I mean Visual Studio and Eclipse and (I imagine) Xcode offer substantial features and optimizations for the languages and ecosystems they primarily support. The cost of those optimizations and features appears when a person moves outside of the languages and ecosystems a particular IDE supports. Any language outside of those for which an IDE was designed is an edge-case (google up "Xcode Perl" for example).

Sure, it's possible to use an IDE outside of it's design sweetspot but it's swimming upstream in the Turing Tarpit. And the likely longterm outcome is that a programmer will wind up using a different tool and one of the options for most languages will be a text editor.

So the model I would use for why people choose a text editor is analogous to gradient descent where text editors are a local minima.

I ended up switching to Emacs after having spent quite a bit of time in Visual Studio, Kate, and Geany (in approximately that order). I've since tried Sublime and Atom, but they don't feel right to me. My '.emacs' turns Emacs into my editor rather than someone else's editor that I happen to use.

Basically: I don't really care about the out-of-the-box environment. I care about an environment that's tailored to my use-cases and programming style. This will cause me to frequently gravitate toward Emacs or something very similar.

I also happen to like Lisp, so there's that. TRAMP also helps considerably for editing remote files, and very few non-Emacs IDEs/editors offer any real equivalent.

At the end of the day, my biggest reason is that few of those work/look/act/configure the same as they did 10 years ago, and will undoubtedly change how they work/look/act/configure in the future.

This isn't a bad thing, I just prefer to stick with what I know how to use efficiently to do the tasks I've done before.

One thing to keep in mind: I don't just use a different set of tools, I have a different workflow. Vim rarely takes up a full screen. (well, half now we've all agreed on widescreen monitors...)

As a quick breakdown of working on a project:

- I usually have a 'command' terminal, where I run build commands, execute / debug the app, manage project files, etc... (usually in the root dir of the project I'm working on, so paths are relative and easy to work with everywhere)

- I have a 'main editor' terminal, using Vim to open multiple files for editing, splitting the window and switching buffers on the fly based on what I'm doing.

- I have a browser window with tabs open to various documentation/reference pages for the code I'm writing. This gives me my 'intellisense' equivalent, I guess.

- I might open terminals temporarily to display other code, etc... when I want additional references displayed. (but only ever edit from the main editor window)

- I use tools like cscope (or even just grep) to browse my source code, which I can even do from the editor.

- I generally write a build.sh / run.sh / clean.sh I'll add to as I go, which wrap things like CMake, Make, lint tools, etc...

The biggest perk is that I can work in 100% the same way from any system with an SSH client, with zero change to my workflow. I can reconfigure my entire development workspace on a clean system and be productive with a couple 'git clone' commands and running a shell script to 'yum/dnf install' a couple standard development tools from the default repos.

I don't mean this defensively, I'm genuinely curious... What do you think an IDE gives you that other tools don't? The first two that come to mind are a tightly integrated build system (eg. creating a new source file automatically builds and links it with the project), and the GUI design tools that generate the relevant class files. (Those could be huge factors for some people)

Is it simply the all-in-one packaging and integration between the tools?

Thanks for taking the time to reply if you get through all that :)

Re: the article's last point: I've actually found Emacs to be wonderful as a "sysadmin's editor" thanks to TRAMP; I can edit a remote file on any of my servers (provided I have SSH access, which is the vast majority of the time) using my local machine's Emacs.

Even when I don't have SSH access to a machine (perhaps because sshd ain't running yet), my increasing use of OpenBSD means increasing availability of 'mg' on my servers, which further means that I don't have to leave the comfort of an Emacs-ish environment (even if I lose some of the more advanced features). It's only on my Linux machines (and on SmartOS) that I have to resort to 'vi' or 'ed' for anything, and even that's going away as more distros ship with 'nano'.

I always found directory navigation to be a pain with TRAMP and even dired. Also, I like to run various commands on remote systems and not just edit files there, so having a native shell open there is very natural for me, and emacs' terminal emulations have been very clunky in my experience and require way too much indirection in keyboard shortcuts on top of tmux and evil which I how I use emacs.

This is an aside, but why did the author prepend Emacs with GNU every time?

From my understanding, GNU Emacs is a specific flavor of Emacs (which is a general class of editor). From wikipedia, it's the most common flavor of Emacs. Is it not generally understood that Emacs implies GNU Emacs? Would it not be sufficient to introduce the article with, "... Emacs -- specifically, GNU Emacs -- ..." and then carry on with Emacs elsewhere?

It seems needless, or even pedantic, but maybe I'm missing something?

What you're referring to as Emacs is actually GNU Emacs, or as I've recently taken to calling it, GNU plus Emacs.

I have a feeling there's a joke here I don't understand.

https://www.lurkmore.com/view/GNU/Linux_interjection

In the modern world there basically is only GNU Emacs. The only other actively maintained editor (well, there's Linus's microemacs tree too I guess) that calls itself "emacs" is XEmacs, a long-time fork of GNU Emacs. But it's been fading steadily over the past decade and at this point very few people use it or even know about it.

Basically: yes, you can be unambiguous by just saying "emacs" and everyone who cares will know exactly what software you use. But for the same reason it's not really correct anymore to use "emacs" to refer to a "general class of editor". You need to be more explicit if you're invoking historical or oddball variants.

So, why did the author make such a point of using GNU Emacs everywhere? I feel like I just read an article where the author says, "Apple's OS X" or "Microsoft Excel" over and over.

Edit: Confused about downvotes too. My question comes from a genuine place of not understanding.

Maybe he's a GNU zealot, they exist. The type to refer to Linux as GNU/Linux. ;-)

I never liked mixing Vim and Emacs. I used both, but for different things. I use NeoVim as my terminal editor, with tmux, zsh and iTerm2. And I use it for 70% of code I write. Emacs I have Installed, GUI version, and I use it for functional programming languages, mostly Lisp, Clojure, OCaml, Haskell feel better in Emacs. So there goes other 20% of code I write in my free time mostly playing with FP, those languages that lean on REPLs are clearly better integrated into Emacs and all that FP history that is pretty relevant in considering Emacs. And 10% is when I have to write something in Java where I have to fire up IntelliJ Idea, thankfully it doesn't happen so often.

Never got into that Emacs as an OS mentality, but I can see it's appeal to someone but I didn't like it. But I am really grateful for system wide shortcuts in OS X, just C-A, C-E has saved me so much time in macOS. And yeah, Emacs made me rebind ctrl to Caps Lock, which is so good, I can't imagine how I used keyboard before this!

I like UNIX and use it for everything I can. (there is other thing on internet called UNIX as an IDE)

Edit: and oh, I forgot there are some beautiful things with Emacs like magit. I have understood git and it's concepts thanks to this emacs git interface, now I am 10 times better and I know what I am doing in terminal.

This just reads like anyone who's flirted with both editors. "I'm really familiar with <editor A>, and I see the merits of <editor B> and wanted to use it, but in the end I'm very familiar with <editor A> and decided to stick with it". Not much insight here.

Also, "I learned $A and got really good at it, and shunned $B figuring $A was superior in every way, but my experience with things similar to $B convinced me to learn it, and ultimately I realized I like it much better than $A, and have been happily using $B for years now."

There are significant architectural differences between Vim and Emacs which mean that each better accommodates some workflows better than others. In the author's case the architectural differences manifested in the mechanisms for extending core functionality. Vim was initially designed to do one thing well...edit text. Emacs was designed to do whatever the user wants whether that's editing text or something else or choosing their own definition of what it means to edit text (e.g. org-mode). Each approach has value for different tasks for different people at different times. That doesn't mean that one is not better than the other for a particular person/task.

It doesnt matter what were they initially designed in some abstract sence. Nobody would question that those 2 are primarilly editors and that it is their most important function - editing and navigating text (and along, text interfaces). That means that vim must be better as its workflow is more efficient for that (thanks to the 2 modes and speed that object motion combinations give) and more healthy (without producing RSI which means I can physically do vim more time then emacs, a point mostly ignored by people ).

Both can do basically anything nowdays so the argument of particular workflow suiting better different people does not hold. Its just that some people dont want to invest time into learning vim because vim on-boarding is probably the hardest compared to any other editor. There are maybe some other aspects involved for some people (like lisp vs viml) but those can safelly be ignorred as non important in majority of casses.

I do agree with the general sentiment here... both emacs and vim are primarily editors. However, it's also worth noting that emacs is much easier to extend and change than vim which is one of the reasons people do so many things in it (hence the "Emacs is a decent operating system lacking only a good text editor" joke). Handling email, chat, all git operations and more is common in emacs, but fairly rare (at least in comparison) in vim.

There's also spacemacs (for a large config) and evil-mode (if you want to get into the nitty gritty details) for using vim bindings in emacs. Doing the opposite would be a much harder feat.

I love both editors... and there's a reason I have both a vimrc and an init.el. vim has the advantage of being pretty much everywhere (so it works really well when editing on servers), and has awesome modal editing, but emacs works really well for local development where I can make sure I'm using the right version and have it tweaked to work exactly how I want.

I don't think that one is better than the other, just that they have different use cases.

Because Emacs has modes that make it mimic Vim, it's false that Vim "must be better," especially when Emacs can do things (like frames) that Vim cannot. I'm not saying Emacs is "better," just that this line of analysis is flawed.

Its not flawed. The greatest use case for editor is editing text. Even the small differences in efficiency in the main use case pile up enormously on the long run. Thats why people practice vim golf - to make micro optimizations that will lead to huge benefit.

The argument emacs can do frames is irrelevant in this respect.

You suppose that the only measure of efficiency is keybindings. It is not. For me, other aspects of the editor, such as frames, superior auto-completion, and superior compilation mode, make me more efficient. I don't use an editor solely to "edit text." I'm using to to accomplish a bigger objective, such as creating or fixing a program. Overall, Emacs is better at that, and the fact that I can give it bindings that mimic those in Vim also helps.

evil (the vim emulator for emacs) is fantastic, but the argument that emacs + evil must be equivalent or better than vim is also flawed. For example, plenty of emacs modes and packages have extensive keybindings that clash with vim, so the emacs + evil experience will never be as smooth as vim and its own native packages that were designed with vim's interface in mind.

Yes, you can give up the vim bindings in certain modes, or spend lots of time re-configuring various packages' bindings. But that is not something you'd ever have to struggle with when using vim.

To me, the initial architectural decisions are reflected in the tools today: just as the initial architectural decisions of the Pantheon versus the Pyramid of Cheops are reflected in the way each building is actually used by people today.

For example the Pantheon's architectural design more readily facilitates shelter from inclement weather. While the Pyramid of Cheops could be modified to do so, it seems to me that adding a portico or walk-in interior space is both non-trivial and at odds with the existing architecture.

> vim must be better as its workflow is more efficient for that (thanks to the 2 modes and speed that object motion combinations give)

Emacs provides object motion commands, too, based on b/f/p/n. It can have two modes (in the vi sense), if you wish, using evil-mode.

It's also far, far better than vi at editing and navigating the text of a news post, or a newsgroup, or an email, or a web page, or a process listing, or a kubernetes definition, or or or.

Emacs can completely emulate vim; vim cannot emulate emacs. Seems to me emacs is more powerful.

Emacs can completely emulate vim; vim cannot emulate emacs

That is probably not true. The main reason is more probably that nobody wants to emulate emacs in vim. Its more telling IMO that emacs people want vim in it. As user slurry above pointed out, its probably because old habits die hard and because people continue doing the same stuff to justify time investment.

I have been an emacs user for 16 years now, and I have come to this conclusion as well. I don't - like 99% of emacs users - use advance scripting capabilities. But even if I did, it would still be less efficient at the core task of text editing. I'm stuck on emacs, because old habits die hard. But I'll teach my son to use vi.

> Both can do basically anything nowdays

But Emacs makes it easier for that "anything" to include things the user wants to be able to do, but aren't built into the system. I use VI, but far prefer Emacs because I can keep adding functionality to it as I need it. That's what's important to me.

You add functionality in vim as you need it too in its profile, local profile, or via number of other means. VimL sux big time comparing to Lisp tho although you can also use Python and Ruby and Lua and whatnot (it sux that it might not be an option on some platforms that easily).

Actually, the author claimed to be more familiar with vi or rather that they were using vi much more yet decided to go with emacs. Pretty much the opposite of what you are saying.

No in the realm of plugins, which was the subject of the article, it's exactly how OP says: they know the Emacs plugin landscape and not the Vim one. For the relevant passage search "I'm not that person".

From the first paragraph of the article:

"The reality is that I already spend most of my editing time in vim"

I read his blog regularly, and my impression is that cks actually feels more familiar with Emacs, though he uses vi-descendants a little more due to how easy is to deploy Emacs plus all the configuration in all the OSes he runs (times the servers he runs, as they don't have much of a configuration management system).

this post doesnt make sense to me, he could just run vim from emacs using evil/viper mode. perhaps he is new to emacs?

To me, running evil-mode feels like an extra layer of complexity that makes it harder to debug problems. Vim has a good support ecosystem. Emacs has a good support ecosystem. But the intersection where evil-mode lives is not a particularly robust ecosystem...debugging problems means dealing with three things: Vim, emacs in general, and evil-mode and then trying to sort out where the problem sits.

Reply on news.ycombinator.com