7 ms·
A pragmatic decision on GNU Emacs versus Vim for programming
- sevensor 10y agoThis 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.
- cat199 10y agoPrecisely 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.
- cat199 10y ago^ bitterness resulting from the conflation btw vim and vi :b
- cat199 10y agoalso: keep your grubby hands off of my directory mtimes :D
- ktRolster 10y agovim still opens in ~250 ms (or less) on my system. I'm not sure what problems it's causing you.
- majkinetor 10y agoI have 100++ vim plugins and get around 500ms startup because of contextual loading by neobundle.
- eikenberry 10y agoHis 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.
- sevensor 10y agoI 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.
- pmoriarty 10y agoSpeaking of needless complexity and bloat, I don't know why you stop at nvi and don't just use ed.
- eikenberry 10y agoDo 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.
- sevensor 10y ago> 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.
- colordrops 10y agoThis 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.
- sdegutis 10y agoAlso, "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."
- brudgers 10y agoThere 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.
- majkinetor 10y agoIt 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.
- deleted 10y ago[deleted]
- jaequery 10y agothis post doesnt make sense to me, he could just run vim from emacs using evil/viper mode. perhaps he is new to emacs?
- brudgers 10y agoTo 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.
- Pfhreak 10y agoThis 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?
- vdnkh 10y agoWhat you're referring to as Emacs is actually GNU Emacs, or as I've recently taken to calling it, GNU plus Emacs.
- ajross 10y agoIn 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.
- Philipp__ 10y agoI 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.
- chousuke 10y agoI'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...
- pmoriarty 10y agoNeither 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.
- fmoralesc 10y agoNot with that attitude ;) https://github.com/adolenc/cl-neovim https://github.com/adolenc/cl-neovim
- pmoriarty 10y agoYeah, 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).
- enknamel 10y agoWhy 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.
- roadnottaken 10y agoI 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.
- Philipp__ 10y agoGive 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!
- belovedeagle 10y agoFor 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.
- dgfgfdagasdfgfa 10y agoIf 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!
- 10y ago
- myst 10y agoOMG who cares?!
- yellowapple 10y agoRe: 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'.
- pmoriarty 10y agoI 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.