Emacs Timeline
emacs.brause.cc
emacs.brause.cc
The 0th entry should be the addition of “^R MODE” to TECO, which was the interactive display editing mode for what was previously just a text mode editor like Multics qed or its descendant, Unix’s ed. I believe ^R mode (an MIT extension) was around ‘75.
But this is second hand as I was quite late to the party, not encountering Emacs until 1978.
IIRC I went digging around the simh ITS packages (hard to do since it's an alien filesystem image, not exactly a consumable tarball) and couldn't find it.
I didn’t discover Emacs until almost two decades later and I’ve been using it my entire career. It’s truly remarkable longevity.
No reason to think it shared code with anything else in the tree, of course.
I think the biggest issue is that people are simply intimidated by learning Emacs from the bottom up themselves. It has an incredibly extensive tutorial baked in. It's almost completely self-referential which distinguishes it from most stuff people engage with today. And that's the crucial part I think because if you start copying other people's configs around or just ask stackoverflow I think you're not going to have a good time. Emacs for me was the first complex thing where I basically could have turned the internet off and just look at it myself.
I honestly credit Emacs with no less than curing me of a weird learned helplessness I got from my awful education that threw tools at me where I had no hope of understanding what they do.
I find that people who take a slower long-term approach tend to be the ones that have a good experience. The moment someone really "needs" to get something done with emacs is usually when they shelve it for something more intuitive or more powerful out of the box.
I just looked at it as something to have fun with honestly. When I got stuck with something I just put it down for another time and I kept in mind that it's going to take a long time. And because I intentionally avoided copying things I didn't understand there honestly weren't that many moments of being super clueless. Also reminding myself that it was basically twice as old as I was at the time helped because you just can't expect to grok it immediately.
(also power is useless if you can't wield it and I would argue given the learning curve of emacs that very few people if any wield anything close to its full power out of the box)
What makes it worth it for me is that
(a) Once configured properly, I have a uniform interface to files, regardless of what sort of files they are. This save me time and mental effort.
(b) Emacs is extremely hackable in ways you won't understand for the first year or two, at least. If there's something about its behaviour you don't like, you can run a couple of commands and be taken to the relevant parts of the editor (Lisp) source code. Then you can replace that code (or better, write new code that hooks into it dynamically) with whatever you would like instead.
The latter sounds like a nutty thing to desire, and it's very hard to appreciate it without having used it for a while.
(c) Emacs won't disappear after a few years (where "few" can mean decades if your career lasts that long - mine ran from 1967 to 2011 and I still use emacs daily) the way virtually every (or maybe every) "more intuitive" editor/environment will, given time. Your investment in learning it will really pay off.
Adoption rates of intuitive IDEA and Visual Studio, while not quite as old, have long pushed Emacs into niche territory. Emacs hasn't disappeared only in the sense any venerable UNIX utility hasn't.
"hasn't disappeared only in the sense any venerable UNIX utility hasn't"? "Only" doing a lot of work here! That's the most reassuring "only" I've read all day. I bet you a pound people will still be using Emacs in 2050.
Though all of that, I have used GNU Emacs, definitely an unconventional choice for Java development. I've occasionally tried the leading IDE, and while it's sometimes been helpful to ramp up on new projects with tools shared with other teammates, the productivity of a comfortable and customized Emacs environment has always drawn me back.
In 10 years, IDEA and VS may or may not be still widespread, but Emacs will definitely still have its niche.
Not to say that you should use Emacs instead of VS Code or anything else. Just that Emacs not disappearing means that your investment to learn it and set it up is more likely to keep yielding returns.
If existence is tantamount to corporate sponsorship, then GNU Emacs never existed. It'd take one or two graybeards with too much free time to sustain Atom. Just look at the current Emacs maintainers.
What do you mean by this? The emacs-devel list looks like a smart and generally well run project.
Perhaps. Does Atom have said graybeards? The motivated ones are hard to come by.
Two things which have contributed to my success: - The System Crafters YT channel. David has an amazing tutorial series where you build a config file from scratch. I followed along, and it both gave me a very functional Emacs config and taught me enough about Emacs to get out of trouble when I goof up: https://www.youtube.com/c/SystemCrafters - Not being afraid to go back to other editors/IDEs for a while, or even rely on other editors for some tasks. Learning Emacs is tough enough as it is, but when you're a working programmer and you're on the clock for getting something done, it's extra tough to tolerate the slowdown from all those 1000 little things that you haven't gotten comfortable with, or features which were present in your previous editor but aren't yet present in your Emacs config. In past lives I would have just rage-quit and given up on Emacs, but I tried to be gentle with myself this time and take breaks from Emacs when I need to, and it has been a winning strategy.
Never going back.
Once you have the keybindings in your brain, you will struggle with other editors. And the main advantage of Emacs for me is: I can edit really everything editable, and will find a nice environment. Most IDEs are limited one or few languages and outside of that, you are out of luck.
Having support for everything I edit and seamlessly between languages, many of which don't have "IDEs", ist hard to beat. I avoid Java these days, but take SLIME as a really great Common Lisp IDE, or from quite early on good Go support, and many more. And in all of the modes, C-c C-c will either compile the file or evaluate the function under the cursor. And I can edit all those languages not only with the same tool, but within the same session. In one Emacs, you can edit them all side-by-side.
I realize this is sort of like complaining about trivial code style preferences in a code review, rather than looking at what the code at hand is actually doing.
But Emacs just feels too... Old-school. Not in a cool way, but rather in a boring way.
I wish I "figured out" Emacs though.
I wonder if there is an opportunity for a modern, open-source, extendable, programmable text editing environment that uses CUA, Tabs instead of Buffers, and Javascript instead of LISP. Or if it's already too late because VS Code has already taken over the modern, open-source, and extendable parts already?
Edit: incidentally I think there’s a GNU Emacs fork that has some kind of JavaScript binding.
Funnily, I also work for a company where many people use Emacs (it was the only editor with good support for our tools for a long time – you can even order lunch from it – new hires were encouraged to use it, even non-software engineers when they needed to interact with the Linux side of things) which I think is pretty uncommon. There was definitely a time 10 years or so ago when vim seemed to have massive popularity online and everything else seemed to fly under the radar.
The popularity of vim frankly surprises me. Vim is 1970s to its bones, with nothing to suggest that it’d be picked up so widely.
(Saying this as a vim user of about two decades who has only been able to switch to Emacs thanks to evil mode.)
What brought me to it was Orgmode. I'd TRIED to use emacs before, 20 years ago, in my LAMP-stack days, but it was too easy to use more modern editors (for me, on a Mac, this was a mix of BBEdit and TextMate). The learning curve in emacs is intense.
Then years later, I got sick of the existing to-do software I was using. I changed jobs into a MUCH busier one, and the David Allen / GTD tools like Omnifocus just weren't working for me. I realized what I really really needed was the ability to take notes and intersperse to-do items in the text, and then have some tool that would look at my notes files and show me a dynamic view of the to-dos coming up (or overdue).
I mentioned this desire to a friend, and he said, in so many words, "boy do I have some good news for you, because that exactly describes orgmode."
In adopting orgmode, I find myself using emacs for other tasks, too, including whatever generic coding I end up doing now where it's reasonable to do so (ie, not vba and not interacting with MS SQL Server).
I had a rather nice SQL workflow in Emacs using an inferior SBCL with SLIME and cl-sql. At the time org-babel either didn’t exist or I didn’t know about it, and it was a really nice pseudo-literate environment to explore data.
SSMS is really, really useful. I cannot imagine an emacs approach would equal it, and if I have to have it around for OTHER tasks, using it for writing SQL is much, much easier than using something else.
The thing about Emacs is that it’s rarely the best tool for the job, including when that job is text editing. Where it shines is the ability to integrate and automate entire workflows. There are some real advantages to having your email, IDE, notes, terminals, and whatever else all integrated and seamlessly working together, even if it’s not the very best at each of those things.
As for the "everything emacs" thing, I'll say this: there is near total overlap between the set of people who do this and the set of people for whom tinkering with emacs is a rewarding hobby. If you just want to get work done, it's rarely the most effective path.
emacs for me is a means to an end: OrgMode. Absent org, I'd never have started using it. Once something else comes along that works as well as org and has a better mobile story, I might move on (Obsidian is interesting...).
I am, generally speaking, not a fan of monolithic solutions because it leads to sunk-cost-fallacy thinking and difficulty in migrating to new tools that might serve a purpose better.
After leaving programming entirely for a decade I can back to Emacs recently when I discovered pdf-tools and Org mode. Took only a bit of time to get reacclimatize this time. It’s all muscle memory. You just have to force yourself to do real work with it so you exercise the muscles.
The main issue for most people is that the standard install is pretty barebones in terms of ergonomic enhancements. Sure, the default Emacs install has _way_ more functionality than a VSCode install full of plugins. But it won't have simple things like fuzzy search for commands, buffers, etc.
I'd suggest looking into Spacemacs, or Doom Emacs if you are comfortable with VI. Those will have sane defaults and cut down on the amount of script snippets you have to add considerably.
Not favorably. Perhaps there's a magic combination of SSH and Tramp settings that can make the experience lag free, but I can't find it. VSCode's remote editing was setup-free and close to seamless when I tried it.
Tramp has support for many, many more remote protocols though.
It's probably been a decade since I used TRAMP, so maybe it's gotten worse or more likely people are expecting more of it.
There are also non–trivial bugs that cause headaches when typing out a TRAMP path to open a file, possibly caused by interactions with the various autocomplete packages people may or may not be using. For example, if you want to edit a file on a different machine via ssh but also change to root using sudo, you can enter a multi–hop path like `/ssh:othermachine|sudo:root@othermachine:/etc/whatever.conf` which is very, very useful. However, if you mistype and put a colon instead of a pipe, or have to backspace to edit something, then it will usually just break. Some types of connection errors can cause it to break as you type, causing it to fail to accept further input. All you can really do is hit C-g and try again.
That said, I use TRAMP every day of the week and it is amazingly useful. I could do my job without it, but it would suck.
I did not move from Code -- but I had an interesting interaction with my son recently, who is a Code user. I was showing him my org-agenda set up. He noted that it was weird to organize your life in the app you use to edit code. I do see his point!
Only if you think of it as an "app", which often carries a connotation of singular or narrowly constrained purpose. I open an app to get directions, I open an app to see my email, I open an app to send a message, I open an app to check my grocery list.
Emacs isn't an app, it's a system. Is it also weird that we use the same systems (Linux, Windows, macOS) to code and organize our lives and to host a variety of limited purpose apps?
But I do like your son's is a good perspective to think upon -- and all claims/questions deducing from it.
So when I programmed on Windows, I used an IDE -- typically Borland C++ or Microsoft Visual C++. When I wanted to program for Linux -- ???
There was no equivalent. I had to use my old-school Unix skills and write the code in a text editor, then use the compiler and make to put it all together in an executable. I started with -- pico, was it? But a friend told me Emacs was really great and the editor to use if you're a programmer. I'd heard the name Emacs from Micro Emacs on the Amiga, but apparently this was big boy Emacs.
It came with Slackware, so I fired it up. And holy crap. It seemed unspeakably powerful and live-codable. I would only get a sense for its true power over years of working with it -- to code, to write HTML pages and stories. It had a web browser, email client, and IRC client. It had games! All written in Emacs Lisp. Blew my damn mind at the time.
The skill ceiling for Emacs is tremendously high, it's not something you will pick up easily. But for me it was well worth learning. I won't call myself proficient in it, but I can do things with it and shape it to my exact needs in ways Visual Studio (Code) can't match, live, as I use it. To me it's worth its weight in gold.
For me the key was starting small. Initially I just used emacs for org-mode, then for magit, and then finally for programming. Now I have a hard time imagining using something else.
The thing is you won't feel any benefit of using Vim/Emacs over Visual Studio Code unless you put LOT OF TIME configuring it. I didn't use any of the configuration framework like Spacemacs, and built my config over the years (adapted bunch of stuff from Centaur Emacs as it was super simple to copy things from there). But once you get it, it almost feels like an extension of you which I never feel on the other IDEs. And now with LSP clients on Emacs, bunch of basic things for programmning almost work out of box, it has never been easier.
I've a feeling you can probably get there by configuring Visual Studio Code too, but it does feel as inviting to be hacked as say Emacs.
I don't think this is true. What is true is that by putting a lot of time into fine tuning your own Emacs you learn to master Emacs.
But then, once you master it, you can use it almost vanilla, and still be as efficient and productive.
I've spent years customizing my init.el file and even wrote minor and major modes and a few custom packages. At some point my Emacs was loading almost a thousand lines of personal elisp code.
Then I decided to try to slim down my config and started fresh. I used M-x customize for a few things (I did everything manually before) and have a small — maybe 20 lines? — init.el file and that's it.
It still rocks and I'm still very proficient with it.
Now I'm trying to go further and switching to Kate. It's a fun ride but a bit hard at time and has lead be to become a small contributor to the project to improve both Kate and the underlying KTextEditor :). I'm kind of rediscovering the fun I had configuring my Emacs 15 years back ^^.
I love all those fancy modes and they are all part of my workflow -- ivy, ivy-ripgrep , magit, lsp (for autocompletion, code navigation), diff-highlight, perspective, swiper, flycheck, projectile etc etc. I like to figure out keybindings, that work for me over long term. You also don't want to make it feel bloated, overwhelming, and slow meanwhile. Without all these, it is just good for doing quick edits.
In the end I want to be productive with the codebases I work with. There was a time, pre-LSP and native-comp when Emacs was getting super slow, and I was ready to jump ship to VSCode, plainly because I wasn't feeling productive/efficient with Emacs anymore.
Edit: to give further context. When you install LSP, it may or may not be as per your taste. For me, I don't like bunch of UI stuff it adds like breadcrumbs, doc popups, sidebars. So you'd spend sometime finding the right config to disable. Now multiply this with bunch of other packages you like, figuring out right set of keybindings that are intuitive and easy, it all takes a bit of time IMO.
Yes, I use them as synonymous. My point was that spending time configuring is what makes you learn to master Emacs, but once this is done, your configuration can be quite minimalistic and you can still be very efficient.
Minimalistic configuration does not mean no package, it means a few selected packages that require a single or two lines each to be loaded, rather than full customization and something custom implementation of everything you need ^^.
(1) That time spent to master Emacs is much higher than say traditional IDEs. I get what you are saying. I hardly edit my Emacs config anymore, except once in a while.
(2) I think I disagree about loading a package with just couple of lines each. Some packages work well that way. Simple packages, which most of them would be work fairly well that way. But soon as you start using some non-trivial packages, say company, projectile, magic, lsp you may or may not be ok with the defaults.
I'm not doing anything fancy particularly like making my own modes, except making Emacs behave certain way. e.g. I see I've ~80 lines configuring Shackle which decides where certain popup windows Emacs show up, because if I don't have that, it just puts them wherever sometimes. I can live without this change, but it is really nice to control that.
Then tried Emacs while learning Clojure, and after a few to and fro, stuck with it.
This was before Visual Studio Code (or Atom) became a thing, though.
It’s a life time tool that grows with you.
I started using emacs almost 3 years ago for org mode; a few months later I started programming in Common Lisp. Emacs works very well for those 2 use cases, and I feel like I've adapted well-enough. I still use Visual Studio for C#, and everything else is either vim or vim key-bindings.
Neither antecedent (vscode dies) nor consequent (emacs survives) is at all assured.
VSCode's development is so totally dominated by one company that it's hard to imagine it continuing to go strong if they decided to discontinue it (Cf. the fate of Atom).
So maybe there's an exception for tools with Visual in the name.
And all of Office.
It has a proper GTK interface and even runs natively on Wayland today.
The GTK GUI interface isn't just a niche fork or addon that nobody uses, it's really the primary interface for Emacs and how most people probably use it.
Let me tell you, X-windows and fvwm2 was a real eye opener though. Up to that point I thought fiddling with RedEdit was UI customization.
Im just so comfortable in a JetBrains IDE.
I'd find a spot in your workflow where emacs works better. Learning the basic commands takes time.
I'm sure people are out there who just use stock emacs, but I'm not sure why you would do so instead of using something simple like nano.
But I am just so utterly addicted to vim's undo/redo that I always feel naked without it at my fingertips!
And yes, emacs is definitely a universe unto its own. The point is that as a standard command line utility, the option to use it as a bare bones text editor is always readily available to end users, without need to do very much digging into things like settings/hamburger menus. I'm sure there are many emacs gurus "at the ready" in order to answer any conceivable unanswered question about emacs posted to stackoverflow.
Maybe it has become better, but for a while I looked into it as it was popular for Go editing. Unfortunately, there is way to much predetermined flow built in, so Emacs makes it the way better Go editor for me. Back then, there was even no key binding for compiling the current file.
And as I said, the language coverage is much worse than Emacs, as it is its hackability.
It's sort of a palette cleanser. "Ehhh, I don't feel like working what I'm supposed to be working on, I think there's this urgent emacs feature I should figure out..."