I think the first entry should include Eugene Cicarelli’s TECO init file which was the base of the others.
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.
Agreed. Does anyone know if there are sources retained anywhere for any of that stuff?
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 used the TECO init file version, it was on Multics. at that stage, i actually preferred "command line" TECO to visual TECO, keeping the abstract visualization in my head led to fluid authoring of edit commands, where looking at the screen with the cursor caret it was too easy to be distracted by material away from the point.
Emacs first public release is as old as I am. It seems that development on GNU Emacs is regaining momentum. I'm glad to be using an editor that's probably going to be around for the rest of my life time.
GNU Emacs development does indeed seem to have picked up the pace in the last 5-10 years. And the package archives and development community outside of people working on the core editor seems super vibrant. See, eg, magit, helm/ivy/vertico/…, spacemacs/doom, paredit, eglot, …
My people to follow are Daniel Mendler (github.com/minad; author of vertico, consult, marginalia, corfu, tempel…) and Protesilaos Stavrou (modus-themes, denote) but that's in part due to the fact that the development of these packages specifically impacts my work directly. There is a ton of other stuff happening in other packages. Some off the top of my head are org-roam, the magit ecosystem, lsp-related stuff. Nicolas P. Rougier has some insanely beautiful Emacs packages as well.
There are some interesting interactions between emacs and the rest of technical computing that might be interesting additions here, or at least footnotes. For example, me recollection of the first version of Linux that was worth running instead of 386BSD was 0.12... not as-posted, but with John Kohl's patches to make the select() syscall work well enough that you could actually use emacs... I wasn't the only one who saw that as a benchmark for "Oh, huh, this linux thing might actually be worth a look, if it runs emacs" (Note that it didn't have TCP yet :-)
It's got some of the commercial emacsen, but I don't see CCA Emacs (ran on VAX BSD, at MIT in 1984-1985 at least; notable for things like "running a child csh to do file globbing" which was almost clever... until you didn't save for an hour and the csh autologout fired, and you discovered you could no longer save anything either. Never got bit by it, just remember being unable to help people with it...)
No reason to think it shared code with anything else in the tree, of course.
Has anyone here 'adapted' to Emacs after starting out with Visual Studio / Code / etc? I have tried multiple times over the years to give it a shot but it hasn't stuck.
Yes. I started programming in ~ca 2010 when I went to uni and we mostly programmed in Java with Netbeans, so using Emacs wasn't exactly natural for me. The worst thing is the keybindings which don't conform remotely to anything modern.
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.
Interesting perspective. What were you doing during the initial semi-helpless "why-does-this-hurt-so-much" phase of your emacs journey?
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.
>What were you doing during the initial semi-helpless "why-does-this-hurt-so-much" phase of your emacs journey?
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)
I have, but it took a very long time. For the most common operations, you can get Emacs to be as convenient as whatever you're coming from, but it takes quite a bit of work and learning if you're new to it. When I transitioned, LSP wasn't a thing either so it had to be configured fresh for every language, pretty much.
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.
Agree wholeheartedly with your (a) and (b), and would add:
(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.
Emacs won't disappear... the way every "more intuitive" editor will
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.
Is this supposed to be some kind of ding? Because it is (if I may be so bold) not a very good one. Like, look at dd! We're still stuck with that stupid shit after nearly 50 years. It doesn't even have POSIX-style command line arguments! 50 years.
"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.
When I started doing Java, everyone else was using JBuilder. Then Eclipse came along, and JBuilder died. Next, IDEA showed up, and Eclipse started to whither. Don't get me wrong, IDEA is great but IDEs do come and go, and are subject to the fortunes of the company that pushes development.
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.
Perhaps, but Atom has already disappeared, and VS Code might, too.
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.
I have indeed! This is my first year of using Emacs. Previously I was using VS Code, and before that Atom, and before that Sublime.
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.
I have. I had used various IDEs, from Turbo Pascal over Borland C++ and Visuaol Basic, the last being jBuilder. When Borland refused to give me an upgrade deal to the next version after I had bought jBuilder 1.0, I had enough anger to really dig into emacs and to learn to use it and the back then really great JDE package for Java development.
Since then I have mostly stuck to Emacs for my coding. Sometimes I still would use an IDE, for Java coding you really can't avoid intelliJ :), but most of the time it is just Emacs.
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 think people who stick with it tend to be people who see it as a hobby. If you're just looking to get stuff done VS Code or JetBrains will get you up and running way faster than Emacs, with similar productivity. I stick with Emacs because it's so configurable it can be exactly the way I want it, which I haven't found in other editors.
Another perspective: those who stick with it view their tools as a long term investment. I have noticed that those who drift from editor to editor tend to use a subset of their features for a subset of their work. Only a handful will become proficient in its use and use it for a broad range of applications.
In a professional context I'm known for telling people "we don't care what editor you use, but it's where you're going to spend most of your working career, so there's a lot of payoff to picking one and obsessing over it." (Of course, I also recommend people learn to touch type...)
Sure Emacs is endlessly configurable. But it is too clunky for my taste.
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.
Growing up with Windows GUI, I too found many concepts in Emacs are just too different and "old-school".
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?
VS code is corporate embrace and extend open source. Note how they intentionally cripple the truly free builds. That said, VS Code has done great good too. The LSP is a wonderful step forward for all editors.
Edit: incidentally I think there’s a GNU Emacs fork that has some kind of JavaScript binding.
I used to use visual studio and I think I maybe also learned some very basic vim (arrow keys, i, dd, p, :wq) to do some remote sysadmin type things. I wanted to learn Common Lisp which, at the time, meant having to learn Emacs too. And then I was more interested in things outside of windows and Emacs stuck. (Also the calculator in it is amazing).
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.
Yeah, I came to it late -- actually, I came to it after my jobs stopped being "sling code all day."
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.
It is an absolute truism that, if someone suggests that doing X isn't great in emacs, someone will come along and disagree. ;)
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.
Well it suited my purposes very well, which was fetching data from MySQL and then doing transformations that were cumbersome in SQL.
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.
If that's your whole use case, yeah, sure. I routinely need to do things like backup and restore, or adjust DB settings, or easily copy data out of SQL and into Excel for tasks, and SSMS is just really, really good at all 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.
I started with visual studio in the late 1990s. Didn’t try Emacs until 2005 when I started using SLIME for Common Lisp. Committed myself to doing some projects in Common Lisp, and insofar as SLIME is head and shoulders better than anything else for that, it forced me to learn the environment.
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.
I 'adapted' before VSCode was a thing (we had Sublime, Textmate, etc).
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.
I also bounced off multiple times but have now been happily using it for 2 years. I really reccomend trying Doom Emacs and learning the default VIM modal editing. Doom comes with sane defaults and very simple configuration presets for every language out of the box. Learning modal editing pays off quickly.
Yes, it is my second year running with Emacs after ditching VSCode. While I miss the remote editing capability of VSCode, working on a shared HPC cluster made me finally use Emacs. Nowadays, I have shifted most of my workflows in Emacs, especially using Org mode, and I believe it should stick for the next several years.
Not great, but I think it is an acquired taste. TRAMP makes it _feel_ as if you are working locally, with some caveats. I like the fact that I can use dired to quickly navigate my projects on the cluster, open a vterm session and run my scripts, open my python files and save which automatically syncs them in the remote; magit works seamlessly (with a slight lag). What I wish is for better LSP support (lsp-mode/Eglot) for remote development - its kind of a miss for me. lsp-mode straight up does not work, and Eglot keeps me waiting until it can connect, leading to decreased editing experience. I have kind of given up on LSP for remote, nowadays I just use dumb-jump for quick navigation and local editing for more serious development.
> I'm not sure how that compares to VSCode's capability.
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.
I suspect good ssh support is just so much more necessary for vscode than it was for Emacs when tramp was developed. I do think tramp was also full of generality towards things that are very uncommon these days (various different protocols, ssh workarounds, baud rates, …)
Lag free? What are you doing where lag is problematic? Sure it takes a couple hundred milliseconds longer to open a file or save a file but the actual editing is lag free, and that's what matters.
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.
ControlMaster auto. Most distributions don‘t ship with it turned on because it needs somewhere to store the socket files, and nobody has pushed for it to be the default. And then you still have to know to set up key–based authentication so that it doesn’t ask for a password every time it needs to reconnect.
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.
To fail to answer your question, I've been a vim (then neovim) user for twenty years or so, and moved to emacs in the last couple of years.(initially because of a desire to have a searchable/configurable email client, then I stayed because of org-mode.).
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!
> 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?
Mhm, evil and org-mode brought me to emacs. I generate documentation, presentations, embed little scripts to transform org-tables, and use ledger-mode. I don’t even use it for coding projects anymore.
Kind of, almost by force. I was trying out Linux back in 1995, coming from Windows. Going from Windows to Linux back then was a bit like switching from a brand new economy sedan to one of those cars built out of scrap by Immortan Joe and his War Boys. Everything was so janky and cobbled together, but extremely powerful, it seemed, compared to what you left behind. It would be close to another year before some German Amigaheads put together the first Linux desktop worth taking seriously -- KDE.
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.
Yes, I switched over after using vim for a few years, then JetBrains, then VSCode. Being already familiar with vim keybindings, doom emacs provided a nice on-ramp, much simpler than spacemacs IMO, which I tried a year or two earlier.
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.
I learned programming in various IDEs. Visual C++ 6, Code::Blocks etc ... Moved to Vim somehow when learning Linux, and eventually Emacs because I was programming a lot in Racket and it was just nicer there. This all predates Visual Studio Code.
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 ^^.
Isn't fine tuning ~= spending time configuring? How much configuration and fine tuning you need is subjective. I personally don't like using it vanilla, particularly if I'm working on a big codebase.
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 ^^.
Yes, I think I had two things in mind when I said:
(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.
I have to disagree with this a bit. I try to keep my emacs file pretty minimal, like 20 lines of customizations like fonts and a few flags, the rest mostly just requiring additional packages and a very few custom functions.
Yeah I adopted it after exploring other languages after learning to program in Turbo Pascal 5. Bit later I started using it for mail and news (Gnus) and other things.
Using different tools for different types of work / programming is an option.
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.
I tried using spacemacs at first, but it was just too slow. After a few days, I ended up going with vanilla keybindings. Muscle memory eventually caught up.
I only tried once about 15 years ago (from GUI IDEs/editors) and it didn't appeal to me. Now with GitHub Copilot and the like I think the use of command-line editors will further diminish for generalized programming tasks, although they will always have a place in system administration.
Realistically, there’s not much emacs can’t do, including integrating with copilot[1]. I think it’s niche isn’t system administration, but people who have the time, energy, and interest to really invest in their tools. Its configurability is second to none, and it’s not going anywhere. Emacs will still be around long after vscode is forgotten, and it’s nice to know that the time I spend learning my editor won’t go to waste when some big corp decides to up and leave, or the programming zeitgeist moves on to the shiny new thing.
Nothing lasts forever, but Emacs has enough momentum behind it that I'd be shocked if it dies within our lifetime (assuming there's no general collapse of technological civilization, of course). Even if the FSF were to become defunct, enough people care about Emacs and are involved with it that somebody will continue developing it.
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).
Emacs is not a command line editor (but it can run in a terminal if needed).
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.
I first encountered Emacs on workstation UNIX (DEC, HPUX, SunOS, etc) at the university. Prior to that I’d been using a Mac so it was definitely somewhat alien. But honestly it wasn’t that difficult. Many power users like to disable the menu, but I learned a lot from using it. That was back when the Mac “power user” culture was, essentially, use the menus to learn the keybinds. So it wasn’t that alien to me.
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.
I like to disable the menu on my Emacs but I do NOT recommend that neophytes do so. That's what it's there for -- to help you issue commands with a guide to what's available.
Isn't the reason why people gravitate to standard utilities such as emacs and vim largely because they simply can't cope with all of the shiny graphical bloat while they are trying to wrack their brains coming up with some new kind of thing or another? I use vim, and I've spent countless hours of my life trying to write a new kind of vim with it. (See: https://lotw.site/shell, then enter "import fs && vim" at the prompt.)
Modern GNU Emacs isn't really comparable to vim in this respect, since people use it with tons of bells and whistles. Emacs is probably better described as a "framework for building custom IDEs" than as a "text editor". Yes, vim plugins exist but my impression is that using stock vim with no plugins and only a bit of configuration is much more mainstream than doing a similar thing with emacs.
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.
I've actually managed to make nano look even simpler, by getting rid of all the interface elements except for a vim-like cursor position indicator in the bottom right. The notes to do it are here: https://drive.google.com/file/d/1BJeBc0mynxR8lrL4u20q4oBc8vQ.... It wouldn't take too much effort do make it a .diff to auto patch the source code. My main issue with nano is its liberal usage of eye-blinding reverse video.
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.
I don't mind a good IDE. But that only "works" well, as long as you are working in one single language, day in and out. There have been such times in my life and I was happy with the corresponding IDE (unless it itself was just crap :p).
But if you are not so focussed, jumping between languages quicker, or just if you don't have a good IDE at hand for your language, Emacs is your friend :).
Sorry, first you should consider your language. "Holds no water" is way to strong, especially as it is absolutely wrong. VSCode is nice but a far cry from the abilities of Emacs. And while it does somewhat support a lot of languages, setting it up for a new language is way more work implementing a complex protocol compared to Emacs.
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.
To set the tone of my reply: I’m an every-day-all-day Emacs user. I greatly enjoy configuring my Emacs. Your point about “hackability” is spot on. That being said, I think the language “holds no water” is reasonable here. It sounds like you haven’t used VSCode in a while. (As a lightweight IDE) it has completely seamless integration with every popular language.
I'm amused by the recursive acronyms EINE and ZWEI. While I doubt seriously they're the oldest recursive acronyms, they're the oldest I've seen (and clever, to boot.)
I'm curious whether you are still an emacs user. I'm a relative emacs noob, having started using it around the turn of the century, and I can't imagine how much time I would have wasted learning the editor of the moment over and over.
Otoh, how much time have you wasted customizing your editor? I know it's a lot for me! :-)
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..."
I started with zmacs in '87. it seemed so old and such an established part of the canon even then - I can hardly believe it was just a baby, and that I'm still using it as a daily driver 35 years later.
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.