- 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.
> Get out of Vim: Use ":qa!<Enter>" (careful, all changes are lost!)
The joke is not relevant anymore
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.
> Nothing too hard, and yes, do use the direction keys, it's not the 70s anymore.
All of that applies to emacs too. What's the difference?
> Usability problems are never the fault of the user.
That's contrary to the old saying: a bad workman always blames his tools.
It's in the post
> That's contrary to the old saying: a bad workman always blames his tools.
It doesn't go contrary. Some tools are bad, some don't.
That's why I choose the tool that doesn't get in the way and don't blame me for not joining their cult: vim
That is not what that means.
If GP had said "I cannot write good code in Emacs", that'd be a poor craftsman blaming their tools. But saying "this tool is not as effective as this other tool" is a thing that good craftsmen do.
(I'm not addressing the original claim, just meta-meta-critiquing your meta-critique).
If something as basic as a text editor is so unintuitive it is not the user's fault.
There's always the option of providing better examples or documentation, or a more intuitive "control scheme" which allows users to toggle between "old" and "new".
The fact that some tools choose to do it "the hard way" is almost entirely rooted in tradition and reluctance to do it another way. Not because it's better.
In my experience, the fact that I can navigate a file without taking my hands off the home row far outweighs any disadvantages hjkl might have.
With emacs, the big point is that you can do so many things in it that you never have to leave it; that also means once you have the keyboard shortcuts memorized, you can use them everywhere - besides editing text, emacs can serve as a mail client, a web browser, an IRC client, a music player, telnet/ssh client / terminal emulator (kind of), you can even play Nethack in emacs.
You can't expect to become fluent in emacs within a couple of minutes, but if you are willing to stick around, the time spent learning emacs pays off big time.
That's half of the benefit.
The other half is, in Emacs things compose and interoperate. That fancy autocomplete plugin you just installed? It will work for suggesting e-mail addresses just as well as for suggesting function calls in code. Multiple cursors? Regex search-and-replace? Keyboard macros? They work everywhere, whether you're writing code, exploring the filesystem, composing e-mails or tweeting/tooting on Mastodon.
That's the reason many people, myself included, try to move as much of their workflow as possible into Emacs. The right thinking is this: Emacs is an application platform for everything that uses text (or can be made to use text), and has much better defaults and interoperability capabilities than your regular operating system.
In other words, its not stuff that's going to drive adoption. The ggp has a point about emacs having a higher barrier to entry for complete beginners.
With emacs, as with C++ or .Net, the idea is that the effort to get familiar with the environment pays off big time after a certain point.
If somebody asks me (that happens almost never, though), my reply is to tell them about the long term-benefits of using emacs and to give both emacs and vi a try and decide what they like better. And that emacs vs. vi is not necessarily an either-or-decision. I use emacs as my main editor, but I often find myself editing config files using vi. I prefer emacs, but vi/vim is an excellent editor, too. More generally speaking, if somebody tries to frame something like the choice of editor as an either-or-question, consider if a-as-well-as-b is a valid answer, too.
I'm also inclined to say that, unless you work in a Windows shop, there really isn't any either-or to it. vim is, at this point, so pervasive that I think the real alternatives are either "just vim" or "emacs and at least a little bit of vim".
I do not. Maybe I was not clear enough, but I made the point in another comment that I totally understand why somebody would choose vim and never look back. I used vim as my editor of choice for a couple of years, and I cannot deny that it is an excellent editor. I still use some flavor of vi on a regular basis, even on OpenBSD, where mg (a lightweight editor that copies emacs' default keybindings) is part of the base system.
In my experience, most (if not all) of the people who use Vim or Emacs are programmers — and I am including sysadmins etc. in the wide category of programmers — and a programmer typically spends far more time thinking about what to type than the actual typing[1]. So I don’t see how the speed of typing is synonymous with productivity.
[1] Unless it’s a Java programmer — they spend most of their time typing — just kidding.
Yet another thing 70s got better than today's software. The defaults you're used to are a historical accident, and are also crap - that is, an impediment to productivity.
> I tried opening the help of both programs (...)
> Emacs? I'll copy-paste here (key bindings help)
How on Earth did you get there? The very first thing in the Help menu (also conveniently bound under C-h t, and also conveniently listed in help-for-help view that shows if you press C-h C-h) is the Emacs Tutorial. The thing that's designed to teach you the basics quickly. Just read and follow the instructions, and it will all make sense.
As for whatever you just pasted here (looks a bit like output of C-x ?), it's probably part of the self-documenting aspect of Emacs, which you're yet to discover. That is, you can get help and documentation on absolutely everything - including runtime values of key bindings, variables and functions (both C and elisp) used by Emacs.
> Everything seems like it's actively fighting the user, and making it more difficult or convoluted than it should.
It's not. It's just:
- following a (somewhat) consistent set of UX principles that are older than IBM CUA (which gave you CTRL+C / CTRL+V, etc.). Older does not mean worse.
- a tool for serious users, who are not afraid of spending 5-15 minutes reading the tutorial.
To be clear, I'm not arguing here for Emacs over Vim. I'm arguing here against the stupid - and stupidly common - approach that proper UX means a newcomer must be able to use the software productively after 30 seconds of exposure to it. It's a stupid approach, because the only way to do this is to dumb down the program to the point it does so little that it can be mastered in 30 seconds. Emacs, like Vim, and Blender, are tools for people who want to be productive. A prerequisite here is the willingness to learn something.
Agreed, that's why I use modern IDEs as well when vim gets in the way
> How on Earth did you get there?
f1 + ? then "describe bindings" which looks like the most relevant option
(I had opened a file with emacs first, I see the welcome page has more helpful guidance, but opening a file is usually what people do first)
> following a (somewhat) consistent set of UX principles that are older than IBM CUA
Sure, it's the same with vim, old standards
> a tool for serious users
Thanks for reinforcing my point that Emacs is more worried about gatekeeping people than being friendly
Any ideas how it could be better?
It has a built-in tutorial. It has thorough help. It welcomes you with instructions on getting help, as you noted yourself. There's plenty of guides and tutorials on-line, too. What else could it do to be more friendly, that would not involve sacrificing its productivity features?
Because it's not really gatekeeping - otherwise why would Emacs have so many, often annoying (myself included), evangelists? It's just about keeping the productivity ceiling high.
I've seen VIM portrayed as this holy grail of productivity for several years now, while Emacs has always been portrayed as a quirky complex editor.
I'm a VIM user and never used Emacs (nothing against it) but, correct if I'm wrong, both have a similar philosophy and have a higher learning curve than modern editors. They're also both extremely powerful under the right hands.
When I first got into VIM, it was from some conference video showcasing it and how to get good at it. Now remembering back I don't think I ever saw a similar thing for Emacs. I've heard of VimCasts but never heard of EmacsCasts (or something like that). It probably exists, I just never heard of it.
Maybe that's what missing for Emacs?
Take all this with a grain of salt. I may just live in a bubble regarding this :D
The thing is, just like conditional, symbolic expressions and garbage collection are pretty important for writing expressive programs, so too a power extensible interface to textual information is important for communicating with a computer. vi(m) is a great editor, but emacs is a great editing environment.
There are a couple of things to explore. I've followed your suggestion and looked at the tutorial, which is fine for the most part (Alt didn't work but it's probably my terminal's fault, ESC ESC works but it's not great)
Compare it with vimtutor.
In the 1st page vim taught how to move around and how to close VIM. Emacs is still teaching 'PgUp/PgDown'. It teaches you how to insert text 7 pages down. Vimtutor: 3rd page
For this basic operations emacs is not harder than vim it is just that they go on and on on and don't get much to the point. To find out how to save a file you need to go all the way down and then read about 'buffers' and how your file is now a buffer and you save it (??)
And that seems to be the main difference. Everything is harder than it should be. Most shortcuts involve C-x something or C-x C-something (which is not very ergonomical). It does not share the conventions or even the vocabulary of other systems.
And something that applies to vim as well: Programs should cut the crap about using direction keys/PgUp/Down/Home/End. My 80s computer had them. Every modern computer has something similar to those operations and that works on all programs. "Oh but then you have to take your hands off of home" I do use a mouse and I do use other programs, as much as I like shortcuts, I have to move my hands and there are a lot of shortcuts outside of that area.
> Most shortcuts involve C-x something or C-x C-something (which is not very ergonomical). It does not share the conventions or even the vocabulary of other systems.
Hey, Vim is the ergonomic one, Emacs is the extensible one (ergonomy improves somewhat with evil-mode, aka. vim emulation in Emacs) :).
> Programs should cut the crap about using direction keys/PgUp/Down/Home/End. My 80s computer had them. Every modern computer has something similar to those operations and that works on all programs. "Oh but then you have to take your hands off of home" I do use a mouse and I do use other programs, as much as I like shortcuts, I have to move my hands and there are a lot of shortcuts outside of that area.
The reasoning here is this: those conventions used in modern programs are hurting your productivity. Vim in particular is strongly optimized towards making your keypresses maximally efficient. Emacs much less so, but still, its defaults beat arrow keys, for which you need to move the entire hand.
FWIW, Emacs has cua-mode (named after that IBM CUA thing I mentioned), which gives you behaviour similar to every other program you know. Maybe it could be introduced to people earlier, but there's a good argument against it - CUA keybindings are really inferior to what vim/Emacs gives you.
In the process of learning a tool thoroughly you forget what it was like to not know how to do it.
So, it becomes hard to write a good beginner's tutorial. And you forget why the things which help beginners are useful, so they just look like clutter.
Personally, I don't think that 10-15 minutes reading the Emacs tutorial is much help to anyone. However, I am glad that I have spent the past few years learning how to use Emacs (and I haven't even learned elisp properly yet), and grateful to the people who made it and all the great software around it.
>I'm arguing here against the stupid - and stupidly common - approach that proper UX means a newcomer must be able to use the software productively after 30 seconds of exposure to it
No one here made the claim that Vim is better because you can be productive faster, nor was it said that productivity software should have no learning curve.
I agree that Emacs overall is more complex overall (which is not necessarily a bad thing), but from a "first impressions" perspective, Emacs wins.
Do M-x (alt-x) and type help-with-tutorial, hit your enter key (RET in Emacs jargon).
";; This buffer is for text that is not saved, and for Lisp evaluation. ;; To create a file, visit it with C-x C-f and enter text in its buffer"
It comes with a Menubar as found on most applications and rightmost is one labeled help, the first entry goes to the tutorial
"Emacs tutorial. See end for copying conditions.
Emacs commands generally involve the CONTROL key (sometimes labeled CTRL or CTL) or the META key (sometimes labeled EDIT or ALT). Rather than write that in full each time, we'll use the following abbreviations:
C-<chr> means hold the CONTROL key while typing the character <chr> Thus, C-f would be: hold the CONTROL key and type f. M-<chr> means hold the META or EDIT or ALT key down while typing <chr>. If there is no META, EDIT or ALT key, instead press and release the ESC key and then type <chr>. We write <ESC> for the ESC key.
Important note: to end the Emacs session, type C-x C-c. (Two characters.) To quit a partially entered command, type C-g. To stop the tutorial, type C-x k, then <Return> at the prompt. The characters ">>" at the left margin indicate directions for you to try using a command. For instance:
>> Now type C-v (View next screen) to scroll down in the tutorial. (go ahead, do it by holding down the CONTROL key while typing v). From now on, please do this whenever you reach the end of the screen."
It goes on at length covering all basic aspects of using emacs. Under the help menu there is also an extensive manual.
If this isn't discoverable enough a logical response would be to type Emacs tutorial into your favourite search engine and read at least one of the results. You say "Usability problems are never the fault of the user." and your not wrong per se but tools have intended audience and reasonable expectations. Scalpels and coffee pots are made for different users and its challenging to make a scalpel that would enable a surgeon to remove an appendix without having to crack a book.
Microsoft office which is aimed at a much broader and less skilled user base makes it very easy to enter a little text but its very normal for users to receive training, google for answers, and RTFM.
Regardless of what anyone hopes neither vim or emacs are much used by random joe to read their email they are tools made by technical people for technical people.
Given the audience I don't think its unreasonable to suppose that people who bypass both tutorials, and manual in favour of describe bindings and leave without a pit stop at the search engine might be the cause of their own discontent.
Let me make a wild guess here. You got frustrated. Took a minute to consult google to figure it out and moved on but you left that part out because it didn't support your position.
- 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).
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.
Emacs still is not that high of a priority for me to learn (I don't care much for org-mode or non-CLI-git), but at least it's on the list now, so well done :)
Most Emacs users don't use it for lisp (aside from programming the editor if needed).
Evil, the Emacs vim plugin, implements the vim commands plus some popular vim plugins (like vim-surround), and the resulting experience is awesome. I'm a heavy Spacemacs user and the user experience is so well done that it is a joy to use.
Really? It would have to be a modal editor to use vim commands. Emacs commands, on the other hand, could work with the vast majority of editors out there, and actually do work in many cases. readline, for example, which is used by bash and many other CLI programs uses emacs bindings. fish and zsh use them too.
Or it would have to emulate them. Which is what VSCode, Atom, Visual Studio, Eclipse, Intellij, Netbeans, Kate all do. Those are just the ones I have used, I'm sure there are plenty of others.
> I'm sure there are plenty of others.
Emacs, for one.
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.
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.
I understand that some people have simple needs. I don't. The editor wars are over for me and Emacs has won.
(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.)
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)
Developers tend to work on a single machine so can tailor it much more to their own preferences.
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.
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.
The number of Unixoid systems I have to take care of is sufficiently small that installing emacs on all of them is no big deal. I usually start an emacs daemon after booting and use emacsclient to fire up an editor, which is almost instantaneously.
eshell supports TRAMP: from an eshell, you can do something like 'cd /ssh:news@news.my.domain:/opt/news/etc' and then run `ls` &c., seeing the results you expect. You can run 'service restart innd' or whatever you'd like, it it runs remotely.
Yeah, emacs is pretty awesome.
I'm a developer, not a sysadmin, though I try to do most of my ops work via Tramp these days. I wish an actual sysadmin and Emacs user could chime in and say something about their workflow, and the problems they encounter.
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/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.
Interesting hypothesis. Ergonomics is certainly one of the reasons I chose vim over emacs.
"Ever so" = for all, so
"Never so" = for all, not so
"Not ever so" = not (for all, so) = there exists, where not so.
The last is fairly clearly the intent of GP. Startup is short either way now, but there exists a time when it was not short - insert references to old slow hardware that would take 10-20 seconds to boot emacs.
I used to think "emacs pinky" was a joke, but it is real. Eventually I learned how to re-map Caps Lock to be a Ctrl-key (I never used Caps Lock anyway), and Caps Lock is far more comfortable to reach with my pinky than either of the regular Ctrl-keys.
Side note - I've noticed a big improvement in general hand pain since I got into climbing regularly, and specifically starting working with a hand exerciser.
It apparently originates from typewriters, when holding shift was quite physically taxing (since it literally shifted all the typeheads over to put alternate characters over the ribbon); so caps lock saved a lot of finger strain when typing acronyms or writing symbol-heavy text.
It's 2018; our keyboards could stand to keep up.
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.
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.
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-editio...
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.