8 ms·
Very difficult to do with free software and completely irrelevant really. At some point in your life it's OK to accept that you're the weird one. We're the weir
by cup-of-tea 8y ago
Very difficult to do with free software and completely irrelevant really. At some point in your life it's OK to accept that you're the weird one. We're the weird ones. Donald Knuth, Richard Stallman, Guido van Rossum, Rich Hickey et al are the weird ones. I don't know why emacs is such a barrier to everyone else or why vim is so attractive. But I don't understand most other humans about most things.
- copperx 8y agoVim is attractive to many because it launches in a fraction of a second. This is especially important to sysadmins, who don't "live in a text editor." It's also quite popular to use vim without customization. I understand that some people have simple needs. I don't. The editor wars are over for me and Emacs has won.
- azernik 8y agoThe performance issue isn't about sysadmins wanting fraction-of-a-second launches; it's about Serious Programmers back in the 90s wanting precious memory. "Eight Megs And Constantly Swapping" was the derogatory nickname, back when eight megs was a lot. (And, secondarily, launch times then were longer; 0.2 seconds vim vs. 2 seconds emacs is a very different comparison than between 2-second vim and 20-second emacs.)
- namibj 8y agoI want my software to be instant, or as close to it as feasible. Vim is fast enough, make sometimes, and gcc not. This is in syntax-only mode for the latter.
- curlypaul924 8y agoBut how can you get more instant than "it's already running"? The emacs way of doing things seems to be to do _everything_ in emacs -- it's your shell, your editor, your debugger, your mail client. Vim users, on the other hand, tend to only open vim when they need it.
- rhizome31 8y ago> Vim is attractive to many because it launches in a fraction of a second I often joke than with all the Vim plugins I use, I manage to make my Vim starts as slowly as Emacs (I haven't encountered wide popular success with this joke though)
- chr15p 8y agoNot just its launch time but its ubiquity, vi comes installed on pretty much every linux/unix machine no matter how minimal the install so if you are a sysadmin whose job involves jumping between machines a lot it makes far more sense to learn vi then install emacs everywhere. Its also the reason to use it without customization so you dont come to rely on a feature that isn't installed on that one machine with a critical problem Developers tend to work on a single machine so can tailor it much more to their own preferences.
- krylon 8y agoOTOH, emacs has TRAMP which allows you to edit files remotely, using ftp or ssh as the transport layer. (Okay, I do not use that feature often, and I do still use vi sometimes for quickly editing a config file or something).
- cbm-vic-20 8y agovim comes bundled with netrw, which lets you do the same thing.
- chr15p 8y agoA normal sysadmin workflow would be, log in via ssh, poke at some log files, run a couple of commands, edit a config file, restart a service, check the logs again, logout. If you need to be ssh'd in anyway to run commands then being able to edit a file remotely is of limited value. I actually really like emacs, for a while I used it as my login shell (no x-windows and with e-shell providing a command line), and elisp is an awesome tool (in theory if not always in practice), but when I moved into sysadmining and later consulting the practical issues meant vi was by far the best option.
- AlexeyBrin 8y ago> If you need to be ssh'd in anyway to run commands then being able to edit a file remotely is of limited value. You can access the remote shell from TRAMP and run commands, just like you can access the local shell from Emacs on your local machine.
- cstross 8y agoStartup time is a non-issue for both Vim and GNU Emacs on modern hardware. (It was not ever so: I remember first meeting Emacs under DOS on a 20MHz 386. It was not speedy.) Perhaps another underrated issue affecting relative uptake is keyboard layout. As the OP explained, Berkeley vi was originally developed on an ADM-3A tty, with no arrow keys and the "Esc" key where a modern keyboard would position the "Tab" key. In contrast, Emacs first appeared in anything like its modern form on LISP machines, which had a radically different keyboard layout from a modern PC or Mac — much less austere, lots of modifier keys (not just Ctrl and Alt, but Meta, Super, and Hyper as well!), and an Esc key tucked out of the way at the top left, as is standard today. Here's s photo: https://upload.wikimedia.org/wikipedia/commons/9/9a/Symbolics-keyboard.jpg https://upload.wikimedia.org/wikipedia/commons/9/9a/Symbolic... If you consider the ergonomics of typing lots of Ctrl- and Meta- keystrokes on the Symbolics keyboard above, it's fairly clear that it requires a lot less hand stretching to play those chords in the key of Emacs. So it was a cheap design choice for the original Emacs folks to take that route — but every time I've tried to spend serious time in Emacs over the past 30 years on a PC or Mac keyboard, I've ended up with stabbing pains in my wrists within a week (and I will note that back in the 1990s FSF programmers were notorious for always wearing wrist splints). The basic vi commands can all be executed from the main QWERTY keyboard area, plus the Enter, Ctrl, and Esc keys. If the position of Esc really bugs you, you can rebind it to the Caps Lock key on your keyboard (depending on hardware support, of course). The point is, there's far less chording involved. So my working hypothesis is that vim is gaining leverage due to selection bias for an editor that hurts the hands less when you use it intensively on an IBM PC-descended keyboard layout rather than a Symbolics keyboard. But "less pain in wrists" is not something we spot easily, so a whole load of post-hoc justifications get invoked to explain the preference.
- curlypaul924 8y agoNit: "not ever" and "never" are synonymous. I think you meant "it was ever so" or "it was always so" or "it was not ever an issue". Interesting hypothesis. Ergonomics is certainly one of the reasons I chose vim over emacs.
- azernik 8y ago
- Vinnl 8y agoAs someone who came into all this "after" the editor wars and is now using Vim, these were what I understood were their selling points: - In Vim, you learn how shortcuts work and how they compose, and then you can apply them to a bunch of new situations and "guess" which other shortcuts apply. - Emacs can do a whole lot and you can customise it exactly to your liking. Oh, and it also supposedly works really well with Lisp. Not sure how accurate my view of Emacs is, but the Vim selling point has turned out to be true for me. The Emacs selling point just didn't appeal to me. I don't care for having to customise my text editor everywhere I work with it, and I don't know yet what awesome customisations there even are. I also don't use Lisp (though I'd like to, someday, and might checkout Emacs then).
- cup-of-tea 8y agoI don't really know when the editor wars took place or when (or if) they finished, but I started to look for a serious text editor around ten years ago. Before that I was using different "IDEs" for every programming language I used but I knew that it made no sense to invest serious effort into something like Netbeans for Java. I also realised that I was using maybe 10% of the functionality of these tools, and it was better for me to go and look for additional functionality as and when I actually needed it. So I started with vim. I also was drawn to the whole "composable shortcuts" thing. But I quickly realised that these key combinations were not shortcuts, rather the keyboard is the interface. I was completely sold on using the keyboard to edit text and wondered why on earth we ever forgot how to use it. The rat was banished. What stopped me even trying to start using emacs was the lack of antialiased fonts. But I downloaded and built a pre-release with antialiasing and was able to try that too. I think it was the emacs concept of major modes that initially made so much sense to me. I then quickly discovered two "killer apps": org-mode and magit. That's how the only love affair I've ever had with software started. Within a few weeks I was learning Common Lisp thanks to being advised that it would make Emacs Lisp easier. Saying Emacs is good for "customisation" is one of the grossest understatements that is so often repeated around the internet. It's repeated even by people who use Emacs and know better, but it's quite hard to describe what Emacs really is if you've never used it. Emacs is deeply related to the Lisp way itself. Emacs isn't a text editor. Emacs is a Lisp environment that is particularly good for building tools related to text. Emacs is written using Lisp and Lisp is written using Emacs. Emacs users regularly use Emacs to extend to itself while it is running. Lisp users often talk about this moment of enlightenment that happens at some point when you learn Lisp. It's real and it happens when you learn Emacs as well. But I feel a bit like someone trying to explain an LSD trip. You just have to see it for yourself. I didn't try Emacs because the above was attractive to me. I tried it because I wanted to learn a general purpose text editor and Emacs had great tools like org-mode and magit. The fact that I got to experience a kind of enlightenment and a feeling of love for software was pure luck.
- blackrock 8y agoI once used emacs. I still do from time to time. But it's too complicated for its own good. Vim works pretty well. It's simple enough to get by. But these days, I usually only use it for viewing mode. And maybe for some light editing. For anything more complicated, then I just shell into the server, and open the file in a full featured text editor.
- dmortin 8y agoEmacs has Tramp, so you can open and edit the remote file right on your computer and emacs takes care of shelling into the server in the background and applying your edits.
- Lio 8y agoVim has bcvi which is a similar concept. Whilst I'm happy to use plain Vim it can be useful if you've customised your own set up and don't want to port it to each server. For those interest in how use raw Vim as a "fully featured" editor I'd recommend Drew Neil's book, https://pragprog.com/book/dnvim2/practical-vim-second-edition https://pragprog.com/book/dnvim2/practical-vim-second-editio... http://sshmenu.sourceforge.net/articles/bcvi/ http://sshmenu.sourceforge.net/articles/bcvi/
- TeMPOraL 8y agoTramp also works with things like dired (Emacs directory/file browser) and GDB. Which means that nowadays, I often don't even need to explicitly open a shell on the server (and if I do, it's M-x shell). Tramp also handles tunneling connections and user/privilege switch. So, for instance, I can open my remote home directory, as root, on some server in another network like this: C-x f ssh:me@public-server|ssh:me@private-server|sudo:private-server:/home/me And it will just work, opening a dired view of the home directory on remote server, with root privileges. Further commands (e.g. opening files) will also work on the remote, mostly seamlessly. Internally, Emacs manages shell connections and translates your operations to shell commands; e.g. opening a file will copy it over to your system, and saving it will copy the altered version back.
- dullgiulio 8y agoNah, the weird ones use Acme: https://en.wikipedia.org/wiki/Acme_(text_editor) https://en.wikipedia.org/wiki/Acme_(text_editor)
- raverbashing 8y agoOk let me be very honest here, let's look at both editors learning curves - vi/vim You need to learn to open a file, edit it, move around and exit and the edit/view mode. Everybody learns how to do it. At first it sucks but you can learn this in 5 min. Nothing too hard, and yes, do use the direction keys, it's not the 70s anymore. From there you can learn other things - Emacs You try reading anything about it, there's something about Meta key (and apparently nobody can say what the actual meta key is without some wrangling from them because who knows if you're not coding on a Sun Sparc from the 90s so they don't want to compromise). Then something about a "prefix command" C-x (what is C? Control? Which other program uses C as an abbreviation for that?) Buffers. What's a buffer? I tried opening the help of both programs, VIM shows exactly what I mentioned there. Move around, close this window, etc Emacs? I'll copy-paste here (key bindings help) > C-x Prefix Command > \200 .. ÿ encoded-kbd-self-insert-ccl > C-x 8 iso-transl-ctl-x-8-map Why the F is this relevant or useful? Then I try to quit and it's a bit of a wrangle until it gets Ctrl-C Ctrl-X right (or the other way) Everything seems like it's actively fighting the user, and making it more difficult or convoluted than it should. Usability problems are never the fault of the user.
- zealsham 8y agoHave you tried exiting vim? :D
- raverbashing 8y agoYes, I press F1 (help) it shows me this: > Get out of Vim: Use ":qa!<Enter>" (careful, all changes are lost!) The joke is not relevant anymore
- JD557 8y agoI know this was intended as a joke, but exiting vim is now much easier than exiting emacs (IMO), assuming that the user has some experience with UNIX and uses `Ctrl+C` to exit most programs. If I start vim and press `Ctrl+C` I get an helpful message saying "Type :qa and press <Enter> to abandon all changes and exit Vim". If I do the same on emacs, first the help screen disappears (which was the one telling me to use `C-x C-c` to exit emacs and then I just get stuck with an unhelpful message about creating new files.
- kamaal 8y ago>>I don't know why emacs is such a barrier to everyone else or why vim is so attractive. Its simple. Its called 'The Rise of Worse is better'. Mainstream programming tools moved out of the control of power users long back, like decades back. We are now in a phase where every thing has to be 'easy' to use. Editors too are a part of it. Look at the continuing rise in interest in languages like Python and Go, and decline in interest in languages like Lisp and Perl. People don't want to invest any time in learning and sharpening their skills more than what is minimally necessary. In fact Go's popularity shows people don't need anything at all. Just give people decision statements, and loops. That is all they need. Selling power user tools to this crowd is asking them to spend their meagre 40-hr work week time budget on things they never even want to. Basically bulk of programming moved to API plumbing work long back, and they are not coming back ever. When the James Damore memogate episode was playing out in prime here, there were full articles posted on this very forum about the 'problems with nerd culture'- Which basically involved people spending time outside work to learn more things as inherently being anti-diversity, evil-like and a big problem to those people who want to do the 40 hour week happily go through their jobs. Basically the world is only getting dumber. Worse is Better.
- emblaegh 8y agoCan you imagine being so delusional you think vim is a dumbed down "casual" programming tool?
- navd 8y agoI think you're looking at this the wrong way. There's a place for programming languages like Go. A tool does not have to "full featured" or "hard" to be good. And using "simple" tools does not make someone more dumb. If you need a swiss army knife, then by all means use one. If you need a drill, Go ;-) with that. There is beauty in simplicity as well.
- krylon 8y agoI have used emacs for the past ~12 years, before that I used vim for a couple of years. IMHO, both editors have their strong points. Vi has the advantage that you can learn the basics in an hour or so, and from there on out it's mostly about training your muscle memory. You do a lot of stuff with very few keystrokes. Emacs, of course, is mostly about extending and customizing. Therefore, emacs requires a larger up-front investment of time, before you get to the point where that pays off. Once it does, it is awesome, but I can understand that people tend to choose an editor that lets them be productive faster. There might be more to it - I never did much customizing when using any variant of vi, for example. But that was my experience when using vi and later emacs.