Why Emacs: Redux

https://batsov.com/articles/2021/11/16/why-emacs-redux/

by winkywooster • 5 years ago

270 205 5 years ago

batsov.com

dang• 5 years ago

The earlier article, discussed at the time:

Why Emacs? - https://news.ycombinator.com/item?id=3256721 - Nov 2011 (128 comments)

bozhidar2• 5 years ago

Thanks for sharing!

rackjack• 5 years ago

Org-mode is Emacs's "killer library" for me.

Phenix88be• 5 years ago

Also magit !

tcmart14• 5 years ago

Magit is what got me hooked. I just find it the best way to interface with git other than via the terminal.

kdtsh• 5 years ago

Absolutely. git at the command line works fine but I have always found it very dense, and prefer to use it only for very basic or very specific tasks. Magit makes all the usual things I do with git so easy.

I have been using Emacs on Windows for a couple of years, but I have been transitioning to using Linux full-time at work, and by the end of the year I won't have to deal with the slowness of Magit (and git in general) under Windows.

michaericalribo• 5 years ago

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.

nverno• 5 years ago

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.

eulers_secret• 5 years ago

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!

rich_sasha3• 5 years ago

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.

G3rn0ti5• 5 years ago

it is just so esoteric to anyone used to ctrl+C for copy

Come on. „CUA mode“ exists since the 90s. ;)

bradrn3• 5 years ago

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.

lvncelot2• 5 years ago

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.

Ketan-fullstack• 5 years ago

Modal editing is what made me go back to vim after 2 months of wanting to like emacs. Even with EVIL mode it didn't feel just as smooth.

Are there other ways to get modal editing in emacs?

philsnow4• 5 years ago

If you're a big user of vim macros, take a look at some of the quality of life enhancements that emacs macros have: https://www.gnu.org/software/emacs/manual/html_node/emacs/Ed... specifically kmacro-edit-macro and kmacro-edit-lossage

You can edit vim macros but it's not nearly as seamless

kqr• 5 years ago

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.

andi9992• 5 years ago

So how to learn this? I used Emacs for a couple of years long time ago, but while the experience was ok, it didn't last. Is there a book/or blog about the magic you mention?

bradrn3• 5 years ago

There isn’t one in particular I can recommend (or remember). Just look up how to install packages, look at other people’s configs, explore what packages are available, and so on. That’s basically what I did.

BeetleB• 5 years ago

The Emacs From Scratch series on Youtube is actually quite good. He does have all his config in a Github repository if you need to copy/paste.

This is the first video:

https://www.youtube.com/watch?v=74zOY-vgkyw

randomcarbloke• 5 years ago

if you're a machinist long enough, you end up making your own tools that iron out the minor but ubiquitous quirks that drive you to the brink of madness.

I'm happy faffing around with Sublime, VSC, even Nano, but when I'm doing anything substantial over an extended period of time I'll always use Emacs, not only that but in the world of Atom Emacs has to be one of the fastest loading/running editors.

npsimons2• 5 years ago

Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material.

That quote reminds me of this quote:

Lisp isn't a language, it's a building material. -- Alan Kay

Funny, Emacs seems to be written in Lisp . . .

Kessler838• 5 years ago

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.

captainmuon• 5 years ago

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.

Kessler838• 5 years ago

I mean rock solid as in being able to edit buffers with very different contents of half a million characters, every day for decades without crashing. I wouldn't call what you describe fragile. It sounds more like a typical learning experience. You did something, Emacs obeyed and then you who didn't like what you just did :). There is a market for restricting choice, so you are clearly not alone!

But I don't think that the Emacs learning curve should be exaggerated, either. If you start it up and follow the instructions, you very quickly become productive. What gets people into trouble is usually when they expect Emacs to be like software X which they already know, so they don't read what's on the screen and kind of skip the introduction. And then they get frustrated when they find out that Emacs is Emacs. I'm not saying that's you, or that it is stupid, impatient etc. or whatever. I'm just saying that I've seen it quite a few times.

Jtsummers5• 5 years ago

So I went to the settings, and accidentially deleted the combobox that allows you to choose the font.

I'm genuinely curious how you did this, and how you did it in a way that was permanent. The customization screens are read-only by default (except for those boxes you type text in to specify the customization) and they're programmatically generated, not fixed.

ReleaseCandidat10• 5 years ago

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.

Kessler838• 5 years ago

Well, to each their own. I never have to restart Emacs. The only time I restart SLIME is when I do something I shouldn't, like redefine a struct or something. I'm sure I could avoid restarting SLIME, too---I just never bothered to learn if there is a way.

BTW, all software that changes will have a bug from time to time, but Emacs and things related to Common Lisp are like at the very bottom of the trouble-frequency charts. I can't think of any software that I use regularly that gives me fewer problems. For the record I never encountered a bug in either (which doesn't mean they don't exist).

tsimionescu• 5 years ago

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).

Kessler838• 5 years ago

Well, I guess we have different experiences then. That kind of thing hasn't happened to me in 25 years. Not once.

The OS could matter, I guess. I didn't even think about that. I used Debian Stable and have been since the last century. Always a version or two behind, at least, so I guess bugs could be resolved before I get a chance to encounter them.

rusk2• 5 years ago

I have experienced the same things but even so I would classify it as fairly rock solid overall. Under certain circumstances a rock can split. I see far more fragile, and unpredictable behaviour in other environments.

It must be said that large file handling is an area that could do with some improvement - vlf-mode is okay as a workaround but it would be nice if I could deal with a large file in much the same way as a regular sized files. Few environments will provide this either though.

jimmyvalmer6• 5 years ago

Rock, rock, rock solid no matter what I through [sic] at it.

Try opening a large file. Or a small one. With emacs it's always a wait-and-see.

Kessler838• 5 years ago

You should probably tell Emacs users about it---they may not have noticed.

yissp• 5 years ago

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.

mumblemumble• 5 years ago

Java support is, unfortunately, iffy in every editor that isn't made by JetBrains.

I've recently got Python working well. It can be done. The deeper problem - and this is admittedly ubiquitous in emacs - is that the defaults are awful, and there is not even good discoverable official documentation about what configuration you should use because everyone's just a wee bit too content to allow, "We have a very welcoming community on IRC!" to stand in for a proper new user experience.

rwilson42• 5 years ago

I use elpy regularly for python development. Handles virtualenvs really well, makes it super easy to run one or all test cases. Good support for linting and reformatting (black).

I should note that I don't work on large codebases. My codebases have ~20 files and <20,000 lines of code total. I know some folks prefer LSP and that might be the reason.

AlexCoventry2• 5 years ago

It's been a few years since I developed in python. What kinds of limitations does emacs have for it?

elwell• 5 years ago

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?

DonHopkins• 5 years ago

One thing hasn’t changed though - I still love Emacs and I’m quite passionate about it.

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

mettamage• 5 years ago

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).

prohobo• 5 years ago

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.

r3n• 5 years ago

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).

Hope this give you some ideas.

heavenlyblue• 5 years ago

Why would I need emacs for "complex behaviours" if I have <insert any programming language> installed on my computer?

For example, I made a lot of scripts in Python to refactor codebases by automatically splitting files (including imports). Could I do that with emacs? Probably yes. But why?

For most intents and purposes it doesn't matter if your "automated editing" environment is integrated in your editor.

rvieira• 5 years ago

Emacs is my personal little starship that helps me cruise the vast universe of computers :)

bborud10• 5 years ago

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)

throwawy6sgd32• 5 years ago

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?

bborud10• 5 years ago

I used to have a decent working knowledge of Emacs Lisp, but I wouldn't use words like "mastery". I could get stuff done. However, I haven't done any development in elisp for at least 15 years. Think of it has car ownership: I might have been interested in repairing my own car in the past, now I just want a car that does what it says on the tin and not have to futz around with it.

I used to have a highly customized Emacs setup with a lot of code that would automate lots of tasks for different programming languages and environments. I essentially ended up using an email reader that I found somewhere and then rewrote to include a lot of automation of the way I did my email.

Of course, things changed over time. My customizations started breaking - more and faster each year. I went from having my email delivered on a traditional mailbox file, to using IMAP. Along the way I had to use POP (because I could emulate having a mailbox file) the client needed a major rewrite to deal with IMAP and in the middle of the rewrite I gave up because something else broke. I have always worked on multiple machines, so I had to synchronize setups - sometimes between machines with different emacs versions.

I used Emacs for fewer and fewer things until it was only used for writing code and markdown files.

Heavily customizing anything is risky because at some point you become the sole maintainer of a lot of code. At one point I'd spend perhaps 2-3 days per month programming Emacs Lisp - which, at the time, was not all that great.

I don't customize software I depend on that much anymore. Including keybindings. It is cheaper to try to learn defaults, and if you put your ego aside, usually not that big of a deal. This doesn't mean you can't add functionality or customize it - it just means you shouldn't have to rewire the innards to accomplish it.

Sadly, in Emacs, "extensions" are, to put it mildly, a rough ride. And more so the more you customize. Things are a bit too "freeform". You end up saying no to a lot of things you could have had for free because things start to clash with your customizations. "You broke it, now you own it".

I have a very clear benchmark for what might bring me back to Emacs: be able to set up Emacs from scratch in 10 minutes so that I can program in Go, have good language server support, easy access to documentation, and a lot of the things I used to have before, but which simply rotted away over the past few years.

....and then not have it break in a way that requires more than a couple of minutes of my attention for a year.

fergie2• 5 years ago

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.

ReleaseCandidat10• 5 years ago

The fate of VS code seems to be really closely tied to TypeScript at the moment.

That's like saying the the fate of Emacs would be closely tied to Common Lisp (or Coq with Proof General). That's some languages Emacs where still beats anything else.

zkldi• 5 years ago

If it turns out that Types really are the way forward, then these will eventually be included in the JS core.

Not necessarily? TypeScript could easily continue being its own thing as it is now, and ECMAScript have shown absolutely 0 interest in adding types to the core language a-la TypeScript. Infact, the amount of work needed to enable types (supporting new syntax) would result in so much backwards compatibility breaking that it wouldn't even be feasible.

TypeScript is way more likely to remain its own thing.

_0w8t3• 5 years ago

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.

bborud10• 5 years ago

Do you use the syncing features? I sync to Github, so if I install VS Code on a new machine it takes a lot less than 20 minutes. That bit works great.

b5n• 5 years ago

To each their own, but it doesn't take long to setup Emacs from scratch to the exact state I want.

  git clone myemacs
  mv myemacs ~/.emacs.d
  emacs

qubitcoder• 5 years ago

This is why I've been using Spacemacs as my primary editor for years now: cross-platform support, automatic language detection, package installation, well-designed key bindings, great documentation, etc. Not to mention significant productivity gains from packages such as magit (it's always fun when people see Git time machine in action--using the n/p keys to move backwards and forwards in time to see every change to a file, along with the commit message).

And it works across all major OSes. Just copy your .spacemacs file to a new laptop, and wait for everything to install itself.

To be fair, I use VS Code pretty regularly as well. But more of a nicer alternative to TextEdit/Gedit/etc. to capture notes as I work in Spacemacs (of course, there's also the helpful scratch buffer).

[0] https://www.spacemacs.org

alex_smart3• 5 years ago

Emacs continually being changed, any setup that works will eventually stop working

Any specific example of Emacs being changed to break your workflow?

bborud10• 5 years ago

Go support is one example. If you set up Emacs to provide decent support for Go at different times between 2015 (when I started using Go) and today, the setup would probably last an average of 18 months or so before you lose something significant and had to sit down and bodge something together to get some replacement for functionality that just died.

I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.

openfuture• 5 years ago

Yeah so I was thinking about this...

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.

nodejs_rulez_1• 5 years ago

If you pick a language designed by someone who explicitly hates tooling, then you are bound to suffer from the lack of good tooling.

bborud10• 5 years ago

are you talking about Typescript, JavaScript or Emacs Lisp?

donio4• 5 years ago

Assuming that you are talking about Go, I don't know where you are getting that from.

Go has had excellent tooling from early on. Standard code formatting with gofmt from day 1 was HUGE. godoc, godef, goimports and oracle were also available from early on. And then when LSP came along we got multiple LSP server implementations fairly quickly.

I don't have a link around but I am fairly certain that getting the basic tooling into shape was one of the priorities before the 1.0 release.

cle• 5 years ago

I’ve been using Emacs for Go dev for years and have barely touched my Go-related config. It’s vanilla lsp-mode with some hooks like format-on-save.

It was more fiddly when I started because gopls was new, but now it’s just rock solid (and fast).

NoGravitas4• 5 years ago

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.

cutler2• 5 years ago

Spacemacs seems to be dead. 0.300 has been promised for years but still hasn't gone stable.

donio4• 5 years ago

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.

G3rn0ti5• 5 years ago

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.

jazzyjackson• 5 years ago

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)

[0] https://github.com/microsoft/vscode/issues/126310

[1] https://youtu.be/x8y_6Gg28GI

noir_lord• 5 years ago

I live in Intellij, it has it's own minor warts but it's a superpower compared to anything else I've used.

It covers everything (code, inspections, docker, database layer, seamless multilanguage support).

bovermyer• 5 years ago

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.

buzzwordninja• 5 years ago

Are we talking the 1980s word processor WordStar??

npsimons2• 5 years ago

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.

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...

Zababa• 5 years ago

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, and I have a feeling they will be with us for decades to come. This means that an investment in them will be likely paying you dividends much longer than an investment in a newer editor or IDE.

The thing the author seems to forget is that you don't need to "invest" anything to learn VSCode. I also wouldn't call it an investment, as you can't really "forget" your Emacs skills and get part of your money back. It's more like buying a tool. VSCode was free, or almost free. Emacs seems to cost way more.

bloopernova• 5 years ago

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)

convolvatron• 5 years ago

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

phyrex• 5 years ago

AFAIK it supports SVG rendering. Is that not enough or what did you have in mind?

cossatot3• 5 years ago

I agree completely. I made a big push to switch from vim to spacemacs so that I could use org-mode for note taking and reduce my dependence on paper notebooks, but the lack of ability to easily sketch really killed it. I'm a geologist so I need to sketch out maps and other kinds of figures that aren't just scatterplots and flowcharts or whatever (which can be done programmatically). If I could have something even quite crude it would be revolutionary, especially if the org clients were improved for iOS with better editing/syncing capabilities and less of a focus on agenda and calendar capabilities (todoist and native calendar apps work better for my job situation, personally). The rest of org is so easy and powerful... I still dream my little dreams but am not willing to learn how to implement something like that myself I guess.

chadkennedy2• 5 years ago

Would this help? https://elpa.gnu.org/packages/sketch-mode.html

jmclnx2• 5 years ago

Learning Lisp is on my "bucket list", I know where to go to learn it but I need the time :)

davidw• 5 years ago

Emacs lisp is something you can figure out a bit at a time: mostly you're writing 'snippets', rather than organizing some huge codebase where you have to know all the ins and outs.

dotancohen3• 5 years ago

  > Learning Lisp is on my "bucket list", I know where to go to learn it but I need the time :)

Where?

jpe904• 5 years ago

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.

codethief• 5 years ago

I'm glad to hear that because so far my impression agrees with yours (before you learned Lisp) and this comment[0]. Do you happen to know a good tutorial to learn Emacs Lisp?

[0] https://news.ycombinator.com/item?id=29256103

searene2• 5 years ago

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.

User23• 5 years ago

Does pixel-scroll-mode[1] not do what you want? It’s a built-in feature.

[1] http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/pixel-s...

NoGravitas4• 5 years ago

pixel-scroll-mode was introduced at or before Emacs version 26.1.

The third-party package "good-scroll" improves on pixel-scroll-mode by adding variable speed. IME, it's necessary in order to prevent flickering from pixel-scroll-mode. The defaults are somewhat conservative, and might not look like "scrolling pixel by pixel" to you, but you can definitely customize it to get what you want.

searene2• 5 years ago

Thanks. Actually I've tried both the built-in pixel-scroll-mode and good-scroll. None of them gives me the experience of a modern text-editor (e.g. VSCode).

dreamcompiler2• 5 years ago

Related: My biggest complaint with Emacs is that when you scroll, the cursor moves to keep itself visible on-screen at all times. Modern text editors don't behave this way--it's easy to scroll to a different location to look at something without losing your insertion point.

Has anybody written a patch for Emacs to implement this behavior?

NoGravitas4• 5 years ago

I don't think so, and I think it might involve unreasonable changes to core.

The "Emacs Way" here is to use a command that takes you back to where you were before. If you used tags navigation to get to what you wanted to look at, you could use `pop-tag-mark`, which is on M-, (other modes for getting around, like xref and LSP use the same binding). Or failing that, if you know you're staying in the same buffer, you can `set-mark-command`, scroll to where you want to look, and `exchange-point-and-mark` (and then deactivate the mark with C-g if you were in transient-mark-mode, which most people are these days).

There's also a package `dogears' (https://github.com/alphapapa/dogears.el) for saving your place to go back to automatically even if you're just scrolling.

I recognize that all these solutions are not intuitive to someone who expects the cursor position to stay in the same place even if it scrolls offscreen.

bmj• 5 years ago

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.

bozhidar2• 5 years ago

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.

agumonkey• 5 years ago

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.

keymone2• 5 years ago

i'm one of them traitors that switched to vscode from emacs. over time i just realized that i'm spending too much time coding the code editor, just can't stop, there's always something that isn't perfect, always some new approach or new extension, always a better way somebody else solves the same problem. got tired of playing catch-up.

with emacs i have this mindset, that emacs can do literally anything and be perfect for my brain with enough tuning. with vscode i know it's limited and don't bother fixing it, just muscle-memory the workarounds.

i do miss magit.

rprospero• 5 years ago

Would you have a little time to describe how you made that switch? I've worried multiple times that I'm too deeply immersed in the emacs ecosystem and have wanted to try branching out into a different editor to see what I might be missing. However, when I spent a month using vscode, it was just a month of lost productivity. I found the interface completely inscrutable and couldn't find any good explanations of how to think about vscode.

As a concrete example, for the main project I work on, we usually configure via CMake and then build through Ninja. A simple `cmake` command followed by a `ninja -j4` was all I needed to get everything built. However, I could never get vscode to just do that. I saw that it had its own internal version of CMake (that could never find my shared libaries) and it had its own build system, but they usually failed to build (despite the code still building just fine on the command line). Every guide I found on vscode was about starting a new project from scratch and didn't touch on working with existing code.

I know that the issue has to be how I'm thinking about vscode. That I'm not understanding its philosophy on how to work with code. What that philosophy is, though, I can't seem to find a good understanding of.

keymone2• 5 years ago

I’ll let somebody more experienced to chime in on cmake and organizing c++ project builds, but vscode has decent built in shell where you could just run the commands you need without leaving the ide.

There’s way less philosophy to vscode than to emacs, i would suggest using it as dumb editor for a while and explore how various extensions make your life easier. If they don’t - maybe you just got your eMacs config right and should stick to it :)

yoyohello13• 5 years ago

I had the same experience with window managers. I used to spend a lot of time customizing my perfect tiling wm setup. It was fun, but every time I saw a little issue or inefficiency I'd have an impulse to fix it. Now I just use default gnome for everything. I find I'm much more productive and happy when I just accept the defaults.

andrewaylett• 5 years ago

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.

jmclnx2• 5 years ago

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.

trevorriles• 5 years ago

Magit is the thing that keeps my tied to emacs. No other tool gives me such a good experience interfacing with git.

tharne3• 5 years ago

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.

lvass• 5 years ago

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.

otterpro• 5 years ago

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.

prerok3• 5 years ago

Is it still true that saving a file you are working on is Ctrl-x Ctrl-s? I am sorry but I will take vim's :w normal/insert/visual mode hell over this simplistic but cumbersome ergonomics issue any day.

(disclaimer: happy vim user but always looking :) )

martinflack• 5 years ago

You'd rather hit 4 keys over 3? And use 2 hands instead of 1 (US keyboards)?

shift semicolon w enter

ctrl x s

(Flaming in jest and good heartedness)

spijdar• 5 years ago

I know this is (partially) a joke, but it does raise an interesting point to me (as a vi heathen), why does :w seem easier to remember than C-x C-s?

I guess it's the modality, I know ':' indicates the start of an ex command, and "w"rite saves the file, while I only see C-x C-c as a "single token".

I supposed it's just C-x for "execute command" and ... I'm not sure why it's control c, instead of just c, or s, or w...

prerok3• 5 years ago

Well, it's been years (like 15 or so) since I gave it a go, really, so maybe I should try again. But, yes, holding Ctrl and then pressing X and then S seemed too cumbersome for an ordinary operation like saving your buffer (or frame?).

Back then I was also using vim in mswin mode where Ctrl-S would save the file, just like in Windows.

Interestingly, though, I still find :w<Enter> easier. Maybe it's muscle memory now, maybe because I don't need to hold a second key for two key strokes, maybe colon is easier for me, maybe...

I guess I need to check my habits more closely :)

bradjohansson• 5 years ago

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.

Why Emacs: Redux

Related Stories