Emacs' feature of being a platform for Lisp is really something that needs to be restated again and again.
You can do practically anything to text or other objects. If you can think of it, I'm pretty sure that Emacs can accomplish that for you. Any transform, file action, font changes, etc etc.
Example, this auto-saves a given file. In this case, whenever I archive an org-mode subtree, the archive file is auto-saved:
435 │ ;; The `save-some-buffers` function can run silently, and it also accepts a
436 │ ;; function argument to predicate whether a buffer is saved or not.
437 │ ;; This predicate simply says "save the buffer's file if it's the notes archive
438 │ ;; file"
439 │ (defun redacted/save-notes-archive-file ()
440 │ (interactive)
441 │ (save-some-buffers 'no-confirm (lambda ()
442 │ (equal buffer-file-name
443 │ (expand-file-name redacted/notes-archive-file)))))
444 │
445 │ ;; Finally, the newly-defined function can advise the archive function. So,
446 │ ;; after a subtree in org is archived, the archive file will be automatically saved.
447 │ (advice-add 'org-archive-subtree :after #'redacted/save-notes-archive-file)
Before I learned lisp, I remember seeing this sentiment expressed a lot and thinking people were underselling the difficulty and overselling the usefulness of "programming your text editor" as opposed to just configuring it via standard options.
After I learned enough Common Lisp to build a few small projects, I realized how powerful it is to write small, bespoke functions for odd text editing jobs. You can write and save functions that do something very specific but powerful to any project you're working on, regardless of the language or tooling used, because everything uses text. I'm so glad I learned it.
I really wish emacs had evolved a model for dealing with simple vector graphics. I know part of that falls on the market for not choosing a common model..but
I find it doesn't really matter what I'm interested in (computer-wise)---Emacs has me covered. It saves a huge amount of time to not have to relearn a new IDE each time I need to switch programming language. There is always more about Emacs to explore, but it is well invested time, as I know that Emacs is going to be around most likely for the rest of my life-time. The killer features for me are:
+ Org-mode
+ SLIME (Common Lisp IDE)
+ A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable).
+ Really smooth integration of LaTeX, Dot and Tikz.
+ Rock, rock, rock solid no matter what I through at it.
Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.
> Rock, rock, rock solid no matter what I through at it.
The main reason why I don't like Emacs is that it feels very fragile to me. The first time I tried to use Emacs seriously - granted, that was many years ago and probably things have improved - I wanted to change the font because it was using an old X11 pixel font. So I went to the settings, and accidentially deleted the combobox that allows you to choose the font. I tried to configure it with the command line or REPL or what it is called and managed to mess it up even further. Later, as I got more familiar, I regularly managed to get it into a state that required restarting. It seems in Emacs, everything is a mode and everything is an editor, and there is no separation between content and UI (except for things like the menu bar, which uses a different toolkit and is bolted on). I've learned to appriciate less configurable editors because there is less to screw up, and you have the same good experience on any PC without your special config.
It seems a bit disingenuous to say "emacs can do everything" citing org, slime, and auctex, which are probably the three highest-quality extensions out there (maybe throw in magit too). In my experience this level of polish is not consistent, e.g. python or java support is much less robust. Emacs is indeed great for many things, but not everything.
I spend most of my time in Emacs (Clojure/Script), but if I'm writing JavaScript then VS Code works so much better. Maybe I haven't spent enough time tweaking Emacs for JS?
> Rock, rock, rock solid no matter what I through at it.
That's actually not how I would describe Emacs.
Not for Common Lisp either, Sly (and before that Slime) always had some glitches where I had to restart them or Emacs.
> Rock, rock, rock solid no matter what I through at it.
This is definitely not my experience. I regularly see emacs lock up indefinitely when asked to handle large buffers, especially when also using TRAMP. Even when it doesn't lock up indefinitely, it can easily stall for minutes(!) when doing something like moving point to the end of a large minified JS file (C-E).
There are many reasons to love Emacs, and I use it as my main development OS almost, but stability and performance are not among those reasons.
Note: mostly used it in console mode on Linux (Ubuntu WSL 2).
> I’ve also seen plenty of new editors rise and fall in the past 20 years - Komodo, TextMate, Sublime Text, Atom, etc. Emacs and vim are the only editors that stood the test of time
This is the main reason I keep using Emacs for my everyday use. I never thought it was simply the best editor you could imagine. But it’s an editor I could always rely on.
There have been so many editors and IDEs in the past with their shiny features, great UIs and everybody screaming of excitement — until they were replaced by the next new shiny editor after a couple of years.
VSCode is surely a nice editor. (Although I don’t think its pixel dust UI is particularly great. And don’t get me started on its memory consumption.) Microsoft’s LSP, however, is a great idea. Emacs absorbed this feature already and will make it available even long after everybody stopped using VSCode within a couple of years.
Editors fall out of fashion. People die. Emacs remains Emacs.
VS code has been my standby for years but the number of times it wants to restart for updates drives me up a wall, and what do I get for allowing constant updates? A giant modal popup [0] asking if I trust a folder enough to let VSC run automated scripts. Yes it’s configurable but i value default setups so I can more easily wipe my OS without reconfiguring everything.
I watched a video on JetBrains [1] and the keyboard shortcuts and navigation look genuinely well thought out, so I’ll be giving that a try (with a vim emulation plugin, naturally)
> This is the main reason I keep using Emacs for my everyday use.
This might be my number two reason. I learned Emacs in 2000. Meanwhile, I've not had to learn, over and over again, all those other editors and IDE's. To be sure, I've honed my Emacs skills, installed and learned new tools in it (hello flycheck, elpy, SLIME, org-mode, TRAMP, CEDET), and just generally get on with whatever I'm working on ATM.
Not all old, unfashionable editors are dead, though. See WordStar, for example. And people definitely still use all of the editors in your "fallen" list to get work done.
I use a mix of editors on a day-to-day basis because they each solve a particular problem in a way I like. I imagine everyone else has a similar thought process. If you like the way it works, then it's the editor for you.
As a devoted Emacs user I think the following is really the most important part of the article:
> Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material. The out-of-the-box experience is kind of basic and somewhat weird, but I don’t think that anyone should be using Emacs like this. You take this simple foundation, you shape and mold it to your taste and preferences and you end up with the best possible editor for you and you alone. That’s the reason why you should consider using Emacs. … For me, personally, the ability to extend Emacs easily with Emacs Lisp remains its number one advantage over vim. There’s also the fact that you can re-create much of the vim experience with Emacs, but you’ll be hard pressed to re-create the Emacs experience in vim.
For me, this is really the key attraction of Emacs. It’s not an editor; it’s a library for me to build my own ideal editor. And, in the long term, there are very few editors which can compete with this.
I'm currently in the process of moving from vim to emacs, and I've noticed that the only things from vim I really need are the modal editing and the basic keybindings - everything else, like the plugins I've come to love, are more or less interchangable, and from what I've seen, more than plentiful in emacs-land. I think comparing emacs to vim as "editors" creates a false dichotomy, one that has kept me from trying emacs for too long.
For me, this is a bit similar to how Linux is not really an OS, it's a set of tools with which you can build your own ideal OS. This means everyone who likes "Linux" likes a different configuration.
What made me switch to VS Code (after using Emacs for 30+ years) was that I got tired of just how much of an easter egg hunt Emacs is for me now.
Setting up Emacs reasonably for Go development just isn't even close to being straightforward. And with Go, go tooling and Emacs continually being changed, any setup that works will eventually stop working and you have to try to figure out how to rewrite your configuration. This happens often enough that even someone like me, who really, really didn't want to ditch emacs, eventually may do so.
I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
The goalposts moved. They are farther afield. Expectations of what an environment has to offer have gone up. If a decent developer experience isn't an understood priority, then Emacs isn't going to be very attractive for new developers. And it may have problems both attracting new users and developers and retaining new developers.
(That being said: VS Code is apparently going through a rough patch where things have gotten really buggy if you use it for Go development. So it isn't like VS Code is a magic bullet)
Vim has more users than Emacs and lately neovim gained a lot of traction; they managed to coordinate the community on a direction, ask for money, fund a new generation of programmers to learn the codebase and update it to be async and use a different script engine.
Emacs has had several efforts at replacing elisp or rewriting the core in rust or what have you... But they've never been able to budge the local maximum nor coordinate the community on the new direction. Actually, I believe guix is the new emacs because..
Neovim has succeeded in retiring vimscript for lua and from there a community is emerging around fennel (a powerful lisp that compiles to lua). This is the beginning of a very interesting answer to emacs which is growing fresh from old roots and there seems to be a lot of people eager to build tools with these tools.
Although I tend to think the brand value of vim and Emacs is worth a lot I'm starting to see a lot of new editor projects that look somewhat appealing but until the packaging and configuration management gets at least an order of magnitude easier I'm reluctant to spend time with these things.
Its worth remembering that Visual Studio also used to be regarded as really good right up until it... wasn't, and then with VS code is sort of was again. Except right now it kind of isn't.
The fate of VS code seems to be really closely tied to TypeScript at the moment. If it turns out that Types really are the way forward, then these will eventually be included in the JS core. What then for TypeScript? Who even decides?
The nice thing about Emacs is that it is firmly rooted in standards and consensus. It will never be the best editor for most people at any one moment in time, but it has been a _good_ editor for decades and will continue to be so for decades to come.
> I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
Emacs is really short on core developers, and core development is hampered by the de-facto requirement that no aspects of user experience should change by default for longtime users with no out-of-core customization.
That said, the improvements in Emacs 28 are tremendous. The biggest is the native compiler, which will AOT compile Emacs Lisp code to native code, so lots of things that used to be slow are now very fast. Native JSON parser (maybe was added in 27?) means that LSP support is very fast. Pure GTK frontend didn't make it into 28, but will probably make it for 29, and means that Emacs on Wayland doesn't use X11 anymore.
What I'd like to see is a "standard distribution": something not as opinionated as Spacemacs or Doom Emacs, but which will apply more modern defaults, and have something similar to the Spacemacs "layers" feature, where there's a standard, supported way to enable the needed packages for a language or common workflow.
Very different experience for me, working with Go using Emacs has been pretty smooth sailing from day one (which for me was around the Go 1.0 release).
go-mode with godef, goimports and oracle was great during the early years. I remember telling people how the simplicity and quality of tooling and the great Emacs support around them was one of the reasons I enjoyed working with Go.
The transition to module support was a bit of a pain but that was a question of updates to the tooling, not Emacs itself. And then LSP came along just around the right time to deal with that and everything else.
Other than Elisp itself and Common Lisp (SLIME) I'd say Go is my favorite language to work with using Emacs.
Edit, looking at the timeline Go 1.0 was March 2012 and it took a year before we had go-mode with godef support. I guess I managed until then, it was simpler times in the Go world.
This is unbelievable to me who has been emacs user for this long. What i have seen so far is people whos customize heavily and use as a way of life or people who don't like after trying for some time and move away to other editors. There is another category of people who use for a specific purpose regularly(like org mode users) without making any customization or learning elisp. But your case is special. What is your level of mastery in emacs and elisp?
I presently use VS code at work as well, but not because it so nice, but rather that I can setup it from scratch to the tolerable state within 20 minutes including extension installation time and it works very similar on Linux/Mac/Windows (I need to work on all platforms and cross-platform functionality is a must). Plus it works on huge source tree like Chromium with fast file opening and whole tree search with almost no setup (VS Code hits some default limits on amount og Git modules, but that can be adjusted).
I stopped using Emacs like 10 years ago after realising that if one needs over 1000 lines of init.el then I am not the target user of the editor. I tried to reduce that via using external packages, but that has not helped much.
And for hobby projects I am happy with Geany on Linux.
What makes Emacs unique to me doesn't have anything to do editing code. All the tools for doing that are incredibly similar, specially after LSP became a thing. Writing code in Emacs or VSC is practically the same for me, though I happen to prefer the former.
It's mainly about how powerful plaintext is and how Emacs and it's community acknowledged that. Org and org-roam are extensions of my brain by now, I've even installed Emacs in my smartphone because of that. Ledger-mode is the most ideal finance management I could conceive, and I've set-up Emacs (CUA-mode with just a ledger hydra) for two family members so they could use it too. I have absolutely no idea how I could make Ledger tolerable to non-technical people without Emacs. I also create beautiful presentations in a couple of minutes using org-reveal.
Besides, it's hack-ability certainly inspires inumerable beautiful creations. Some packages like Magit, Hydra, Helm and avy are just that, beautiful. When I don't feel like programming, I change some config and write programs as an excuse to test it, because Emacs is fun. It's no wonder people who act like understanding your editor is a chore have a bad experience, they're missing the point.
Very nice, after your original article I started using Emacs more and more on my Linux Systems (I dabbled with it before). And in 99% of the time I prefer Emacs.
On OpenBSD there is one nit, and googling only suggested 1 fix. I am a heavy RCS user, but Emacs RCS package fails on OpenBSD due to its Base RCS. The only fix I can find is to install GNU RCS and disable OpenBSD Base RCS. I tried to find and fix the Lisp package, but it is way beyond my skill level.
OpenBSD people seems unconcerned about correcting their RCS to work with Emacs (maybe a security thing). I believe the same seems to be the case Emacs RCS people, I think they would prefer the use of GNU RCS (understandable).
I would prefer to use OpenBSD Base RCS but I am caught between two projects. So on OpenBSD I stick with vim until I can find a workable solution.
> Beware - Emacs is highly addictive and it might easily consume years of your life!
I agree with that wholeheartedly. Don’t get me wrong—I love emacs and I’ll be the first to talk your ear off about it.
But it’s a hobby, and not necessarily worth the time investment compared with other editors, if you’re looking for something that “just works” and has all the modern features.
Now that you've gotten the ritual disclaimers out of the way, though, Emacs time investment pays off big time. Survivorship bias, sure, but you certainly don't need to go full Colonel Kurtz into the Emacs rabbit-hole like Bohzidar, before you can reap benefits- it really is a gift that keeps on giving.
I just spent a couple days getting my corporate e-mail to work in emacs(settled on gnus+offlineimap+notmuch).
I even got syntax highlighting for patches and wrote some lisp to link up notmuch search results to gnus- so I can search for an e-mail and find the whole thread easily.
Of course, I could have just started evolution and been done, but this stuff is fun!
Agreed. I find myself struggling to recommend it to newcomers - it is just so esoteric to anyone used to ctrl+C for copy. But I can't imagine life without it.
At my last job, I was forced to use PyCharm. Fine an IDE it probably is, I hated every second of it. Within 3 days I ditched it for Emacs.
I like that the author hit on the curious and fun aspect of emacs. Whenever people talk about IDEs and editors, there's so much focus on things like efficiency, practicality, and return on investment.
I don't use emacs because I did some cost-benefit analysis on my editor. I tried emacs and found that it's a whole lot of fun, which of course is why I got into programming in the first place - I found it, and still find it, fun.
If you view programming as a job in the same way something like being a tax account is a job, then learning emacs is probably not for you, you're better off with something like VS Code that asks very little of its users and gives you a nice working environment right out of the box.
Emacs is great if, as the author notes, you're an intellectually curious person who genuinely enjoys tinkering. If that's the case, you'll most likely have a lot of fun with emacs. It's very hard to describe how much fun it is to edit and modify your development environment in real time while you're working in that very same development environment.
Author is none other than @bbatsov, who created Rubocop, Cider, Emacs Projectile, etc. I have huge respect and his work/contribution in open source definitely lends credibility for his writing, even if you may not agree with some of his opinion. As a side note, I've always wanted to get into emacs, even though I'm ok as a vimmer/vscode user.
I’ve also seen plenty of new editors rise and fall in the past 20 years - Komodo, TextMate, Sublime Text, Atom, etc.
Two of those editors are Mac-only, and only one editor is open source. I suspect if Sublime had become open (and cross-platform), it would be significant "player" in the editor wars. Atom has mostly died on the vine, thanks to VS Code. That doesn't negate any of the author's points about Emacs, but, aside from VS Code (and, I guess, Atom), there have been few efforts to create a performant[0] cross-platform, IDE-like editor.
[0] Insert comments about VS Code's performance here.
That's a fair point, although I can think of examples in the IDE reals as well - e.g. in the world of Java Eclipse and NetBeans were popular (and open-source), but gradually IntelliJ IDEA dominated them for various reasons. I also remember all the Borland tools (super popular in the 90s) that have mostly disappeared by now. I definitely think that open-source projects are more likely to survive long-term, but it's not like they don't fail.
Btw, I think TextMate is open-source these days as well.
My take on some of these comments as someone who has used Emacs almost exclusively for my day job for around 4 years:
Emacs is not rock solid.
It's easy to bring Emacs to a standstill with something as simple as a long string. This is especially apparent outside Linux, e.g. on Mac OS (Windows is a whole other story). It's a fundamental flaw in the text editor, and I don't know if there is any solution on the horizon.
Text editing can also become noticeably slower once many of the must-have Emacs packages are in use.
At the same time, becoming somewhat proficient at Emacs and knowing a thing or two about Emacs Lisp has made me a better programmer, and certainly more productive in the use of my editor.
If Emacs can solve some of its performance issues, and perhaps make things like the Debug Adapter Protocol easier to set up, it will continue to be in a league of its own and an essential editor to many for the foreseeable future.
My experience with Emacs is bittersweet. On the one hand, org-mode in Emacs is extremely powerful. I use it to schedule TODO items, organize my thoughts, write notes, publish websites, and lots of other things. On the other hand, Emacs drives me crazy from time to time. It's slow, hard to maintain, the environment I set up is fragile, and most of all, it lacks a modern UI. Scrolling pixel by pixel is still impossible in Emacs.
Sometimes I do use VSCode as an alternative, but VSCode only has a rudimentary implementation of org-mode, and the so-called org-mode alternative - markdown - is not nearly as powerful as org-mode.
One of the things I've found as I grow older is that I spend less and less time customising my environment, and learn to enjoy the defaults. I've never managed to get a proper dotfiles setup, despite trying, so moving between machines -- especially when they're not my machines -- means reestablishing all the settings I want to keep.
I used to live inside Emacs -- not just for coding but for mail and news too. But nowadays I use Jetbrains IDEs for development and a reasonably clean vim for editing random files.
Every time I use a editor, I miss elisp freedom. Now other ones are programmable but a capable lisp in a dynamic env is still such a comfy spot to live in.
When I meet quite practical devs that are into PHP or Java, they always recommend IntelliJ. Can anyone of that crowd that also have a solid understanding of Emacs do a short comparison between the two?
I'd really appreciate it.
Currently, I've only mustered enough courage and time to understand enough of vim to not feel scared of it anymore (vimtutor was the silver bullet for me there, learning enough vim in an hour to feel fine with it).
I think it's as simple as: Emacs is like VS Code, IntelliJ is like Visual Studio.
JetBrains makes great IDEs, and you should use them if you're working on a large project that one of those IDEs is geared towards. It'd take a lot of work to get any other editor to have the same feature-set and organization of workspace.
Emacs is a general-purpose environment for writing, and you should use it if you want a specific flow for writing code, or anything else. You can setup plugins so that it's like a mini IDE for most of the languages you write in, and you can setup plugins to modify the organization of your workspace. You want tabs? Add them. You want a tree view of your current project folder? Add one. You want Vim-style editing? Enable it. Etc.
Right now it seems everyone is looking for a code editor that is extensible and fast - Emacs fits that bill better than VS Code (also Neovim might end up being even better!), but it's more difficult to get it right. That's why there are projects like Spacemacs and Doom Emacs to make adding/removing plugins easier, and also have a good setup out of the box.
I use both for almost 10 years, here are my experiences:
The main advantage of IntelliJ or any other IDE by JetBrains over Emacs, is that the out of box experience IDE provided, especially from a new programmer's perspective. All they need to do to click a button, check few checkbox, then IDE will resolve it for you and tell you what happened.
But to make Emacs do any complex behaviors, you usually have to write additional codes or configurations to glue different features together. Not to mention you need to read documents and debug it when there is an error. In JetBrains IDEs those are integrated already. A context-aware error detection and code inspection is available the second you open the IDE first time. That is something default Emacs can never do.
The main advantage on Emacs over IDEs, is that you can ask Emacs to do whatever you want as long as you know how to implement it. Practically speaking, you most likely will accumulate many little functions over time that is specific designed for your workflows. That kind of customizability is something IDEs cannot provide. I do not consider myself an Emacs power user, but I still benefit form it.
Emacs is also have better text editing features in general. You can use the same features no matter what text file you are editing. That's why people want to use Emacs for everything.
In short, they are different tools, use it where it is suitable for you.
For me, I whine about how bad the editor is when I use IDE, then I complain about how bad the integration my Emacs has between multiple tools (mainly my inability to make it work).
[+] [-] bloopernova|4 years ago|reply
You can do practically anything to text or other objects. If you can think of it, I'm pretty sure that Emacs can accomplish that for you. Any transform, file action, font changes, etc etc.
Example, this auto-saves a given file. In this case, whenever I archive an org-mode subtree, the archive file is auto-saved:
[+] [-] jpe90|4 years ago|reply
After I learned enough Common Lisp to build a few small projects, I realized how powerful it is to write small, bespoke functions for odd text editing jobs. You can write and save functions that do something very specific but powerful to any project you're working on, regardless of the language or tooling used, because everything uses text. I'm so glad I learned it.
[+] [-] convolvatron|4 years ago|reply
[+] [-] jmclnx|4 years ago|reply
[+] [-] Kessler83|4 years ago|reply
+ Org-mode + SLIME (Common Lisp IDE) + A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable). + Really smooth integration of LaTeX, Dot and Tikz. + Rock, rock, rock solid no matter what I through at it.
Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.
[+] [-] captainmuon|4 years ago|reply
The main reason why I don't like Emacs is that it feels very fragile to me. The first time I tried to use Emacs seriously - granted, that was many years ago and probably things have improved - I wanted to change the font because it was using an old X11 pixel font. So I went to the settings, and accidentially deleted the combobox that allows you to choose the font. I tried to configure it with the command line or REPL or what it is called and managed to mess it up even further. Later, as I got more familiar, I regularly managed to get it into a state that required restarting. It seems in Emacs, everything is a mode and everything is an editor, and there is no separation between content and UI (except for things like the menu bar, which uses a different toolkit and is bolted on). I've learned to appriciate less configurable editors because there is less to screw up, and you have the same good experience on any PC without your special config.
[+] [-] yissp|4 years ago|reply
[+] [-] elwell|4 years ago|reply
[+] [-] ReleaseCandidat|4 years ago|reply
That's actually not how I would describe Emacs. Not for Common Lisp either, Sly (and before that Slime) always had some glitches where I had to restart them or Emacs.
[+] [-] jimmyvalmer|4 years ago|reply
Try opening a large file. Or a small one. With emacs it's always a wait-and-see.
[+] [-] tsimionescu|4 years ago|reply
This is definitely not my experience. I regularly see emacs lock up indefinitely when asked to handle large buffers, especially when also using TRAMP. Even when it doesn't lock up indefinitely, it can easily stall for minutes(!) when doing something like moving point to the end of a large minified JS file (C-E).
There are many reasons to love Emacs, and I use it as my main development OS almost, but stability and performance are not among those reasons.
Note: mostly used it in console mode on Linux (Ubuntu WSL 2).
[+] [-] G3rn0ti|4 years ago|reply
This is the main reason I keep using Emacs for my everyday use. I never thought it was simply the best editor you could imagine. But it’s an editor I could always rely on.
There have been so many editors and IDEs in the past with their shiny features, great UIs and everybody screaming of excitement — until they were replaced by the next new shiny editor after a couple of years.
VSCode is surely a nice editor. (Although I don’t think its pixel dust UI is particularly great. And don’t get me started on its memory consumption.) Microsoft’s LSP, however, is a great idea. Emacs absorbed this feature already and will make it available even long after everybody stopped using VSCode within a couple of years.
Editors fall out of fashion. People die. Emacs remains Emacs.
[+] [-] jazzyjackson|4 years ago|reply
I watched a video on JetBrains [1] and the keyboard shortcuts and navigation look genuinely well thought out, so I’ll be giving that a try (with a vim emulation plugin, naturally)
[0] https://github.com/microsoft/vscode/issues/126310
[1] https://youtu.be/x8y_6Gg28GI
[+] [-] npsimons|4 years ago|reply
This might be my number two reason. I learned Emacs in 2000. Meanwhile, I've not had to learn, over and over again, all those other editors and IDE's. To be sure, I've honed my Emacs skills, installed and learned new tools in it (hello flycheck, elpy, SLIME, org-mode, TRAMP, CEDET), and just generally get on with whatever I'm working on ATM.
My number one reason has been the power though, especially after reading things like this: https://blog.vivekhaldar.com/post/3996068979/the-levels-of-e...
[+] [-] bovermyer|4 years ago|reply
I use a mix of editors on a day-to-day basis because they each solve a particular problem in a way I like. I imagine everyone else has a similar thought process. If you like the way it works, then it's the editor for you.
[+] [-] bradrn|4 years ago|reply
> Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material. The out-of-the-box experience is kind of basic and somewhat weird, but I don’t think that anyone should be using Emacs like this. You take this simple foundation, you shape and mold it to your taste and preferences and you end up with the best possible editor for you and you alone. That’s the reason why you should consider using Emacs. … For me, personally, the ability to extend Emacs easily with Emacs Lisp remains its number one advantage over vim. There’s also the fact that you can re-create much of the vim experience with Emacs, but you’ll be hard pressed to re-create the Emacs experience in vim.
For me, this is really the key attraction of Emacs. It’s not an editor; it’s a library for me to build my own ideal editor. And, in the long term, there are very few editors which can compete with this.
[+] [-] lvncelot|4 years ago|reply
[+] [-] kqr|4 years ago|reply
[+] [-] bborud|4 years ago|reply
Setting up Emacs reasonably for Go development just isn't even close to being straightforward. And with Go, go tooling and Emacs continually being changed, any setup that works will eventually stop working and you have to try to figure out how to rewrite your configuration. This happens often enough that even someone like me, who really, really didn't want to ditch emacs, eventually may do so.
I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
The goalposts moved. They are farther afield. Expectations of what an environment has to offer have gone up. If a decent developer experience isn't an understood priority, then Emacs isn't going to be very attractive for new developers. And it may have problems both attracting new users and developers and retaining new developers.
(That being said: VS Code is apparently going through a rough patch where things have gotten really buggy if you use it for Go development. So it isn't like VS Code is a magic bullet)
[+] [-] openfuture|4 years ago|reply
Vim has more users than Emacs and lately neovim gained a lot of traction; they managed to coordinate the community on a direction, ask for money, fund a new generation of programmers to learn the codebase and update it to be async and use a different script engine.
Emacs has had several efforts at replacing elisp or rewriting the core in rust or what have you... But they've never been able to budge the local maximum nor coordinate the community on the new direction. Actually, I believe guix is the new emacs because..
Neovim has succeeded in retiring vimscript for lua and from there a community is emerging around fennel (a powerful lisp that compiles to lua). This is the beginning of a very interesting answer to emacs which is growing fresh from old roots and there seems to be a lot of people eager to build tools with these tools.
Although I tend to think the brand value of vim and Emacs is worth a lot I'm starting to see a lot of new editor projects that look somewhat appealing but until the packaging and configuration management gets at least an order of magnitude easier I'm reluctant to spend time with these things.
[+] [-] fergie|4 years ago|reply
The fate of VS code seems to be really closely tied to TypeScript at the moment. If it turns out that Types really are the way forward, then these will eventually be included in the JS core. What then for TypeScript? Who even decides?
The nice thing about Emacs is that it is firmly rooted in standards and consensus. It will never be the best editor for most people at any one moment in time, but it has been a _good_ editor for decades and will continue to be so for decades to come.
[+] [-] NoGravitas|4 years ago|reply
Emacs is really short on core developers, and core development is hampered by the de-facto requirement that no aspects of user experience should change by default for longtime users with no out-of-core customization.
That said, the improvements in Emacs 28 are tremendous. The biggest is the native compiler, which will AOT compile Emacs Lisp code to native code, so lots of things that used to be slow are now very fast. Native JSON parser (maybe was added in 27?) means that LSP support is very fast. Pure GTK frontend didn't make it into 28, but will probably make it for 29, and means that Emacs on Wayland doesn't use X11 anymore.
What I'd like to see is a "standard distribution": something not as opinionated as Spacemacs or Doom Emacs, but which will apply more modern defaults, and have something similar to the Spacemacs "layers" feature, where there's a standard, supported way to enable the needed packages for a language or common workflow.
[+] [-] donio|4 years ago|reply
go-mode with godef, goimports and oracle was great during the early years. I remember telling people how the simplicity and quality of tooling and the great Emacs support around them was one of the reasons I enjoyed working with Go.
The transition to module support was a bit of a pain but that was a question of updates to the tooling, not Emacs itself. And then LSP came along just around the right time to deal with that and everything else.
Other than Elisp itself and Common Lisp (SLIME) I'd say Go is my favorite language to work with using Emacs.
Edit, looking at the timeline Go 1.0 was March 2012 and it took a year before we had go-mode with godef support. I guess I managed until then, it was simpler times in the Go world.
[+] [-] throwawy6sgd32|4 years ago|reply
[+] [-] _0w8t|4 years ago|reply
I stopped using Emacs like 10 years ago after realising that if one needs over 1000 lines of init.el then I am not the target user of the editor. I tried to reduce that via using external packages, but that has not helped much.
And for hobby projects I am happy with Geany on Linux.
[+] [-] cle|4 years ago|reply
It was more fiddly when I started because gopls was new, but now it’s just rock solid (and fast).
[+] [-] alex_smart|4 years ago|reply
Any specific example of Emacs being changed to break your workflow?
[+] [-] nodejs_rulez_1|4 years ago|reply
[+] [-] lvass|4 years ago|reply
It's mainly about how powerful plaintext is and how Emacs and it's community acknowledged that. Org and org-roam are extensions of my brain by now, I've even installed Emacs in my smartphone because of that. Ledger-mode is the most ideal finance management I could conceive, and I've set-up Emacs (CUA-mode with just a ledger hydra) for two family members so they could use it too. I have absolutely no idea how I could make Ledger tolerable to non-technical people without Emacs. I also create beautiful presentations in a couple of minutes using org-reveal.
Besides, it's hack-ability certainly inspires inumerable beautiful creations. Some packages like Magit, Hydra, Helm and avy are just that, beautiful. When I don't feel like programming, I change some config and write programs as an excuse to test it, because Emacs is fun. It's no wonder people who act like understanding your editor is a chore have a bad experience, they're missing the point.
[+] [-] jmclnx|4 years ago|reply
On OpenBSD there is one nit, and googling only suggested 1 fix. I am a heavy RCS user, but Emacs RCS package fails on OpenBSD due to its Base RCS. The only fix I can find is to install GNU RCS and disable OpenBSD Base RCS. I tried to find and fix the Lisp package, but it is way beyond my skill level.
OpenBSD people seems unconcerned about correcting their RCS to work with Emacs (maybe a security thing). I believe the same seems to be the case Emacs RCS people, I think they would prefer the use of GNU RCS (understandable).
I would prefer to use OpenBSD Base RCS but I am caught between two projects. So on OpenBSD I stick with vim until I can find a workable solution.
[+] [-] michaericalribo|4 years ago|reply
I agree with that wholeheartedly. Don’t get me wrong—I love emacs and I’ll be the first to talk your ear off about it.
But it’s a hobby, and not necessarily worth the time investment compared with other editors, if you’re looking for something that “just works” and has all the modern features.
[+] [-] nverno|4 years ago|reply
[+] [-] eulers_secret|4 years ago|reply
I even got syntax highlighting for patches and wrote some lisp to link up notmuch search results to gnus- so I can search for an e-mail and find the whole thread easily.
Of course, I could have just started evolution and been done, but this stuff is fun!
[+] [-] rich_sasha|4 years ago|reply
At my last job, I was forced to use PyCharm. Fine an IDE it probably is, I hated every second of it. Within 3 days I ditched it for Emacs.
[+] [-] dang|4 years ago|reply
Why Emacs? - https://news.ycombinator.com/item?id=3256721 - Nov 2011 (128 comments)
[+] [-] tharne|4 years ago|reply
I don't use emacs because I did some cost-benefit analysis on my editor. I tried emacs and found that it's a whole lot of fun, which of course is why I got into programming in the first place - I found it, and still find it, fun.
If you view programming as a job in the same way something like being a tax account is a job, then learning emacs is probably not for you, you're better off with something like VS Code that asks very little of its users and gives you a nice working environment right out of the box.
Emacs is great if, as the author notes, you're an intellectually curious person who genuinely enjoys tinkering. If that's the case, you'll most likely have a lot of fun with emacs. It's very hard to describe how much fun it is to edit and modify your development environment in real time while you're working in that very same development environment.
[+] [-] otterpro|4 years ago|reply
[+] [-] bmj|4 years ago|reply
Two of those editors are Mac-only, and only one editor is open source. I suspect if Sublime had become open (and cross-platform), it would be significant "player" in the editor wars. Atom has mostly died on the vine, thanks to VS Code. That doesn't negate any of the author's points about Emacs, but, aside from VS Code (and, I guess, Atom), there have been few efforts to create a performant[0] cross-platform, IDE-like editor.
[0] Insert comments about VS Code's performance here.
[+] [-] bozhidar|4 years ago|reply
Btw, I think TextMate is open-source these days as well.
[+] [-] bradjohansson|4 years ago|reply
Emacs is not rock solid.
It's easy to bring Emacs to a standstill with something as simple as a long string. This is especially apparent outside Linux, e.g. on Mac OS (Windows is a whole other story). It's a fundamental flaw in the text editor, and I don't know if there is any solution on the horizon.
Text editing can also become noticeably slower once many of the must-have Emacs packages are in use.
At the same time, becoming somewhat proficient at Emacs and knowing a thing or two about Emacs Lisp has made me a better programmer, and certainly more productive in the use of my editor.
If Emacs can solve some of its performance issues, and perhaps make things like the Debug Adapter Protocol easier to set up, it will continue to be in a league of its own and an essential editor to many for the foreseeable future.
[+] [-] rvieira|4 years ago|reply
[+] [-] rackjack|4 years ago|reply
[+] [-] Phenix88be|4 years ago|reply
[+] [-] DonHopkins|4 years ago|reply
As passionate in your love for Emacs as Kyle Machulis is? ;)
https://news.ycombinator.com/item?id=29207607
https://github.com/qdot/deldo
https://www.youtube.com/watch?v=D1sXuHnf_lo
[+] [-] searene|4 years ago|reply
Sometimes I do use VSCode as an alternative, but VSCode only has a rudimentary implementation of org-mode, and the so-called org-mode alternative - markdown - is not nearly as powerful as org-mode.
[+] [-] andrewaylett|4 years ago|reply
I used to live inside Emacs -- not just for coding but for mail and news too. But nowadays I use Jetbrains IDEs for development and a reasonably clean vim for editing random files.
[+] [-] agumonkey|4 years ago|reply
[+] [-] mettamage|4 years ago|reply
I'd really appreciate it.
Currently, I've only mustered enough courage and time to understand enough of vim to not feel scared of it anymore (vimtutor was the silver bullet for me there, learning enough vim in an hour to feel fine with it).
[+] [-] prohobo|4 years ago|reply
JetBrains makes great IDEs, and you should use them if you're working on a large project that one of those IDEs is geared towards. It'd take a lot of work to get any other editor to have the same feature-set and organization of workspace.
Emacs is a general-purpose environment for writing, and you should use it if you want a specific flow for writing code, or anything else. You can setup plugins so that it's like a mini IDE for most of the languages you write in, and you can setup plugins to modify the organization of your workspace. You want tabs? Add them. You want a tree view of your current project folder? Add one. You want Vim-style editing? Enable it. Etc.
Right now it seems everyone is looking for a code editor that is extensible and fast - Emacs fits that bill better than VS Code (also Neovim might end up being even better!), but it's more difficult to get it right. That's why there are projects like Spacemacs and Doom Emacs to make adding/removing plugins easier, and also have a good setup out of the box.
[+] [-] r3n|4 years ago|reply
The main advantage of IntelliJ or any other IDE by JetBrains over Emacs, is that the out of box experience IDE provided, especially from a new programmer's perspective. All they need to do to click a button, check few checkbox, then IDE will resolve it for you and tell you what happened.
But to make Emacs do any complex behaviors, you usually have to write additional codes or configurations to glue different features together. Not to mention you need to read documents and debug it when there is an error. In JetBrains IDEs those are integrated already. A context-aware error detection and code inspection is available the second you open the IDE first time. That is something default Emacs can never do.
The main advantage on Emacs over IDEs, is that you can ask Emacs to do whatever you want as long as you know how to implement it. Practically speaking, you most likely will accumulate many little functions over time that is specific designed for your workflows. That kind of customizability is something IDEs cannot provide. I do not consider myself an Emacs power user, but I still benefit form it.
Emacs is also have better text editing features in general. You can use the same features no matter what text file you are editing. That's why people want to use Emacs for everything.
In short, they are different tools, use it where it is suitable for you.
For me, I whine about how bad the editor is when I use IDE, then I complain about how bad the integration my Emacs has between multiple tools (mainly my inability to make it work).
Hope this give you some ideas.