> While Emacs certainly still has a following, some people think that the Editor Wars are over and that Vim won.16 The 2018 Stack Overflow Developer Survey suggests that this is true; only 4.1% of respondents used Emacs.
I'm an Emacs user for years now and love the editor. But I'm curious about this claim of its poor popularity. The article refers to a piece from
http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruc... which bases its arguments on two surveys from 2013 and 2014.
Does anyone know of a credible way to measure the popularity of Emacs and what the usage trends are in 2018 other than SO?
The majority of "vim users" are painful to watch using it solely in visual mode with arrow keys and pressing backspace like crazy when they want to delete something.
That's always funny. I have the same reaction with IDE users who vocally disdain my use of Vim. Usually, I find they're copying and pasting with a mouse in a solitary window in the centre of the screen whilst boasting about syntax highlighting. :D
Of course it's great to see someone who actually really does know any piece of software give a demo of how they use it.
For Vim newbies I'd point people first to the Vimtutor and then to http://vimcasts.org/ as a starting point.
Definitely. I can't see a reason not to if it works for you.
The few times I've tried IDE plugins they get the Vi/Vim basics right but usually fall down later.
The terminal means that I can almost always have consistent keyboard based workflow across platforms.
I like being close to the OS and use external tools for things like git, debugging, profiling, etc.
I'll supplement that with GUI tools when it suits me. E.g. for web work I'd use Chrome for it's debugger and profiler.
I really like that things like Language Server Protocol are offering IDE like features without being tied down to a particular GUI IDE.
There' more than one way to do it though so if GUI IDEs are what you prefer more power to you. GUI IDEs haven't been new technology since the 80/90s. They're just different.
Probably not the majority but yes quite a few developers out there that are “vim users”. I had one friend who would rave about vim and then I learned he didn’t know how to copy paste...
The majority of "vim users" are painful to watch berating other programmers out of a misguided sense of self importance and overblown massive egos all because someone else dares to use the mouse to do something when they could save less than 1 second by using a hotkey instead.
People are most productive when they use the tools they know best. I use vim all the time, but I also like to use the right tool for the job, and sometimes that tool is an IDE and other times that tool is a gasp mouse.
( P.S. Please don't take this comment too seriously or personally, I am mostly kidding and am being extra hyperbolic on purpose because this thread seems like such a wonderful opportunity to rehash the never ending vim vs sublime debate and I wanted to get the sublime side of the argument off on a strong footing ;) )
I have been amazed how many really good linux people will close and re-open a file in vim because they dont know how to undo.
Its weird to me how people will spend weeks learning openstack or kubernetes in depth but never think "there must be a way to do this..." or get round to googling a 5 minute basic command tutorial for the text editor they use every day.
Completely anecdotally I've ever met two person who used Emacs and handful of people who use vim. At my current job I'm the only one who uses vim as my main tool, but collegue sitting next to me is the other Emacs user. Although some poeople have started to dabble in vim every now and then. I guess people just run into vim more often in the wild.
It's an anecdote that describes my experience as well. In more than ten years I've only met three other people who use Emacs (and one other person who uses WindowMaker :-) ), and I've often been the only Emacs user in an entire department.
I've been using evil-mode for a few years and I'm also very happy with it. It's the only vim emulation I've seen so far that implements "g?" (rot13). That's how compatible this mode is.
Already running it! Although I have this in my head that I need to create my own emacs configuration from scratch and learn more how it works. Someday...
I use a Mac, where most text field by default support at least some readline keybindings, so Emacs knowledge comes in handy :)
(try it yourself! If you're on a Mac, open the reply box in a browser that uses Mac-native controls, and start typing, then hit C-a or C-e or other readline key combos and see which ones work)
There used to be a kext that would make Mac text fields respect vim keybindings. (Maybe there still is, but I've lost track of how to use kexts safely these days, or whether it's even possible.) I miss it terribly.
> a huge number of other editors have vim keybindings as an option or plugin: intellij, eclipse, visual studio - the list goes on forever...
I think I managed to crash the IntelliJ vim keybinding mode like twenty times when trying to get used to vim.
I did try later to just use vim on it's own, but it really doesn't appeal to me at all, I have to google pretty much everything I need to get done and that takes so much time, is there a way to make vim show a help bar just like nano has?
I printed a cheat sheet. The first 1-2 weeks are less productive. After that, it’s «life before and after». Would recommend learning plain vim, just to keep yourself from getting confused from what’s vim and what’s intellij.
/r/Linux is biased to sysadmin types but there are other communities where Emacs is more popular, for instance in some academic fields (where Mac OS tends to be more common).
At work, I use Windows, and I use emacs all the time; it's among the first programs I start after logging in. On top of everything else, it has a builtin "shell" that is a reasonable approximation to a Unix shell.
I mainly use macOS for example. At least on the systems where I use Emacs. I use Linux for servers, but I rarely do much editing directly on those systems.
Stupid poll. Due to the limited options, people who use neither editor seriously have voted vim simply because they know about it. Also it can't be denied that vim is the hipster editor, used by the same kind of people that use reddit. People that use emacs, like me, do not vote in polls on reddit.
I meant to say vim is the "hip" thing, as in, it's in fashion with a certain type of programmer for some reason. Fashion definitely exists in our world, even though it's hard to admit. In my (purely anecdotal) experience, vim gets a lot more lip service than actual use.
I use Emacs and this is completely anecdotal, but I agree, it feels like vim is the hip editor. I think it started to become hip when Rails gained traction. A lot of screencasts using vim. I guess this was when TM had fallen out of favor or something.
A lot of Elixir devs use vim, as well, and many came from Ruby/Rails.
Or maybe vim is massively over represented in those other polls. Lots of people claim to use it. Few customise and really live with it and thus are not likely to subscribe to a subreddit about it. I know "vim users" that actually use pycharm with vim keybindings if you actually watch them. If that's OK then everyone who uses default readline bindings is an emacs user.
My personal journey. My first editor was vi. Then I learned about emacs and used it for a few years. But I still had to use vi when I logged in remote machines that didn't have emacs. When vim came a long, it was almost as good as emacs and I could use it everywhere.
Conclusion: vi/vim was everywhere already.
Now days I use sublime. I still use vi/vim when using *nix servers.
Same. What forced me back to using ed, ex and vi was the then-design of unix: if you were in the middle of recovering a truly borked server then only the static binaries were available.
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.
Ok 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.
> Nothing too hard, and yes, do use the direction keys, it's not the 70s anymore.
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.
> 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.
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.
Thanks for your thoughts. The tutorial could definitely be improved and restructured.
> 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.
Honestly I feel that it has become more of a fame and dissimination thing than anything else.
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
I think it's basically the Blub Paradox for editors: vi(m) is so much better than almost any editor, that its users think 'this, this is truly the best!' When they look at e.g. nano or Notepad++ or Atom, they can easily see how vi(m) is so much better, but when they look at emacs, they simply think, 'nah, I don't need to use that!'
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.
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.
You're addressing something that is not really related to raverbashing's point. It's just a quick look at learning curves.
>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.
> use the direction keys, it's not the 70s anymore.
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 also means once you have the keyboard shortcuts memorized, you can use them everywhere
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.
As great as that is, though, they're all advantages that won't become relevant until you've really learned emacs, and won't become really advantageous unless you're comfortable enough with emacs that you're willing to commit to it.
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.
But having to spend a lot of time getting familiar with some tool, language or framework is not unusual in IT/Programming. Think of C++, or the .Net framework. When programming in C#, I spend at least 1/3 of my time browsing the API documentation or StackOverflow, TechNet, etc.
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.
Fair, though, I think the story is a bit different with editors. Ultimately they're just a means to an end (editing code), and it's obviously true that plenty of people are able to work successfully with either of them, so you can't really fault people for just picking one to learn and going with it. Learning both intimately enough to make a serious comparison is a time-consuming prospect.
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".
> you can't really fault people for just picking one to learn and going with it.
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, the fact that I can navigate a file without taking my hands off the home row far outweighs any disadvantages hjkl might have.
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.
Your comparison is a little unfair. If you just want to use it as a text editor, Emacs is easier to use than Vim. You can move around with the arrow keys, typing letters inserts them into the document, there are the standard menus, toolbars and scrollbars you would expect. In other words, if you're looking for a "Notepad replacement", Emacs works just fine as that, and you don't have to learn anything about the meta key or whatever.
I agree that Emacs overall is more complex overall (which is not necessarily a bad thing), but from a "first impressions" perspective, Emacs wins.
I 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.
";; 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.
> 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.
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.
> That's contrary to the old saying: a bad workman always blames his tools
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).
Usability is always and without a doubt the responsibility of the designer. The old saying might be valid for tools that are meant for complex tasks. Expert level tools where doing the job a certain way is more important than doing it intuitively. In reality that saying is mostly used as an excuse for a tool that could be more effective but isn't.
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.
As 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).
The vim commands are mostly great, they are a fantastic set of hyper-productive defaults we all should learn. One of the reasons is that almost every other editor has the ability to use vim commands.
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.
> One of the reasons is that almost every other editor has the ability to use vim commands.
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.
> It would have to be a modal editor to use vim commands.
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.
On macOS, the standard widget for text input supports emacs-style shortcuts, too, which means you can use them pretty much everywhere. One of the few things I miss about macOS.
I 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.
Well, you explained the attractiveness of both vim and emacs better than I did, so I now better understand why people like Emacs, and I hope this also helps explain to the grandparent why people often try Vim.
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 :)
>>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.
I 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.
Vim 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.
Startup 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/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.
> 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
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.
Wouldn't you hit ESC with your ring finger or middle finger instead? (When I used vim, I preferred Ctrl-C so I would not have to move my fingers so far.)
That would require lifting my hand off the home row, which would be uncomfortable on my wrists. Playing around with it now, the motion seems to be more of a sideswipe, with a bit of muscle tone to keep the finger from just bending out of the way.
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.
Because you got me curious enough to look this up:
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.
I like mapping jk to ESC for vim/evil-mode, then swapping caps lock and CTRL for the comfy tmux and readline ergonomics. (I've tried readline's vi mode, but I didn't like it.)
Emacs is sufficiently powerful that I think it’s worthwhile to use a keyboard with a proper set of modifiers. Moreover, the emacs approach is sufficiently powerful that I think it's worthwhile to use a keyboard with a proper set of modifiers in any program. Use easily-hit keychords for common functions and more-difficultly-hit chords for uncommon ones; maybe even reserve a prefix for certain uses (e.g. Super for the OS & Hyper for the user).
Your equation of "not ever" and "never" is off - "ever" means "always", and "never" means "always not" ("ever not"). In logic terms:
"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.
Not 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.
OTOH, 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).
A 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.
> A 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.
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.
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.
That's true. In the eternal Vim vs. Emacs discussion, I found that preference is correlated to whether a particular person feels more like a ops/sysadmin, or more like a programmer. As you wrote, developers tend to work on a single machine, while sysadmins tend to jump between many machines.
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.
The 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.)
I 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.
But 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.
> 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)
I 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.
Emacs 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.
Tramp 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.
>As far as I can gather, Intel HEX files are meant to make binary images less opaque
I know this is getting away from the main point of the article, but they're purpose is more to have a standard format that compilers can generate and eprom/device programmers could read without being concerned with the machine's endianness. Pretty much any embedded compiler can produce a .hex file, and pretty much any programmer will read one.
When I was a kid I liked to poke around executables in the MS-DOS world. Hex editors were limited in the sense that they wouldn't let me insert bytes into the file, just edit existing ones. Because I didn't have access to an disassembler or an assembler (they were sold at stores but they were too expensive for me), I wrote a simple program that would convert a binary file into a text file full of hex codes, then I could edit that, change jumps to different addresses, change strings, and then I would reassemble the executable with another program to see the effect. I used this to translate programs and games to Spanish by changing the strings in the executable. Messages in Spanish are in
average longer than English ones, so I couldn't just use a hex editor.
It's funny to me that the hex file format is a real thing.
And, unfortunately, it is a destructive process going from elf to hex, as I've discovered a few times. Intel HEX is just the data at what addresses so one looses the section info and metadata from an elf.
I'm always happen to see when a uC vendor IDE keeps the elfs and the programmer takes elfs.
I see MS-DOS is mentioned near the bottom, but the part I was most curious about was not.
When I got my dad's old Windows 3.1 laptop somewhere around 1999, I discovered DOS and started fiddling with it, eventually discovering the "edlin" editor. Everyone else though it was bizarre and hard to use, but I really liked it because I could look at different parts of a file at the same time.
The commands were similar to the example given here for ed, but the output much much easier to read. Does anyone know if it was another clone or just coincidence?
>When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
>TEXT EDITOR.
>When IBM, in its ever-present omnipotence, needed to base their “edlin” on a Unix standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.
> Does anyone know if it was another clone or just coincidence?
EDLIN was a clone of CP/M ED. Was CP/M ED influenced by Unix ed? I don't know, but I somewhat doubt it. Gary Kildall's primary background was in IBM mainframe and DEC minicomputer systems (in particular VM/CMS and TOPS-10), and so it seems to me more likely that CP/M ED was influenced by DEC or IBM line editors, than by Unix.
That said, Unix and IBM mainframe operating systems share some common heritage. Both were influenced by CTSS. So, it may be that any observed similarities between CP/M and Unix line editors could be due to that shared ancestry, rather than any direct influence of Unix on CP/M.
CP/M ED is more in the TECO tradition than anything else, through the DEC influence. It is oriented around characters rather than around lines as the ed family is.
And if you keep going back, TECO (like QED) can be traced back (via ports, rewrites, shared authors, etc) to the PDP 1 and Colossal Typewriter. All those histories are intertwingled back then.
I was around 12 and got an assembly programming book. It stated that one has to use decent text editor like edlin to write assembly. Well, I went for it and even entered few programs until realizing that under norton’s F3 it is just a regular text file. After a little frustration and experiments with F4 I understood that edlin wasn’t special for editing .asm files. F8 on edlin.exe was the first thing I did afterwards. Or was it edlin.com back then?
During the DOS 5.0 days I discovered EDIT.COM and the split windows blew my mind. I would view function prototypes or structs while writing code in the window below. And I could do it in 80x43 instead of 80x25!
I wouldn't be surprised if a large part of Vim's current popularity stems from EDITOR=vim by default on many distros, despite often having emacs and always including nano. Even over a decade ago when I was in my early teens this seemed pretty common.
I believe EDITOR=vim in turn stems from vim being able to run in restricted mode.
I once saw a hardcore emacs user forced to use vim because he was building a setup that allowed shell users to edit a file. And couldn't do that in emacs. So he had to use rvim -y.
I myself once built a nethack shell server where I used rvim to allow users to edit their nethackrc.
So distros preferring vim can either stem from it being vi-compatible which is POSIX. And/or from having a restricted mode.
To be honest I've seen very few linux machines with emacs preinstalled, nano seems to be part of the ubuntu default install (maybe debian too?) but isn't on any fedora box I have immediate access too (it is available in the repos). This might be because I mainly deal in servers with smaller installs than most desktops.
I would entirely agree that a lot of vims popularity lies in it being part of the default install on pretty much every unix box ever though. That and it actually being a decent editor once you get over that initial insert mode/command mode learning curve.
Definitely a part of it, I’m an emacs user but I’ve been on enough machines that only have vi(m) and that I just need to make a quick edit on that I’ve had to learn the basics of vi anyway.
Vim by default reminds me of organ donors. In countries where people are considered organ donors by default and have the option to opt-out, organ donor stats increase dramatically.
Though e-lisp is great and I appreciate the power and regularity of Emacs, Vi(m)'s mode-full, default cmd-mode editing that doesn't require ctrl + meta + esc left_foot_pedal + wink-wink-nudge-nudge... seems so much nicer to me than insert-by-default editing - thank goodness there are vim plugins everywhere.
The TRS-80 Level II line editor was very much in the spirit of "em", along with other BASICs of the day.
I'm always kind of curious about comments like this -- it seems everybody knows you have to play games of Twister and hit twelve control keys simultaneously to do even the most basic things in Emacs.
But... I use Emacs. I've been using it for almost twenty years. And I'm struggling to think of anything I use regularly the involves hitting more than two total keys simultaneously (keys pressed in sequence obviously don't work as an argument, since that's also how you edit in Vim). I think the only one is query-replace, because it involves hitting Shift to compose the M-% combination.
And I don't use a ton of custom keybindings, either. The only custom binding I use that's simpler than the default is goto-line, which I have bound to just M-g.
Do people genuinely run into cases where they frequently have to be hitting 3+ keys simultaneously to use Emacs? Or is this just one of those "everybody knows" things that's actually completely false?
If it wasn't clear, it was hyperbole...
It's just my personal preference that in general I don't like using modifier keys at all, as I will often mangle things, especially when switching between keyboards. The major factor though is the basic approach -- command by default, insert is sub-function (vi), vs. insert by default, command is sub-function (emacs). (I like to fiddle around and use the j/k or -/enter to move around in the file while I'm thinking w/o entering anything into the buffer...)
I have respect for emacs die-hards - though I suppose that those who never leave and still do shell, email, news, web browsing, etc., from emacs are few and far between.
As a lisp fan, the best of both worlds for me would probably be an emacs vi-mode with lisp programability - but I can't depend on such a thing everywhere
I'm a long-term vim user but I felt the need to look into emacs to see what it had to offer. I messed about with various implementations of emacs until I found Spacemacs and then - may I quote Keats here?
"Or like stout Cortez when with eagle eyes
He star'd at the Pacific—and all his men
Look'd at each other with a wild surmise—
Silent, upon a peak in Darien."
Substitute Spacemacs for Pacific and we're on the same page!
Evilmode is useless for long-time vim users with muscle memory. Things such as different behavior of ?<Up> or /<Up> are frustrating. Also many popular plugins (such as orgmode) interfere with evilmode. And movement between windows. And there's not even a consistent keystroke to close a window in emacs, and evilmode's mapping of q muddies the situation even further.
I'm not sure why you're telling me this. I'm just pointing out that Spacemacs is not an alternative to evil-mode, since the latter is a fundamental part of the former.
> Do people genuinely run into cases where they frequently have to be hitting 3+ keys simultaneously to use Emacs?
Paredit mode has several useful ones for writing elisp.
- C-M-f, C-M-b, and C-M-u (forward-sexp, back-sexp, and up-sexp)
- C-( and C-) (barf and slurp commands)
- C-M-k (kill-sexp)
M-: (eval-expression in the minibuffer) is also a frequent command for me.
I've overlaid several keys in the number row with Control and Alt, so they are nice to press with my middle and ring fingers (as opposed to pinkies). I've been meaning to write a blog post about this.
Only barf and slurp are paredit commands, the others you mentioned (the sexp motion and killing commands) are stock Emacs!
(Well, by default C-M-u is bound to backward-up-list, either that's what you meant or paredit really defines a slightly different up-sexp commands. I don't remember right now.)
The worst command I regularly use, in terms of number of modifiers, is definitely C-M-% for query-replace-regexp.
I think this is just one of those memes, like Vim being difficult to exit. It's OK for banter but not to be taken seriously.
Vim itself has many corded commands which I find are especially useful in Insert and Ex mode.
As a long time Vim user I know I'll probably never move to another editor like Emacs. That's because of familiarity with Vim and not because of any failing with Emacs shortcuts.
There's no single editor-personality. Some people hate vim default mode, they prefer emacs self-insert and accept the rest a 'sensical' gymnastics to do complex things.
With time you end up enjoying both way of life, I despise some ergonomics of emacs, and I really love the crystalling side of vi command systems (it's almost a tiny algebra of text sculpting).
> And I'm struggling to think of anything I use regularly the involves hitting more than two total keys simultaneously
One I can think of is M-! (shell-command). I'm a vim user, and I frequently use the corresponding :r !some_command to read output from a shell command into the vim buffer.
> Do people genuinely run into cases where they frequently have to be hitting 3+ keys simultaneously to use Emacs? Or is this just one of those "everybody knows" things that's actually completely false?
Search and replace with regular expressions takes 4 keys in the default bindings! The command query-replace-regexp is bound to C-M-%, which means ctrl+alt+shift+5 on most keyboards. (To be fair, you can also replace alt with previously pressing esc, so "esc then ctrl+shift+5".)
The default undo binding in emacs (C-_) takes three keys (control, shift, hyphen). I use that quite a bit, but I don't find it burdensome. I also map control to the caps-lock key on my keyboard.
Emacs really hurts my hands. Maybe evil mode is for me? I like lisp and want to learn emacs, but vim seems more elegant when you don't need to write anything yourself.
On the contrary: with vim you have to write everything yourself over and over. With emacs you capture it in a Lisp function once and never write it again.
That's a sequence, though, right? Like, you aren't expected to hold Meta, m, x, d and SPC down simultaneously, you're pressing M-m, then x, then d, then SPC. Which is no different from some lengthy Vim command sequences.
(and in GNU Emacs, just-one-space binds by default to M-SPC)
You can have Vim-style editing in Emacs via Evil mode. This way you get the best of both worlds. I used to be a hardcore Vim user for 10 years, switched to Emacs/Evil mode for Elisp, and never looked back.
I still fondly remember lynx it was like the vi version of the web browser. There is an O’Reilly book called “spidering hacks” which goes into some of the advanced stuff. Lynx was the Swiss Army knife which could host, execute, parse, and script web pages in a single command (lynxcgi). It was also decentralized and could run through telnet or raw sockets inside a VMS system. Vi keys and Emac keys were options either of them could be set as the html editor making it seamless.
I don't think I could write an editor with regular expressions from scratch in a week. Especially if you took away the internet and 99% of my CPU and RAM. Fail.
True it is missing regular expression-support, but it does have find, and many people (including myself) have forked it to added regexps, lua-scripting, and other advanced features.
> Fred Fish was an American programmer that mailed out a floppy disk every month with a curated selection of the best open-source software available for the Amiga platform.
Fish disks contained mostly freeware/public domain as far as I remember. Not open-source software.
The name "open source" had not even been coined at the time. "PD" was a popular contemporary prefix for things, although their actual public domain status was legally questionable, irrespective of the FSF's objections to the idea.
It's time to give a spotlight to NeoVim that puts efforts into getting rid of legacy craft while maintaining compatibility to move vi past 50 years of usage.
Last time I checked, there's no clear advantage from users' perspective for now but some plugins have started targeting it as the primary platform and also a few GUI are being developed too.
C shell could have been the de facto standard had the parser not been buggy as hell and had there been proper facilities for stdin and stdout like in Bourne shells.
tcsh is my default shell, but I never program in it because of “C shell considered harmful”[1]. I write my programs in original Bourne shell instead for maximum portability.
Fred Fish was a great programmer I was quite delighted to work with. We happened to stop by his house on our honeymoon, (although that was because our car broke down in Phoenix, but my wife liked him too). I was sorry when he passed away.
When you are learning programming, its important to be able to isolate the problem you are working on and focus on that. The fact is that vim has a steep learning curve, and no matter how fast you are at typing things, your rate of productivity is still limited by how fast you can make decisions and how fast you can think and solve problems. I strongly believe that mastering hotkeys and tools like vim is the final stage of achieving the highest levels of programming skill. This is because once you have learned so much and trained yourself hard to think and move really fast, only then does your productivity bottleneck become things like using the mouse too much, not knowing certain hotkeys, not using things like regex replace, multi-line edit, and so on. The problem is mastering a single tool requires a tremendous amount of investment of time and energy, and once you are at the point in your development as a programmer where you need to start improving on hotkeys, well you are already deeply invested in whatever tool you are using and making the switch to vim has a major cost associated with it, because now you have to learn everything you already know how to do all over again. Is this cost worth it? Sometimes, depending on how advanced a person is, other times, depending on the situation, it's not. I think this phenomenon explains a lot about why vim is not as popular as perhaps it deserves to be.
I still use the original, AT&T vi since I grew up on UNIX and Solaris 2.5.1 was my first UNIX OS after using my Amiga.
Even when I’m on a GNU/Linux variant, I run vim by calling vi, primarily because syntax highlighting enrages me to no end.
vi won because it came with every UNIX by default, and when one is in a cold server room connected to /dev/console via serial port at 3 o’clock in the morning, one quickly learns to appreciate vi’s ready availability and ubiquity.
Emacs on the other hand was always a huge program, was never bundled with UNIX by default, and compiling it on one’s own always ended in failure somewhere around Emacs wanting to compile itself as an Xwindows application.
Add to that that Emacs had completely different key bindings and users would have to adapt to it rather than it letting them use their prior knowledge, it was a death knell to Emacs. Later versions added vi key bindings (“evil mode”), but since the pre-built versions continued to insist on Xwindows, it was wholly unsuitable for servers; for example, an SGI Origin 200 or Origin 3000 didn’t even have a frame buffer nor did they need Xwindows, and neither did the hp K-, N-, or L-class servers. Meanwhile, vi continued to be the UNIX system administrator’s trusty friend: always there, with no additional software requirements.
Ironically, when I’m on the Amiga I use vim, but there it doesn’t have syntax highlighting which I hate, and so is usable out of the box (I use it as I would vi on UNIX, without any extra vim fluff).
I'm an Emacs user but I'm really surprised at the number of (presumably, as HN skews young) younger people here using vi or derivatives. Most younger people I know use neither vi nor emacs, using Sublime Text or an IDE or something, but vi seems much more alien to the modern worldview than Emacs, as it a modal editor, which has died out in all but vi-clones these days.
26yo astrophysicist / datascientist here. Using neovim since two years now and before vim for 3 years as main editor.
I don't know anyone below 40 using emacs. (Neo)Vim using (lots of) plugins has a pretty solid user base around here. Most is Atom / VS Code / Jetbrains IDE but vim has a solid standing especially along the more enthusiast programmers.
That's a great read. I'm not a hardcore vim user, but like most devs I bump in to it often enough to get somewhat familiar with its wacky interface. I always had this feeling I'm using a legacy tool (in a nerdy positive way) even though it's relatively young. This article shows that my feeling was quite accurate.
I've tried emacs a couple of times over the years, but it never really stuck for me. Not sure why. I use vim as my main editor on the job and at home. The more basic commands have become second-nature and every now and then I go read about something I haven't played with yet and make it part of my workflow.
I can't stand IDEs. I understand their benefits, but the amount of resources they take up appall me at some deep level. I'll use them and grumble if I need to. I haven't really liked an IDE since the Turbo Pascal 4.0 days. I also have a thing about not liking software that tries to second-guess me. I'll take a vim session loaded with files and another terminal window to build the project in and I'm golden. Of course, I'm not working on huge projects for the most part. Maybe it's an old-person thing.
They didn't answer this question. The most obvious to me is that Linux distros have had it as the default for decades. If FreeBSD caught on instead maybe we'd have people writing the same article about the amazing history of nvi.
This is a weird thing to me. When I was getting started with this stuff, everyone out there acknowledged that vim was a vi clone in the first breath. There are now lots of folks that think vim is the primary thing. Kind of similar to how they call shell scripting "bash". I guess it's rather like asking what brand of Kleenex, or a Coke in the southeastern US.
> ...Emacs could cost hundreds of dollars (this was before GNU Emacs)
Emacs clones (of various levels of compatibility) for unix and other systems could be purchased back around the time this sentence is set, but to be fair, the original Emacs (or EMACS -- the ITS filesystem only had upper case) evolved by RMS et al from Gene Ciccarelli's TECO init file was naturally free. And Bernie Greenbergs Emacs clone for Multics (called emacs because Multics was case sensitive) was also free (and the first one, as far as I remember, to be written in Lisp).
I used one called Mince, I believe, on CP/M machines - I think on a Compucolor or Cromemco or something. There was another I can't remember the name of.
Ah: https://en.wikipedia.org/wiki/MINCE
And found this - Lynx friendly as well! http://www.texteditors.org
For some reason i'm not the biggest fan of vim on a computer. But, vim on android with termux is the best editor i've found for android and I don't know why but as weird as it may seem using vim with the right touchscreen keyboard isn't actually that bad. It's the only realy solution i've found for doing small amounts of programming on my phone. Nothing big, but for small hundred line or so, scripts and such vim is definitely the best thing i've found to use on android.
> Thompson paid a visit to Queen Mary’s, saw the program Coulouris had built, and dismissed it, saying that he had no need to see the state of a file while editing it.
How old are regular expressions, when the predecessor of `ed` already got it?
Edit: Found it[0]
Regular expressions originated in 1951, when mathematician Stephen Cole Kleene described regular languages using his mathematical notation called regular sets.
I recall the early days of RoR crowd were pushing for Vim too. It was hipster in term of adopting new and awesome things and RoR crowd really push some new things. This was when the editors war was still a thing.
In the early days of Ruby on Rails Textmate was the recommended editor. DHH used it in the original blog screen-cast showing off features such as snippets and fuzzy file finding that weren't commonly supported in Vim in 2005/2006
I don't get your statement. But to clarify I was talking about how the crowd in RoR have a high uptick on vim editors. I was reminiscing on the old days of RoR that may have contribute to some more people adopt Vim.
I don't see this gets mentioned much but this is one of the larger reason I never use emacs. When quick editing files on remote servers, snappiness is really nice, even with bunch of plugins activated.
You can run emacs as a daemon and run emacsclient -c to open a new emacs window connected to the existing instance.
This is instant no matter how complicated your config. You can also edit remote files via tramp so you never have to leave your local emacs instance.
This means that the proper comparison is instant access to your customized instance with your plugins vs instant access to whatever environment you can sync with all machines you intend to access.
You use it wrong. You're supposed to keep your local emacs running and use tramp to login to the remote server. That way you still have your emacs config with you and don't have to load it again.
What vim users don't seem to understand is: I never restart emacs. Mine stays running for weeks, even months at a time. When I change my emacs config I just run the code. I don't restart emacs.
You understate how great tramp is. It is what allows me to simply not care whether a file system is local or remote. They all behave like local file systems under tramp.
No. We're talking about highly specialised tools for professional engineers, not some dumb electronics made for children and old people. You're using the tool wrong. Emacs is not vi.
This is a great historical trace / origin story. And now it all makes sense. But I'm a little disappointed. As someone who came to vim from the world of Notepad / Wordpad / WordPerfect / Word, vim, when I finally learned how to be productive in it, seemed so revolutionary and amazing. I sort of was hoping for a story that justified this feeling, like "Bram had a dream one night where alien greys appeared to him and told him he had a mission for humankind. They then showed him source code for a perfect text editor used in the Aldebaran system for millennia. It's name, they said, would be vim. Bram created it in a non-stop 3 day sprint before expiring for 1 month."
This is, in fact, the story behind Lisp Machines. Unfortunately, humans quickly forgot the lessons from the aliens, and made computing the mess it is today.
The history is documented here: http://landoflisp.com/ (scroll down and follow the arrows).
I'm an Emacs user for years now and love the editor. But I'm curious about this claim of its poor popularity. The article refers to a piece from http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruc... which bases its arguments on two surveys from 2013 and 2014.
Does anyone know of a credible way to measure the popularity of Emacs and what the usage trends are in 2018 other than SO?