The Emacs Lock-In Effect or the Emacs Sunk Cost Fallacy

https://karl-voit.at/2021/07/23/emacs-lock-in/

by fipar • 5 years ago

175 265 5 years ago

anyfoo9• 5 years ago

I'm in a similar boat as in the first quote: Have used emacs for decades, glad that I do, can't imagine switching... don't think I would recommend it to anyone new, unless they are really open about learning something entirely different.

Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world. This starts with (nowadays) non-conformant shortcuts, includes window/buffer management (the terminology alone is archaic: panes are windows and windows are frames), and ends with elisp, which even Lisp programmers themselves rebuke.

But such a do-over is impossible in both LaTeX and emacs, since that would also mean throwing all the thousands (ten thousands?) packages--and lots of core functionality--away. Stuff that has accumulated for many decades and that is the reason why we're sticking with it: Everything else feels very limited in comparison.

And it's not just the "big" things. When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things.

Admittedly, I haven't tried modern distributions like spacemacs and DOOM Emacs, but it's a bit hard for me to imagine that you won't need to come face to face with "emacsism" at some time.

CalChris2• 5 years ago

With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud).

I don't want to master an editor anymore. I want to get work done. Pretty much the same with LaTeX. When I want to improve something in a doc, I look it up and do that. When I go back to the doc later, I don't always remember what that magic meant. But that's ok, I'm writing a doc. I'm not trying to master the writing of a doc.

anyfoo9• 5 years ago

I don't want to deeply learn an editor myself anymore, too, but that being said I am still extremely glad that the past decades have made me proficient in emacs. The editor is just one of the most important tools for me.

cpach2• 5 years ago

Just out of curiosity, which editor do you use? Overleaf?

User23• 5 years ago

Imagine a carpenter saying, "I don't want to master my tools, I just want to build things."

Ar-Curunir• 5 years ago

The problem with LaTeX is that it isn't well-designed enough that you can just use it without thinking about the magic.

When stuff is not up to scratch (image is placed incorrectly, spacing in your table is wrong, your diagram has an incorrect alignment, etc), the error messages suck, and you often need to figure out what the magic does to be able to fix the issue.

marcosdumay• 5 years ago

The thing with LaTeX is that it's a full text-oriented programing language. What is great if you want to extend it, but a problem if you want to use it on any context not supported by the interpreter. So, if you don't want to create a PDF, it just sucks.

eulgro3• 5 years ago

With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud).

$ latexmk -pdf main.tex

How hard is that? The only thing Overleaf adds here is a button and a 10x compilation time overhead.

I don't always remember what that magic meant.

Overleaf mostly won't help you here, unless I'm mistaken.

I don't mean to be aggressive here, I just don't get the Overleaf hype. What's wrong with good old text editor + version control? I think I'll pass on the slow web app for now. At least they have Git integration so nobody is going to force me to use it.

lenkite• 5 years ago

Use pandoc

908B64B197• 5 years ago

But such a do-over is impossible in both LaTeX and emacs, since that would also mean throwing all the thousands (ten thousands?) packages--and lots of core functionality--away.

For LaTeX a large part of the appeal is to get a template and be able to respect whatever arbitrary formatting requirements.

Someone could build a layer on top of existing LaTeX to add a more modern language on top of it and have it expand to LaTeX.

grae_QED2• 5 years ago

Why redo something if it works? People are still using Fortran because it works well for certain applications. Just because its old doesn't mean its outdated.

I could even argue that since Emacs hasn't been phased out (and still has a decent user base) that it does something that other text editors don't (or can't) do.

Jtsummers5• 5 years ago

Fortran has seen major changes over the 64 years it's been in use. I feel that Emacs Lisp has had a much slower evolution (though admittedly I've only used it for about 20 years, I can't comment on how much it changed prior to that).

In particular, the biggest change I'm aware of with Emacs Lisp (the language) is that we now have lexically scoped variables. The biggest change to its implementation has been a push towards native compilation (much improved performance, I like it). The language has, otherwise, largely remained the same.

In some regard, this can be seen as a consequence of having a decent base language. Where Fortran's original version became increasingly indecent as time went on, Emacs Lisp seems to have held up better thanks to a stronger foundation. That doesn't mean there isn't room for improvement.

In particular, the things that (my opinion) are still missing from the language are:

1. A good concurrency model. CSP, actors, I don't care but it needs to exist. Paired with the native execution we're getting now, this would greatly improve the real and perceived performance of the system.

2. A real module system. I'm not talking about a package manager, but moving things into module scopes a la Common Lisp packages. The prefixed names for functions and variables is a hazard. Even if you leave every symbol exported by default so that you don't lose visibility to module internals it would be better than now. It would also open up a lot of opportunities like the potential to run multiple versions of the same package side-by-side.

tsimionescu• 5 years ago

Well, Emacs has some major limitations as an editor, places where it really shows its age. Particularly, it is single threaded and this affects many normal uses - for example, while opening a connection to a remote machine with TRAMP, the whole GUI is completely frozen. Similarly with many development tools, such as magit or the excellent lsp-mode (Language Server Protocol support).

anyfoo9• 5 years ago

Part of my point was that it's difficult to get into (still worth it overall), but another part is definitely that technology has moved on, and emacs often reminds me of its age there.

No matter what, emacs still feels "alien" in my OS's desktop interface with its UI concept, and never fully integrates. That's fine if you don't want it to integrate, but I actually like some concepts of my OS's UI a lot, and miss them in emacs.

And elisp is not a very good language, born of a time where programming languages still had a long way to go (at least in the mainstream, academically it always seems a bit different to me). They are actively trying to fix things, e.g. the adoption of lexical binding, but the scope of this effort also shows how emacs is a very big ship that is hard to change course.

Someone else mentioned lack of proper multi-threading in another comment now, and this is also very noticeable.

Koshkin5• 5 years ago

entirely different

Well not entirely - it's modeless, and some usual keybindings work as well (Home/End, etc.). The built-in tutorial is brief and to the point, it will get one started pretty quickly.

chipotle_coyote4• 5 years ago

Admittedly, I haven't tried modern distributions like spacemacs and DOOM Emacs, but it's a bit hard for me to imagine that you won't need to come face to face with "emacsism" at some time.

Speaking from the experience of someone who has repeatedly bounced off Emacs for going on two decades now, you absolutely will. :)

When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things.

This sort of "little thing" is, perhaps ironically, why I keep going back to BBEdit, at least for my technical writing work: it has a whole lot of these little "multipurpose tool" commands for text manipulation -- and, because they're in old-school Mac menus, they're discoverable. Thinking about it, that's one of the main reasons I bounce off both Emacs and Vim: it's not that I can't figure out the basics or even the, er, intermediates; it's that so much of the advanced stuff is relatively opaque. I am sure that there is probably a command in both Emacs and Vim that equates to, for instance, "find all lines matching this regex that occur more than once in this document, delete them, and copy them to a new document" (a task which sounds like I am making it up, but I swear I have had to do on multiple occasions in my current role). But I am also sure that it is not as easy as selecting "Text > Process Duplicate Lines..." and checking "Delete duplicate lines", "Leaving one" and "Match using pattern".

anyfoo9• 5 years ago

Top of my head, I am pretty sure that I can do that with a "keyboard macro" involving list-matching-lines, and delete-matching-lines (that is literally what the commands are called). "Keyboard macro" by the way is a good and a bad name at once: It does not fully describe the vastly more powerful feature, as it is much more semantic than just repetition of keystrokes, but at its surface it looks like that and helps you get started.

If anyone reading this hasn't used keyboard macros in emacs, try it out the next time you do something repetitive. It's amazing how it can simplify those tasks. "C-x (" to start defining one, "C-x )" to end it, "C-x e" to run it, which conveniently also ends definition if you want to use it right away. Of course you can do things like "M-5 C-x e" to run it 5 times.

But I do get your point: Things are probably much less discoverable in emacs, unless you are relatively proficient in it already maybe. You need to switching into a "programmer" mind fairly quickly, while BBedit probably just lets you do powerful stuff through simple UI.

taeric3• 5 years ago

With modern autocomplete for commands, discovering commands in emacs has never been easier. "M-x sort" will show you all fuzzy completions of that commands basically instantly.

The flow you just mentioned I think looks nigh identical.

Cacti• 5 years ago

There’s at least two ways you could keep the Emacs ecosystem while refreshing some of the other pieces (to build a new editor):

- You could reimplement the Emacs LISP VM and change what some of the native editor types refer to (buffer, point, window, etc.) so that they are interpreted in a “modern” UI setting. Maybe add some new opcodes while you’re at it to handle things like threading.

- You could fork emacs, strip out the display engine, and completely rewrite it (it’s notoriously complicated and probably not worth dealing with 50 years of legacy hacks).

Either of these options would give you a reasonable chance of skipping over the inherent complexity of the system without having to ditch all of the ecosystem packages), though they’re both still pretty involved.

A big part of the reason for this is you’d inherently end up losing some OS compatibility in the process, and maintaining compatibility is probably the biggest problem with making changes or updates to emacs. If you’re willing to ditch that burden, your options expand dramatically.

stouset3• 5 years ago

And it's not just the "big" things. When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things.

FWIW this is something most editors let you do trivially.

With VS Code, select the lines you want to sort, press Cmd-Shift-P to bring up fuzzy command search, type "sort", press enter. Your selected lines are sorted.

I think you might be surprised to find that all the major editors these days have most all of the little things you might want day-to-day covered. Of course the set of little things one cares about will differ from person to person and from the capabilities we've personally found the most use out of. It's hard to argue when that one thing you use every day isn't supported in some other editor, but the list of those is shrinking quicker than I suspect most people realize.

There are a lot of people contributing to these tools and that plus not having to reinvent every wheel from scratch (and maintain that code on top) means that modern editors can cut into the lead time advantage of something like Emacs quicker than you might otherwise think.

neolog5• 5 years ago

I agree with what you say about IDEs, but Emacs' "advantage" over other text editors is that it is only superficially a text editor. It's really more of an operating system.

viseztrance• 5 years ago

I think you would still be surprised at how many things emacs can still do better like undo in region or even simple macros that find use even during simple text edits.

Though ultimately feature per feature, I don't think emacs looks all that great, but the difference is that you can actually use a lot of what it has to offer whereas it's difficult to do so in more modern editors (with fuzzy matching and all).

ellyagg• 5 years ago

I'm a long term emacs user and I know that my emacs use is not down simply to lock-in. I know this because a year ago I spent a month using Panic Nova to see what I might be missing with emacs.

Nova looked super pretty and it's easy to figure out how to do a lot of things out-of-the-box that's harder to figure out on emacs at first.

But there are a couple of core things about emacs that I just don't see replicated in the popular IDEs.

1. The way you manage buffers and "windows" (just partitions of the screen in your GUI window). Buffers and windows are decoupled, which will make no sense to most people if they aren't fluent in it. And these little window partitions are quickly built, re-sized, split, and destroyed at a moment's notice from the keyboard. I can and do regularly go from 1 to 12 partitions at a moment's notice. I switch buffers in partitions constantly.

I tried so hard to figure out how to not make buffer and window management suck in Nova, but to no avail. I've also done some professional development in VS Code, and it doesn't appear to be any more flexible.

Maybe someone has an extension, but I doubt it. And this is too core to my development experience to trust to something as ephemeral as an extension. And emacs has already been doing it for 30 years.

2. I use emacs in the terminal, whether on my desktop or ssh'd into AWS.

The development experience is 100% seamless. Being able to work remotely on any server with my exact same developer experience is huge for me. I don't have to have a mirror copy of the files and do any syncing between edits. I can use all the project management, file browsing, and directory searching features built into emacs with no problem. I'm always at home.

The last thing I'll mention is that, contrary to the person having doubts in the linked article, I'm not an emacs power user. Currently I use an almost-stock spacemacs install, not even in evil-mode, and I've barely explored it. The basic emacs features I learned in the first couple months of using emacs give me more than anything I've found.

I will say that if I made a whole career out of Java or .Net development, and if versatility wasn't that important, an IDE tailored to those environments would have some polish that's hard to ignore. But if I knew I was missing the foregoing, it would hurt a lot every day.

gumby2• 5 years ago

I find the overhead of selecting a pop up, having it appear, often then using the mouse to select something, then pressing do is just clumsy compared to the low overhead command structure of Emacs. Search is a primary cursor move operation, for example.

kqr4• 5 years ago

The sticking point for me is that if I discover some functionality is missing, I can add it to Emacs on the fly with often just a few (1--25) lines of Lisp.

So there's several tiers to this convenience:

1. Does it do the obviously important things out of the box, or with easily installed add-ons? For most editors, this is yes.

2. Does it do the little things out of the box, or with easily installed add-ons? For some editors, this is yes.

3. If none of the above, can you create the thing you need as an add-on without breaking your step, almost as part of what you were already doing? To get to this point it takes a very dynamic system like Emacs.

jeffyang2• 5 years ago

The thing with Emacs is that sort-lines is a string you can copy and paste into a buffer, whereas in Visual Studio it's a command that you have to execute.

Disclaimer: I don't know Visual Studio that well. Still, I suspect what I'm writing is true.

I wrote about this in a separate comment: https://news.ycombinator.com/item?id=28104243

bsder• 5 years ago

As an emacs user, I would say that emacs really didn't have competition until VSCode and modern programming languages.

For example, everybody was kind of 80-90% on syntax highlighting. Some editors and IDEs were a little better at one language than others, but most weren't that great and had all manner of weird edge cases. And, if you wrote a new language, good luck because you had to write a syntax highlighter for it in both emacs and vim to get traction.

And then VSCode came along with the Language Server Protocol. Suddenly, you only needed to write a well-constrained plugin to get your syntax highlighting to about 80%. That was okay.

But the modern languages learned from the failures of C and C++ and designed themselves to be parsed quickly and accurately. So, now your LSP syntax highlighting could go to roughly 99% accuracy on VSCode. And the highlighters were incremental. Suddenly there was a genuine advantage to using something other than emacs.

And this is before we get to things like a debugger that works, etc. I've used all the IDE's, but VSCode is the first one to pry emacs from under my fingers.

And for people who like to complain about VSCode and Electron bloat (a valid complaint), I'd like to point you to some of the old nicknames from the emacs vs vi religious wars (Eight Megabytes And Constantly Swapping springs to mind ...) Bloat simply isn't an argument for most people.

anyfoo9• 5 years ago

I agree that lsp is a necessity nowadays, and I was almost willing and close to give up emacs. And then emacs got proper lsp support (even in at least two forms, lip-mode and eglot), and now I'm happy.

lliamander• 5 years ago

Is there a definitive Emacs key-binding plug-in for VSCode? I've tried several in the past and none seemed quite right.

IntelliJ, on the other hand, has great support for emacs key-bindings.

Frondo• 5 years ago

One other thing about VSCode being an Electron app -- it is by far the snappiest and most responsive and least bad memory-wise Electron app I've used. This isn't like Slack or Discord. It's like magic what they've built on Electron, one of these days I'll dig into the code to see how they did it.

b3morales3• 5 years ago

your LSP syntax highlighting could go to roughly 99% accuracy on VSCode.

? LSP, the protocol, doesn't (yet) have a syntax highlighting aspect.

And doesn't VSCode still use TextMate grammars? https://code.visualstudio.com/api/language-extensions/syntax...

impendia• 5 years ago

What is your criticism of LaTeX?

I am a research mathematician, and I and essentially all my colleagues are LaTeX users. To me it feels like the correct tool for the job; the only widespread criticism I've heard is that it doesn't produce documents accessible to the blind. (And I've heard that work on this is in process.)

I tend to be unsympathetic to criticism that a tool is "outdated"; if a tool is right for the job, why change it? But I want to keep an open mind -- what would you like to see in LaTeX's place?

andi9993• 5 years ago

My pick with Latex is: Error messages look to me as complicated as C++ template errors, packages sometimes don't work well together, a lot of boilerplate is usually needed, and I feel somehow the Syntax needs too many keystrokes, like why not make {} for sub and superscript optional and everything until the next space character is sub or superscripted (and not only one character). Also writing {\rm text} feels wrong. Shdnd it be \rm {text} and maybe instead one shd be able to use $ in an equation block to get to a non italic font.

While markdown is not advanced enough, I feel the making it easier for the user to use is the right modern approach, from which maybe a full system could be designed.

Also figure placement should allow more fine-tuning (not sure how, and yes this is against the original spirit)

GiovanniP2• 5 years ago

what would you like to see in LaTeX's place?

a document preparation system in which

- it is easy to read what you wrote (without having to switch between the editor and the typeset text)

- customization is done with a sensible programming language

Tainnor2• 5 years ago

I'm a heavy LaTeX user, but LaTeX manages to be simultaneously amazing and completely insane.

Let's get started with some negatives (the positive are well known):

- Recompilations needed. Can be mitigated by latexmk, but still.

- Choice of latex, pdflatex, xelatex, lualatex ... and documents compiled with one may or may not compile with another

- packages that are incompatible with each other in odd ways

- when you encounter an error you have to enter "X". if you're using latexmk, you have to enter "X" multiple times

- math commands are not structure-based but presentation based, despite LaTeX's (otherwise well executed) posturing of separating content from styling. If you want to change the alignment of your equations or the size of the integrals sign or just slightly tweak the appearance of the | sign in {x^2 | x € R }, be prepared for a lot of rewriting (some of this can be alleviated by defining new commands, but I don't know how many people actually do that)

- Math LaTeX input is basically unparseable in the sense that it is not really possible to take some latex math code and convert it into some actual meaningful structure (this is a corollary of the above point). Given the ubiquity of LaTeX-style math even in a range of other contexts (e.g. KaTeX), this is a bit of an issue. It's possible to do a best effort implementation that sort-of works, but it's always gonna come up short

- Error messages: "Missing $", thanks

- Outdated defaults. Unicode should just work by default.

I think I could go on, but you get the point.

zibzab2• 5 years ago

Here is an idea: Stop adding crazy marcos and customization and use it like an editor instead of an OS.

I understand this is a very controversial idea, but I have learned that since I'm switching machines and using remote boxes all the time, customising everything 100% to my liking is neither possible or worth the effort.

This of course requires the emacs team to make the barebone emacs a little bit more functional. Otherwise we can simply use uemacs or mg and benefit from faster startup and lower footprint.

rgrmrts• 5 years ago

I use emacs to interact with other machines or remote boxes. All of my customizations and preferences are magically applied to remote files. For example, I wanted to edit a file in the Hetzner rescue image and I just opened it using tramp and wrote my changes.

If I were to use emacs as just an editor, I’d probably stick with sublime or vscode or something. The same UX across many common workflows is precisely why I prefer emacs.

dangirsh• 5 years ago

What do you suspect the "macs" is short for?

bigbillheck2• 5 years ago

"Megabytes And Constantly Swapping".

slapfrog• 5 years ago

I revisit my emacs config once every year or so, but otherwise I leave it along and focus on using emacs instead of tweaking emacs. From what I've heard, some emacs users seem to get addicted to tweaking emacs, so much so that it distracts them from their real work. But that's just not something I can relate to myself, nor is it something I've witnessed from my emacs-using coworkers and friends. I've also perceived an uptick in hand-wringing about such emacs-tweaking in the past few years, seeming to correlate with an uptick in handwringing against GPL licenses and GNU in general, and I wonder if agitation with RMS has something to do with it.

sumtechguy• 5 years ago

I used to customize pretty much all of my tools and OSs like that. If there was a control/config for it I was tweaking it. Now I leave them alone. I jump between so many boxes now it is not worth it. Except for 'hide file extensions' I tweak that one every time :)

natrys• 5 years ago

Why would switching machines prove to be a hindrance to customisation? The configuration files are still nothing but source code text, which could be version controlled and deployed anywhere with little automation, it's really no different from deploying software that you are writing.

Customising everything 100% to my liking is not only possible, but also takes very minimal effort. Detect if it's home desktop, or work laptop, or something completely new, and do something accordingly, what is complicated about a conditional block? Elisp is a normal language with all normal logical abstractions available.

I concede about remote box, I mostly work over ssh in terminal too. Except Tramp is also like really easy. To the point that if I need to use git, I almost always use local Magit over Tramp. This way I am not compromising, Magit is best in its class kind of tool, and I don't even need to install Emacs in remote box to use that.

ta_emacss3• 5 years ago

first time i used tramp it felt like magic, i thought in this age where connecting multiple nodes, vpns, virtual-systems so common that everyone in interent-business would use tramp. but all i could see was people wrestling with ssh, scp, tmux/screen, lots of terminals...

bigbillheck2• 5 years ago

I've been an emacs user for, oh god, almost thirty years now and I completely agree.

If I'm gong to be using a particular account for a while I'll set a few variables (show-paren-mode is the big one) but otherwise it's pretty much stock.

ta_emacss3• 5 years ago

i just copy the .dot file and launch emacs. in a few minutes without touching anything i have the same environment.

zibzab2• 5 years ago

Yeah, that's me 3-4 years ago.

Then I ran emacs on a new machine for months before realising my .emacs refused to load correctly because I had not installed the correct fonts and cscope. So dot files are not foolproof.

(Throwaway account to discuss emacs? Do you live in a vim-only country?)

BeetleB5• 5 years ago

Here is an idea: Stop adding crazy marcos and customization and use it like an editor instead of an OS.

That assumes that using it as an editor is the main reason we use it.

Koshkin5• 5 years ago

Indeed:

http://www.informatimago.com/linux/emacs-on-user-mode-linux....

Koshkin5• 5 years ago

use it like an editor instead of an OS

But, but... I have heard people say that "emacs is a fine operating system in need of a good editor..."

playcache2• 5 years ago

This is why I don't bother with emacs, I just don't have the time to sink in the first place. Now that I have a young family and hobbies outside of work, I don't have the time to spend hours fixing and tinkering a setup or learning an already opinionated set up like spacemacs etc. I just use an IDE which is already set up with good defaults and I have a well settled vim config for driving remote machines or changing something on my main PC. I also cannot get on with the shells available in emacs. They feel slow and have to many quirks and I don't get that with vscode / intellij.

blacktriangle2• 5 years ago

Emacs gives you back what you put into it. There's absolutely nothing wrong with using it at a very basic level, and getting to that point takes minimal time. There's a 15 minute interactive tutorial linked from the start screen at which point you're fully able to get work done. You can then reach for other goodies like Org, Magit, various interactive shells, tetris, whenever you want/need. I probably used Emacs for 5 years straight before installing a single package other than color themes.

To me the pitch for Emacs is it's the same overall platform now as it has been for decades and will probably continue to be. While all my colleagues were jumping from BBEdit to TextMate to Sublime to Atom and now VSCode, I've just been sitting here editing text.

na853• 5 years ago

I say this as a 10+-year emacs user:

The "15 minute tutorial" is emblematic of everything wrong with emacs and its community.

Just make CUA-compliant keybinds the default, and you'd draw in so many more users.

The ideal tool is one that you can start using right away, and incrementally dig into as you descend into madness/poweruserdom. The idea of having to waste 15 minutes before you can even start working in emacs is awful.

I used emacs for quite a few years only knowing how to save/open files and undo, because I refused to go through a tutorial that looks like it's stuck in 1970. I'm sure many others just give up and use vscode.

iLemming5• 5 years ago

This is why I don't bother with emacs, I just don't have the time to sink in the first place

I use Emacs specifically because it's a huge time saver for me. Pretty much almost every day, I find something repetitive that I don't want to do manually.

- Need a link on GitHub for the current line in code?

- What if the same line but in a different branch?

- What if you're already browsing code on GitHub and want to check out this specific file (in specific commit) but in your IDE?

- I want to send a YouTube link to my colleague, but I don't want to separately copy and paste, first the link, and then its description; Emacs helps me do that instantly.

- I have two pieces of code or text. I want to diff these snippets quickly.

- I am not a native English speaker; how can I quickly translate any word or a phrase and even hear its pronunciation?

- How can I quickly find a definition of a word or its synonyms?

- I use and love Grammarly, but I don't want to use their stupid editor. And I don't want to copy and paste the text all the time; I perform Grammarly checks while in Emacs.

- I want to find packages on npm, maven, clojars, etc, without opening the browser and typing.

- I want to select a piece of code and search for it on GitHub, and Emacs would make sure the language is properly set.

- I want to convert between different units quickly, or generate UUIDs, or validate JSON. Even when I'm offline.

- I want to find (recursively) all the files that e.g., bigger than a certain size and were created between April and June and rename them all or delete them.

- I'm going through my notes and see that ticket #1346 is done, and I want to trigger the state change without ever going to Jira, GitHub, etc.

And there are many, many examples of things like that. And sometimes it's not even about the time. It is far more enjoyable that way. It feels empowering. You don't have to think about some trivial things and can focus on what's important.

There's not a single [other] tool that makes me feel like I'm in so much control. And for a software developer is very important to feel being in control. Or it starts slipping into a burnout.

playcache2• 5 years ago

None of those are honestly compelling enough for me to again spend the set up time. I must send a YouTube link at most once a week if that and my IDE does all of the github interactions you list already, with a decent debugger on top. I could generate uuid's with two lines of python.

tome2• 5 years ago

:-o Can you share links to the packages you use to do these things?

neolog5• 5 years ago

the shells available in emacs. They feel slow

Emacs' eshell is the fastest shell out there according to one metric.

https://danluu.com/term-latency/

danShumway4• 5 years ago

It does kind of bother me that Org doesn't have a particularly good formal spec.

There are a ton of parsers out there, which is great, but there is no Emacs-independent set of tests you can run against a parser to figure out if it's compliant. Ultimately, the Org format is what Emacs says it is, and everyone else just tries to play catch-up.

I feel like this is a little bit of a missed opportunity. I use Emacs because I think it's (for me) the best editor that exists today, and it's likely to continue to be the single best editor that exists (for my needs) in the near-to-long-term future. That doesn't mean I'm necessarily pleased about how much Emacs tends to suck features into itself and how hard it is to get them out.

I don't like that the "canonical" version of Org-mode is Emacs dependent. I don't like that when I manage my life through Org-Agenda it becomes needlessly hard to work with other tools unless I sit down and find a partially functioning Org parser on Github that may or may not be abandoned. Yes, Org is plain text, but being plain text isn't good enough, it also needs to be easily parseable into a consistent AST or formal data structure on multiple platforms. I don't like that when I write a tool in Emacs Lisp that I can't run it headlessly anymore, and that it now requires a massive pile of dependencies to run.

The Tern language server was a good development on this front, it's good for language formatting tools to be separate from editors. I wish more parts of Emacs would work that way. But it's not so much of a problem that I'm willing to give up Emacs to in order to cobble together a system that adheres more to the Unix philosophy of being more composable. The lock-in effect is definitely real, it's just that Emacs also happens to be good enough right now that I don't have anything else I particularly want to move to, which makes the lock-in a lot less annoying.

I'd move off of Emacs if I felt like any of the other editors were better, but I don't, for me none of them come even close. Emacs has a huge community and a huge featureset that dwarfs other editors, and it also has this core of flexibility and transparency and extensibility that I feel even "configurable" editors like Visual Studio and Atom haven't really caught up with. But importantly, me saying that Emacs is the best editor around is not quite the same thing as me saying that Emacs is good.

I don't have any regrets picking up Emacs, at all, it was a great choice and it's paid off tremendously, and I think it'll continue to pay off in the future. But I do wish there was a better editor out there.

neolog5• 5 years ago

What is the advantage of plain text? Other than that Emacs is bad at editing other file types.

danShumway4• 5 years ago

The ability to hand-parse/edit outside of Emacs, lower risk of data corruption, the ability to read the data visually even if printed or displayed raw. It's nice to be able to `cat` an org file to a terminal or `grep` from the command line, and if a file gets corrupted or messed up it's pretty easy to recover the data.

So basically: transparency, flexibility, portability.

Plain text is great, it's just not enough on its own. Ideally, Org should be both plain text and rigorously defined with a language-neutral set of parser rules that allow it to be transformed into some kind of JSON or similar data structure so that other programs can more easily read and write it.

Org-mode succeeds very well at the plain text, but (imo) kinda fails pretty bad at the "rigorously defined and easily parseable" part.

Increasingly, I think that both are important -- I'm finding that hand-editing Org files and programmatically editing them are both things that I want to be able to do.

tgbugs• 5 years ago

It does kind of bother me that Org doesn't have a particularly good formal spec.

We're working on it [0, 1].

0. https://orgmode.org/list/CA+G3_POBAB1QX1Zv8q9sjFh4KHUHVmaNXp... 1. https://github.com/tgbugs/laundry/tree/next

danShumway4• 5 years ago

Nice, thanks for linking!

I'm excited to see stuff like this, I think a formal grammar would open a lot of doors for more tools to get built around the format.

yewenjie• 5 years ago

While org-mode parsers are being written in many languages, what is the best currently available alternative to the org-element API in any other language than Emacs Lisp?

lgrapenthin• 5 years ago

I am also a 10+ year GNU Emacs user. I haven't customized it beyond font size and a few settings. I even use the default theme. Other users seem to go crazy and try to make it into a spaceship. Then they claim that it takes a lot of time to customize it. It mainly is very different to operate from all programs and window managers that we are used to these days, and people perceive this as a wrong and try to "fix" it with confusing "starter packs". In reality, its meta features and comprehensive reference documentation make it a closed environment that is very pleasant to navigate.

cpach2• 5 years ago

I agree – Plain Emacs works very well. My current ~/.emacs is 27 lines (comments included).

timbaboon• 5 years ago

Totally with you on this. I’ve added some stuff for coding in Python, but really minimal changes. 10+ years later I’m still happy and use it daily.

_y5hn• 5 years ago

While making notes about config & tips for various linux software, the bar in my book is actually wether you can live with the defaults and how little tweaking something needs.

It's the exact opposite of sinking costs, and rather focus on "good enough" because you often end up switching or changing stuff soon enough anyways.

So more like how fast can you just go from default install and choose the sanest defaults and not spend time on tweaks / unix pr0n. Install what you need just in time etc.

It makes even more sense when using defaults on several remote systems, kind of like just using vi.

BeetleB5• 5 years ago

If it works for you, that's great. However, for me it's the analog of "I never configured my shell to have TAB autocompletion." in the old days. If you can live without it, great. But for many, turning it on makes it worth it.

tech_tuna• 5 years ago

Same here, I'm mostly sticking with it because of muscle memory at this point, definitely not because of RMS.

I may switch over to a new school UI based editor one of these days. I used VSCode for a bit but got sick of it.

Like OP, I really wouldn't recommend emacs to anyone just learning.

2pEXgD0fZ5cF• 5 years ago

I can confirm this. Been using emacs for ~7 years now and my config keeps getting smaller and smaller, not bigger. While I still have my beloved config file, I'm confident that I'd be able to reproduce it within a few minutes from scratch, most of my customizations in there do not affect my workflow anymore.

On one of my machines I'm just using default emacs. Maybe going from all the customizations back to vanilla emacs was part of me "learning emacs" but I think I'd tell my past self that I don't actually have to read up as much as I did and that emacs and vim aren't as scary as many people tried to make me believe.

In the end learning to do the same old things as with other editors doesn't really take more than going through the tutorial, most people will already work as fast or faster by then, before I took the dive into vim and emacs I was very a "mouse and arrow keys" guy when it came to text navigation and editing.

There are of course many things that could be improved when it comes to emacs defaults, I wish the devs were more open to update some of the low hanging fruits.

itronitron• 5 years ago

I think the lock-in effect is driven by a desire to retain (and easily access) memory of prior experiences (emails sent, bugs fixed, etc.) and not based on 'investment made'

The sunk-cost fallacy doesn't really apply here because the time spent using emacs in the future would be spent on any tool that was chosen instead.

pkulak2• 5 years ago

So, that's NOT the sunk cost fallacy. If you are still getting benefit from the cost, it's not sunk*. This is just not wanting to invest time into a new system while you're still productive in the current system.

A sunk cost would be like, "Well, I spent $100 on this steak, so I'm going to finish it, even though the next bite may make me vomit." In that case, you paid for the steak, it cannot be returned half eaten, and eating more of it will bring you zero benefit, so the rational behavior is to not eat more of it.

EDIT: It's not a "fallacy". It is still a sunk cost. My mistake.

Jtsummers5• 5 years ago

A cost is a "sunk cost" when it's already been spent and can't be recovered. The time invested into learning and configuring emacs is a sunk cost.

The fallacy is in persisting with it when other tools may be better, choosing to persist because of the time invested. Continuing with emacs because of that time investment even when there are better tools (for some part of the work at least) is an example of the sunk cost fallacy. Now, that doesn't mean that the tradeoffs can't be considered where someone determines that emacs is better to continue with for them in their particular situation (regardless of the sunk cost of time spent on it).

pkulak2• 5 years ago

You defined a sunk cost properly, but that's not the same as the "sunk cost fallacy".

To abuse my original example some more, when you are hungry, the steak is still a sunk cost, but it's obviously not a "fallacy" to eat it then.

EDIT: Just realized what you are responding to. I'll edit my post. Thank you!

Barrin92• 5 years ago

I think it's an overused concept because it's exemplary of a larger cultural issue. People praise 'openness' and optionality, (not just in software tools), and are skeptical about any form of commitment simply because it closes off some paths.

In programming it comes up a lot with opinionated programming languages, IDEs etc. Environments like Emacs with their idiosyncrasies and age tend to be disregarded because they aren't all things to all people.

bborud5• 5 years ago

I think a good simile would be that using Emacs is a bit like owning an old car. It breaks down more often, and when it does, your Google search results for results lead you to crusty websites that are skinny on solutions that would be applicable for you.

So you end up lying to the floor with parts strewn around you more often than you'd like to. And what you really want to do is go places in your car (ha...ha....ha) than be a mechanic.

I've programmed Go using Emacs for 4-5 years (and I've used Emacs for 30+ years). To be frank: my old Alfa Romeo from the 1980s breaks down far less often than the Go tooling in Emacs. Or the Java tooling before it for that matter.

It's not that I no longer like Emacs. It is just that I like programming more than I like doing redneck-repairs of Emacs.

samatman2• 5 years ago

I don't know whether or not it's a perfect translation, but from his description I would offer "tunnel vision" for Scheuklappen-Effekt.

Emacs is a truly remarkable program, which has painted itself into a corner. There are just too many locked-in architectural decisions to make a complete list, and it's good enough at being what it is to suck up all the oxygen needed to build another text editor which could overcome the 40+ year head start it has on anything else.

Org-mode is the perfect example of what's right and what's wrong with Emacs. It's great, and it's also a weird ad-hoc format, most of what it does shouldn't live in an editor, and if you want to really use it anywhere but inside emacs, good luck to you. Remarkably powerful for a TODO list which evolved sentience!

I'm heavily invested in doing something about all this, but since none of that code is public yet, I should probably stop faffing about on HN and knock off another issue before the weekend arrives...

asciimov• 5 years ago

My first thought for the Scheuklappen-Effekt was blinders. Blinders are used to prevent horses from seeing sideways.

Turns out, blinders are also called blinkers.

CRConrad4• 5 years ago

My first thought for the Scheuklappen-Effekt was blinders. Blinders are used to prevent horses from seeing sideways.

Yup, that's what Scheu-klappen means. "Shy-flaps", to use the English cognates: Flaps you put before (beside) the horse's eyes, to stop it shying away whenever it gets spooked by something it sees off to the side.

Turns out, blinders are also called blinkers.

Funny how the adjectival form (gerund?) is apparently only used on the latter variant: I've only ever seen "that's a blinkered view", never "blindered".

na853• 5 years ago

if you want to really use it [org-mode] anywhere but inside emacs, good luck to you

I wonder if org could be ported to provide a language server via lsp, and in so doing become cross-platform?

Org really is a superior markup format.

Kinrany• 5 years ago

Can it be used without elisp?

xenodium• 5 years ago

I'm heavily invested in doing something about all this, but since none of that code is public yet

Do you mean org or other areas of Emacs?

I slowly adopted org for a few personal notes, which turned into a blog of sorts over time (https://xenodium.com). Initially, I would just export and host the one-pager [1]. This was handy for viewing on mobile, but started slowing down on mobile Safari. I knew enough elisp to get me by, so I added my own mods to split the HTML export into multiple files. Then I needed some rss, so I glued on a handy package… buts that’s the thing, with some elisp glue you can bend the heck out of anything to make it do what you need. Can be quite satisfying.

My org usage continued on to babel… wouldn’t it be neat if I could get it to show SwiftUI layouts? Turns out, you can glue your way into that too [2].

Speaking of babel, I didn’t want to type the block boilerplate for them anymore, so yeah… a bit more elisp glue and got myself my own company completion [3].

I read Atomic Habits over lockdown and was keen to start tracking. Org mode supports habit tracking… but, it’s just not convenient enough to open up your laptop to track every habit. This time around, I couldn’t throw elisp at the problem, so I brought a little org over to my iPhone and built a native app https://flathabits.com, which syncs with Emacs over cloud.

I’m enjoying org on my iPhone, so I think I’ll bring a bit more task management over to it [4].

For me, the journey has been half the fun.

[1] The notes/blog is still a single org file today https://raw.githubusercontent.com/xenodium/xenodium.github.i... [2] https://xenodium.com/previewing-swiftui-layouts-in-emacs-rev... [3] https://xenodium.com/emacs-org-block-completion-on-melpa [4] https://twitter.com/xenodium/status/1423397014646177792?s=21

edit: typos

komali22• 5 years ago

FYI for anyone looking for a good android org app, I've been using and enjoying Orgzly. [1] Looks like it has a totally different UX than flathabits - I'm not sure how xenodium is managing habits in org. Orgzly mostly is a notebook (org file) and headline/todo/deadline property organizing tool.

[1] http://www.orgzly.com/

anyfoo9• 5 years ago

As a German person fully immersed in an English-speaking country (the US) for close to a decade now, I agree that "tunnel vision" is at least close enough in meaning.

kqr4• 5 years ago

Thinking of Org as "living in an editor" is the mental mistake that leads to that confusion.

Org is a full blown task manager and note taking application, written for the Emacs platform.

Emacs is a platform much like the JVM. Someone happened to write Minecraft for the JVM, and someone happened to write Org for the Emacs platform.

People have written editors for Emacs (evil-mode is one I like) just as people have written search engines for the JVM (I use ElasticSearch at work.) But you shouldn't say org "lives in an editor" any more than you would say "Minecraft lives in a search engine". They're just two different applications built on the same platform.

Granted, the Org application reuses much more code and integrates better with the editors available for Emacs, making the comparison a bit odd, but I'm sure there are examples like that for the JVM too.

samatman2• 5 years ago

I understand what you're saying, but I'm not making a mental mistake, and I'm not confused.

I'm working on something which takes the -mode out of org and builds something meaningfully similar which isn't wedded to emacs.

But you shouldn't say org "lives in an editor"

Except it does. If you want to use the org format in any sort of full-fledged way, you're going to be doing it in Emacs.

Which, ok, it's a platform. But it's a platform which is a text editor, comparing it to the JVM only goes so far. The JVM is a bytecode interpreter, Emacs is an editor which has a bytecode interpreter. Yes, it's possible to run it headless, no, it isn't pleasant or fast, it's not designed for this, people don't, good luck embedding it in something else, and so on and so forth.

You seem to be taking the old joke "Emacs is a great operating system which just needs a good text editor" a bit too seriously here.

Org-mode is a bunch of things, and one of those things is a text format. That text format is too closely tied to emacs, it's simply hopeless to reimplement it in anything else. If you don't believe me, take a look at the spreadsheet functionality!

Which is a pity, because another one of the things Org is, is an intriguing and powerful approach to literate programming. One which I expect would be much more attractive if it didn't require one to use Emacs to employ it.

You're welcome to integrate headless emacs into your CI if you're so committed to thinking of it as a "platform much like the JVM". I've found it simpler to take as many ideas from org-mode as possible, and just build from scratch.

But I'm not ready to release my code yet, and until I am, I should spend more time writing it, and less time talking about it on the orange website.

AlbertCory• 5 years ago

When I was at Oracle in the 90s, I was constantly having to sit down at someone else's machine (this was before covid, of course). And there were zillions of Unix versions, not just Linux. You couldn't even count on emacs being installed, but I drew the line at learning vi, other than :q! If they'd been editing, I'd ask them to save it.

What that meant is, whatever customizations I had on my own machine were not available. I had to learn to work with the defaults. This is liberating. I recommend it.

iso1210• 5 years ago

I agree, I've used vim for 20 years with very little in my home vimrc file. Indeed I didn't even have a vimrc file until Vim 8 changed a bunch of defaults to make things worse, which almost made me quit, until I realised the alternative was nano.

abzug• 5 years ago

The alternative could be vi/nvi.

_huayra_5• 5 years ago

I wish there was a solid competitor to Emacs, but the thing that keeps me coming back is that I have the time to tinker with it a lot and the community is great. Vim and Vscode have some valiant maintainers of projects, but from what I've seen it's nothing compared to the big Emacs projects, especially Org mode for which I haven't found a reasonable alternative in Vscode.

However, I don't like fact that most of the editor is a single event loop. This is not a big deal most of the time, but if, say, you're using magit on a large repo and a command finishes and the buffer must refresh, you're gonna wait there for several seconds being unable to do anything else (no switching to other buffers, much less continuing to use Magit while it is updated asynchronously). (btw if I'm wrong about this, for the long of god enlighten me!)

elisp is a bit quirky and dated, and very hard to figure out incrementally. I am still at the place of "copy-paste from other smart people's configs" because I have not really sunk the time to gain a deep understanding of the language; the lack of types and a somewhat tricky (although functional) debugger prevents many of the things about the language from being elucidated, especially because the powerful macros.

However, I don't really know what an effective alternative would be besides perhaps Javascript (which I'm also not a fan of) or Python.

rich_sasha• 5 years ago

I have found it very difficult to pickup elisp, but the latest concerted effort worked. I found learning it to be a very fulfilling experience.

_huayra_5• 5 years ago

Was there any resource that help you get over the understanding hurdle?

Jtsummers5• 5 years ago

For what it's worth, Emacs Lisp clicked for me properly when I learned Common Lisp and then threw out what I knew and treated it as a cousin language (which it is) with some different design elements and read the documentation.

However, learning two languages to learn one is a big ask, I just had no choice on CL thanks to a college course (and have no regrets, easily my favorite language to program in even if I never get to use it professionally; most of my classmates would vigorously disagree).

clipradiowallet• 5 years ago

I admire emacs folks, for the same reason I'm a 15-20 year vim person. If someone uses emacs regularly - they most likely know what they are doing, and we can get along on that basis. I appreciate the authors introspection and honesty about using it though, was a good read.

ta_emacss3• 5 years ago

when you are looking for a tool as a programmer, the question you should be asking is not 'is it complex?', the question always is 'is it worth it?'. emacs is the only tool in existence i can confidently say yes, every bit. as a programmer you should be using emacs.

i have used visual-studio for 8 years then vim for at least 5, emacs was always there taunting me. after 'evil' i had no reason to avoid it and i wish someone told me to use it the day when i started coding. this is not vim-vs-emacs, this is not ide-wars, they are for language-lawyers and influencers spewing bullshit for internet points.

magit, tramp, org-mode, evil... every one of them are free, orthogonal to rest of the emacs-system, supported on every os.

but emacs too comes with a curse, just like lisp. after you get used to it, there is no going back. everything is going to feel inferior.

dleslie3• 5 years ago

Every so often I would start my Emacs config over from scratch. I might port over some old defuns from the previous, eventually, but I would always endeavour to try the latest tools and best language configurations. Consistently I found myself using Emacs and sticking to it because it offered the best developer experience.

And then came Microsoft's Language Server Protocol. Emacs was late to adopt it, and still has generally spotty support for it. This has caused me to stop using it, almost altogether, as Emacs is objectively inferior because of its poor support for LSP.

Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth?

And then when they do work, the packages often drift and break. I had C# working quite well with lsp-mode and OmniSharp, and then I updated Emacs. Without any changes to my configuration the experience has become atrociously slow, and apparently this is due to a known and recently introduced bug in Emacs support for C-style modes.

I strongly recommend other Emacs users shake the sunk cost fallacy and just try the competitors.

BeetleB5• 5 years ago

This makes sense primarily if you assume people who stick to Emacs do so because of its SW development capabilities.

As a person who hangs out amongst Emacs communities, this profile is not the norm.

dleslie3• 5 years ago

I used Emacs for software development and git interfacing.

I tried organizing my knowledge with org-roam. I tried maintaining org todo lists. I tried having an active org-agenda. I tried...

But what I do more than eight hours a day, every week day, is read, write and debug code. Emacs was once the best, it is now not so great.

I've been using Emacs for over two decades, now. It's painful that it fell behind so quickly.

kazoomonger• 5 years ago

I actually just started using emacs recently, specifically doom emacs. It works smoothly out of the box and is super easy to enable LSP for.

I'm not going to try to convince anybody to switch, but if you ever try emacs again, would definitely recommend trying out doom emacs.

forty• 5 years ago

Same. I actually switched from VSCode, and I like it much better :)

nine_k• 5 years ago

If only VSCode had sane buffer control, and the idea of buffers.

I use VSCode with Emacs key bindings for certain development. The lack of uniformity inconveniences me a lot.

But indeed, VSCode is the closest thing to Emacs in its spirit.

Koshkin5• 5 years ago

JavaScript: "Lisp in C's clothing"

https://www.crockford.com/javascript/javascript.html

krylon• 5 years ago

I haven't given them a close look, but there is a project called "zile" that - AFAIU - aims to create an emacs-like editor using Lua instead of Lisp. Which sounds amazing to me.

Also, there's another project to replace emacs' lisp interpreter / bytecode VM with GNU Guile, which started out as an embeddable Scheme interpreter, but apparently these days it is a JIT compiler that supports Scheme, Javascript, and elisp. Which means Guile-Emacs could absorb all of that elisp code without a problem, probably make it run faster, too, but also open the door for people that don't feel comfortable with elisp. More importantly, maybe, this project could bring people from different language communities together.

Again, I have not spent much time looking into the project, so consider all of what I'm writing hearsay. But things are happening.

PaulDavisThe1st3• 5 years ago

Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth?

If you actually think that what VSCode can do here is remotely equivalent to what Emacs can do after customization, then I suspect you don't really understand Emacs.

Yes, VSCode does an excellent job getting you to 80%-90% of where you want to be. But because of the lack of a deep extension language (or to be fair to Emacs, an extensible implementation language), VSCode will make it very hard to get to precisely where you want to be.

Maybe that's OK for a lot of people. But those of us who have used Emacs for quite some time are quite attached to that "final 10-20%", and you can keep your language servers and "detecting my intent" and just leave us be with the way we do things.

dleslie3• 5 years ago

For that last 10% of esoteric power, _I still launch Emacs_.

Eventually VSCode will be able to do such things, too.

saulrh• 5 years ago

It's not even that - My problem is that I depend on emacs for the first 50% of my workflow, not the last 50%. For example, I use key chords for every common operation - ;h ;j k; l; move between panes, xz invokes M-x, kj brings up the buffer list, z\ and z- split panes, etc. I barely go ten seconds without using one of occur, change-inner, a 500-element kill ring, consult-yank-pop, tramp, magit, etc. Emacs works so well for me not because it has crazy extensions, but because its extensibility goes so deep that you can bring the crazy extensions deep into the tightest loops in your interaction with the editor where you can gain the greatest benefits.

axiosgunnar• 5 years ago

VSCode allows you to write in Javascript what Emacs allows you to write in elisp. What's missing?

gumby2• 5 years ago

The flexibility is a distraction. I've been using Emacs for over 40 years and have a very small init file which is gets modified once or twice a year at most -- most of the time not at all.

It's simply a powerful tool. Not the only one I use, but certainly it's easier to type to it than it is to type, say, to the input box here in my browser (even though it has at least some emacs commands built in).

submeta• 5 years ago

I loved tinkering with Emacs, reading through code of packages like org-ql, writing my own helper functions in Elisp, migrating every tool I use to Emacs (Editors, IDEs, file explorers, diff tools, dedicated markdown editors, and many more). At some point I realized I was spending more time configuring Emacs instead of doing work. I have a tinkering-vs-doing chart in my mind where both activities are on opposite sides. With a limited amount of time per day, I was on one extreme side of this diagram (tinkering a lot, getting not much done).

When I took over new responsibilities, I could not justiy this time anymore. I had to move quickly and deliver results. That‘s when I went back to dedicated tools (Ulysses app for writing markdown, Notion.so as a personal wiki (previously org mode), Logseq for personal notes, VSCode and PyCharm as an excellent Python IDE, etc.

Now other people work intensely to perfect those dedicated tools. And I can solely focus at the task in front of me. With this shift in focus my productivity increased immensely.

Now I still use Emacs. For text editing purposes. And I use macros a lot to transform text. But that‘s about it.

ashton3142• 5 years ago

Perhaps an overlooked aspect of Emacs that makes it so attractive is for those of us with some kind of RSI or other accessibility issue that makes customizability a must. I'll admit, I haven't used other editors all that much, but Emacs' keyboard-first approach makes it a much easier tool for me to use than other editors that require some kind of mouse interaction for certain aspects. I've been able to customize Emacs to have more ergonomic keybindings (e.g. I use evil-mode and evil-leader for a lot of common-use functions) and my RSI has never been better!

Granted, some of that RSI was due to how I had Emacs set up before. Not all of it, mind you, just some. I have repented of my non-ergonomic ways.

iLemming5• 5 years ago

I said this before in regards to choosing Emacs or something else. I'll repeat it here again.

There are always multiple paths to get something done. Some people prefer automation. Having "a bucket of bolts and nuts" makes it possible to hack your way around things.

Some people like Ferrari. But for many - the utilitarian value of that car is infinitesimal. Instead, they'd rather have exactly what can be described as "a bucket of bolts and nuts". They cannot go camping in a Ferrari; or take their beloved bullmastiff to a vet in it; nobody drives a Ferrari to help their friends to move furniture.

Emacs is "a bucket of bolts and nuts" and not something akin to a shiny, expensive but not very useful car. It's more like a transformer - you can build a pickup truck, a camper, an ambulance, or a race car. And that's what makes it a fantastic tool for some people and an immense pain for many others.

Some people like Ferrari. And there is nothing wrong with that.

anothernewdude• 5 years ago

I have been keen to find an alternative editor.

But it needs to be as customisable and scriptable as Emacs is. And nothing has come close so far.

(Having an editor use electron is a non-starter)

SirensOfTitan• 5 years ago

I maintained my own emacs config for a while and ended up moving to Doom mainly for a more thoughtful shortcut config. I spend a couple hours every once in a while tinkering for fun (and to fix issues with my workflow).

Sure, you may be tinkering more in emacs and working less, but free play is an integral part of growing skills, as is feeling a sense of joy when using your tools. It’s okay to do things without a goal in mind.

anyonecancode• 5 years ago

Interesting post. I'm ~6 mo into using emacs, but I'm a long time vim user. I use emacs for org mode and org-roam, and for personal finance[0]. And sometimes, magit for git. And honestly... I may never use it for much more beyond this, and that's totally fine with me. Which I suppose is the point of flexibility -- people can use a flexible tool in the way that works best for them. My contribution here is to note that its _also_ ok to decide a tool, even an impressive tool, is something you only want in a few specific contexts without feeling bad about not adopting it everywhere.

I think its working out that way for me because I'm not actually much of a tinkerer. I very much like the straightforwardness of plain text, and I like all tools that empower me to put that in the center of my workflows. I can take or leave emacs, but I love org-*. Actually not too different from how I got into programming in the first place -- being able to write a plain text file in a certain format, point my browser to it, and boom it's a web page, was magic. And from there into actual programs -- use a certain format and boom it does stuff... The tools themselves - eh. Keep it simpler and I'm happier, but I'm not much for customizing them.

I can see how for the tinkering personality one can really get into emacs. That's not me, but emacs works for me for some things, and I've been happy to learn it for those.

[0]https://github.com/beancount/beancount-mode

jonnycomputer• 5 years ago

I use a variety of editors is a ad-hoc way, mostly because for any specific ad-hoc task, one or the other makes it easier to do. For example, creating a scratch buffer (note, not *scratch*) is just easier in BBEdit than Emacs, because all I do is open it and there it is. That said, I do most of my programming in Pycharm these days, and I don't regret it.

As for emacs, I use it just about every day, and I think one of the best things about it is that Emacs will be Emacs whether its 2021, or 2031. Its a lifelong tool for a hopefully long life.

bborud5• 5 years ago

I've used Emacs for 32-33 years and I can't even imagine how many lines of code I've written in it.

Every 2-3 years since the early 2000s I would try an IDE for 1-2 months, but then go back to Emacs again because I was simply faster in Emacs and because the IDEs were supremely ugly, resource intensive and slow.

A few years ago things started to change. IDEs started to become less clumsy. Less horrible to de-fang to the point where they became tolerable. They might have gotten a bit faster too.

Then some time around february this year I felt it was time to give IDEs a try again so I spent about a week configuring VS Code to where it was tolerable. Mostly by removing visual noise. All keyboard bindings etc are standard because I think you ought to learn how to use a tool as close to its default configuration as possible because that means you can make use of the knowledge of other people.

Now, about 6 months later I think I might stick to VS Code for programming in the foreseeable future. Here are some reasons why:

- The support for various languages in Emacs just isn't being maintained. Every so many months my setup for Go would break hard, and along the way small things would constantly stop working and I would have to figure out "what the heck happened now" and hack my way around it. Or shrug and say "okay, so that's gone". This was no different in C/C++, Java and other languages in the past.

- Emacs doesn't have a sufficiently large active developer base. Not only does this lead to poorly maintained language support, but it kind of goes against one of my basic rules for choosing tools: no marginal stuff(1). And Emacs has become marginal. So while I love Emacs, it no longer qualifies as a viable tool in my eyes.

- Emacs isn't going to catch up with VS Code. And I don't think many long time Emacs users want to. They just want to be left alone. Emacs has too many failed attempts at making configuration and adding third party code work well (it really doesn't) and even work with the reams of elisp code each of us tend to end up with after years of trying to get broken stuff to work. Enough for us to develop Stockholm syndrome and thing we want all this chewing gum and duct tape holding things together.

- I don't like JS and its derivatives (like TS) and my dislike is almost militant -- but it beats elisp hands down on every metric that actually matters in the real world: chief among them the number of decent developers who will write and maintain extensions.

As I said, I still love Emacs and I've written close to 100% of my code in it for 30+ years. But I've kind of arrived at the conclusion that it isn't going to evolve fast enough for it to be an attractive option.

VS Code is far from ideal. For one it is written in a language I detest. But it is better for programming Go, and C++, and C and probably java (I haven't written a line of Java for 4 years so I don't know). Yes, it has shortcomings, but fewer than Emacs if your focus is to be a productive programmer and not muck about fixing poorly maintained bits that suddenly stop working.

If people think 30+ years of using Emacs represents an investment they can't afford to throw out I seriously doubt they have really tried. I also think people underestimate their own ability to rewire their brains. I turned 50 this year. I'm extremely conservative when it comes to tools, languages, operating systems because I'm just not that interested in wasting time tinkering with my environment: if it works it doesn't need messing with.

If I can get comfortable with a different environment for programming in a matter of weeks, so can anyone else.

(1) I try to avoid using tools and software that has too few users. Sure, there may be better tools, but tools with small audiences tend to not be well maintained over time. Few users also means fewer solutions you can find online to problems you might have. Pick tools that have large audiences and you will find people that have had the exact problem you are trying to solve. I apply this when choosing OS, language, hardware, tooling etc.

lycopodiopsida3• 5 years ago

To summarize your post: it is OK to use another editor, if it has better support for the language you you want to write your code in.

I see no drama here: I haven an emacs instance always running as my to-go editor but would start IntelliJ IDEA if I have to write even a single line of code in Java. Because it is so much better. Even if I would always reach for emacs if I have to write in Clojure or Racket. Would I still have to write code in JS/TS, I would also use VSCode - do not see it that much justified for other languages, since the support there is spotty at best and nowhere on an "IDE" level.

But the problem is: emacs nowhere claimed to be an IDE in Go and C/C++ so that it makes no sense to condemn it because it did not become one.

bborud5• 5 years ago

It was my development tool of choice for decades. And it very much did the job of IDEs better than any IDE. But it no longer does. In part because IDEs became better editors.

I’d love to use Emacs. But it is more work to use it now than just a decade ago.

ThinkBeat• 5 years ago

The wonderful thing about Emacs is if you learn it well it is a tool that can stay with you and has stayed with you for decades.

I only have a couple of years invested and that was years ago.

Since then, I have had to use a lot of different editors and IDEs. Due to job changes, different programming languages, platforms, and market forces.

Each one has cost me some time, sometimes considerable time to learn well enough to be productive in it. But they are all ephemeral.

X number of years down the line it disappears for one reason or another and the entire investment is lost.

Had I stuck to Emacs (which would be impossible for some of my jobs) I could have gotten much better at using it and that investment would still be worth something today.

rrock• 5 years ago

One of the major things that keeps me in Emacs is the keyboard macros. Being able to record a key sequence is something that I use regularly, and I don’t think the major competitors have it yet.

AtticHacker• 5 years ago

Keyboard macros are great! Although after discovering multiple cursors I found less use for them. 90% of (my) use cases were easier to solve using MC rather than keyboard macros.

teunispeters• 5 years ago

I haven't sunk much "effort" in it. I use it as a syntax highlighted code editor that can load multiple effectively unlimited size files without usually too much issue, recover cursor positions on restart and doesn't suddenly pause and lock up when scrolling. Oh and I need page up/down, home and end of a line as well as doc, and reasonably good cut and paste.

Note : to date, this means it has no competition, except in much more limited editors, like vi and jed. None at all. So far every other package has lost out. And when it's gotten close in capability, it's required it's own walled gardens and can't handle project structures outside of its own.

So yeah, as yet there is no competition to emacs. Maybe someday there will be. Some givens: - it cannot be nodejs based. Has halting randomly, random crash, inability to save and recover and excessive CPU and memory consumption, even with other features covered. - it cannot be one of the many code suites. They all (so far) require projects to be in their Pet Project Format. Useless if one's working on corporate git trees (or other repos), or for that matter linux kernel. - it needs to support many code languages. I do work with lisp, python, bash, C, C++, C#, Java and who knows what else. Just not elisp, not if I can help it ;) - it needs to coexist with the rest of the environment. Cut and paste has to go between apps, not just itself. (you'd think this was common, but eclipse showed me otherwise) - It has to be either UTF8 capable, or binary. Or both.

I mean I've locked emacs up a few times - always with particularly large files ... but this is very rare. oh yeah, emacs user since 1991. I've tried Visual Studio (still have hope on that one, should their linux support finally be good), Eclipse and family, Atom, Code (see Visual Studio), vi, jed, edlin, wordpad, borland C++, turbo pascal and too many other better forgotten systems.

lkrubner2• 5 years ago

I'm currently hiring 5 software developers for a startup that I'm consulting with. On some level, I'm aware that it would help team cohesion if we could all use one text editor. But for the most part, it's a decision that I leave to each developer, as it is a decision that can be left to individuals.

If we were going to use a language such as Clojure, where the whole eco-system tends to use emacs and offers examples in emacs, then I might try to introduce emacs, but the opposite is also true: the feeling that developers should learn emacs is one of the things that makes me wary about recommending Clojure to clients, even though Clojure is the only language I use in my personal projects.

But for this current client I think we will mostly be working with Javascript, so I think most of the people we hire will be happier with their IDE of choice, or with Sublime.

I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp).

But it seems unlikely that anything like that will ever exist, so I go on using emacs, but I don't recommend for any clients.

resoluteteeth• 5 years ago

I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp).

Is there some reason you don't consider this to apply to vs code?

lkrubner2• 5 years ago

VSCode is very good. I could write something about Lisp being homoiconic, also I don't know the VSCode equivalent of "advise", macros rewriting core functions of the editor, but I'll let someone else make that case, if they feel like it.

alex_smart7• 5 years ago

The process of writing Emacs-Lisp: open the scratch buffer, write a function and eval. The process of understanding what any part of the editor is doing: C-h f <function name>, read the documentation and link to the source is again right there. You can go to the source, set up a breakpoint, step through the code, understand it and even modify in place if you feel like it.

There is no other environment I know of, apart from smalltalk, that makes the process of extending and customizing the environment that frictional-less.

I have tried to understand the process of extending vs code, but it seems to require a lot of ceremony.

https://code.visualstudio.com/api/get-started/your-first-ext...

For instance, everything needs to belong in an extension, and you run the extension in different instance of vscode rather than the one in which you are editing the extension, which you have to reload/restart everytime you change the extension's definition.

The difference in experience is similar to the difference in experience in REPL-driven development in an interpreted language v/s developing in a compiled language with the whole edit/compile/run cycle.

monsieurbanana• 5 years ago

Calva on vscode is probably the most beginner-friendly way to start doing Clojure, and has a lot of features thanks to the use of clojure-lsp.

It even includes a quick interactive tutorial for Clojure and structural editing (which is something mandatory to really give lisps a try, IMO).

ilovecaching• 5 years ago

People are treating Emacs as though it's an editor competing with other editors. It isn't. Emacs is a lisp environment. The editor built on top of that is at the same level as the IRC modes, mails modes, org mode, etc, etc, etc.

Emacs is an entire programming operating system you never have to leave. It's not even close to the same as VS Code.

singingfish• 5 years ago

I've been using emacs since 1993 (with a long gap between 94 and 99 where I barely used computers at all). I like to say that it was the only thing that remotely made any sense on the X-windows machines I had access to. I like to say I learned it then, and I haven't had to learn anything new since.

I tend to declare emacs config bankruptcy every few years, so I work fairly close to uncustomised emacs.

komali22• 5 years ago

I only recently feel like I've "gotten" Emacs, to the point where I'm confident enough to tell others about my setup [1], but in the process of doing so I've realized I have so much more built-ins that I've barely touched. Like, dired. Magit, I've only skimmed the surface of. Hilariously, I only learned about apropos last week!

For some reason though I gain great enjoyment from tweaking my Emacs environment (I even made my own theme [2]), and I'm productive at work, so I really can't complain :)

I'm with the author though... would I recommend it? Yeeeeah maybe not, in the long run it's worth it but for new programmers no way, just use vscode like everyone else.

[1] https://blog.calebjay.com/posts/my-emacs-environment/

[2] https://github.com/komali2/Emacs-VSCode-Default-High-Contras...

RHSeeger• 5 years ago

I use IntelliJ every day, to program Java (and some other things) for work.

I use Emacs every day, to do other things for work. For quick, powerful text editing, there's just nothing that compares. For many things, it's faster to start up Emacs, do it, and close it... than it is to just do it in IntelliJ, which I already have open.

Different tools for different things.

SquibblesRedux• 5 years ago

I used to use Emacs for large files and vi for small, quick edits. I am now using VS Code for large files and still vi for quick edits. The single feature that got me to switch from Emacs to VS Code was the ability to use a mouse for navigation and selection. (My Emacs and vi usage was always in a terminal.) I had tried XEmacs for a while, but found it too aesthetically displeasing.

I would be happy to return to Emacs if there was a front end that worked well and was standardized across all windowing systems (Linux/Mac/Windows).

alex_smart7• 5 years ago

I had tried XEmacs for a while, but found it too aesthetically displeasing.

Why would you even bother with a fork whose last release was 12 years ago? :\

frosted-flakes4• 5 years ago

Maybe that's when they tried it. Does it matter?

aaronchall• 5 years ago

If I want to take notes on code in various arbitrary languages I would use emacs because I can evaluate them all in the same note file.

I think there are other editors or systems that give one a multi-language notebook. But having already learned emacs, org, and org's code blocks, the marginal cost of using something else is much higher.

For me, sunk cost isn't the issue. It's the marginal cost of doing the next thing. And that's why I chose to sink so much effort (cost) into learning emacs - I knew it would pay off for the rest of my life.

p4bl02• 5 years ago

I've been using Emacs for almost 15 years now. At some point I even did my emails (using mu4e) and social medias (twitter and identica at the time) with it, in addition to all my work. My Emacs was heavily customized and I spent a lot of time fine tuning it to my likes and needs.

About two years ago, I switched to KDE (from nothing except the Openbox window manager). I wanted to give Kate a try. It's a very decent editor but it was really hard for me coming from my all powerful Emacs setup. It did not really last, but it made me realize that I was originally using Emacs because it is free software from the GNU project, but it was still a jail to me as I was at a point where I had a hard time being efficient anywhere else, even in a vanilla Emacs without all my setup.

Since then I'm still using Emacs but almost vanilla (only minor adjustments — my .emacs.d/init.el dropped from several hundreds of lines to a couple dozens) and not exclusively Emacs. Even for text editing I sometimes use Kwrite or Kate.

maydup-nem• 5 years ago

My Emacs was heavily customized
several hundreds of lines

amateur

p4bl02• 5 years ago

That's just the init.el file. I had several custom Emacs packages loaded from it ;).

dotancohen• 5 years ago

That experience is not exclusive to Emacs. I'm a VIM brat and simply cannot use any text editor that does not speak at least a basic VIM dialect. Thankfully Jetbrains' IDEs have IdeaVIM.

I firmly believe that text editor proficiency is handled in the same part of the brain that handles language. I notice very similar obstacles when switching or learning or trying a new text editor as I do when switching or learning or trying a new language. And those are both something that I do every few years.

dgan• 5 years ago

Every time i tried Emacs, i found that I would be more productive using something else. Still can't find a use for it..

I do use vim tho, as it comes with default installation and has useful regex search, nice to quick edit files

richardjdare• 5 years ago

I like Emacs because it's a live programming environment focused on the editing of text.

As far as I know, there is no other editor with this capability. Sure, they all let you write "plug-ins" but none of them let you do your work by writing code interactively, alongside normal editing commands and GUI operations. As a programmer, this is how I want to do everything with my computer.

I don't have many customizations (I have something to move lines with the alt-key like Eclipse, and I swap parens and square bracket keys so it's faster to write Lisp) and I don't even know many keyboard shortcuts, but I write bits of Elisp all the time to perform large scale text manipulations, generate Java and html boilerplate at work etc. Having everything happen inside my editor, being able to use an editable buffer as an ad-hoc input source to a program just makes everything more fluid and interactive than doing the same thing with scripting languages on the command line.

It kind of baffles me that the Emacs people don't push this angle very much. There's hardly anything about it on the website. You'd think Emacs was just another editor with hundreds of keyboard shortcuts and a strange gui.

kqr4• 5 years ago

I'm not that surprised. It's the sort of thing you won't appreciate until you've tried it. Ask people what they want, and they'll tell you "a faster horse". Ask people what they want, and they'll tell you "a better editor" so that's how Emacs markets itself.

Unless you've tried one, "a car" or "a fully dynamic, programmable editing environment" is just not on people's minds.

andi9993• 5 years ago

I don't understand it. Any examples how to do that in practice? (used emacs for a couple of years, but just as a editor)

alpaca128• 5 years ago

As far as I know, there is no other editor with this capability.

Well, to some degree Vim can do this too. It doesn't let you "eval" a function you just typed into a buffer, but it can eval a vimscript file that you just edited. Including the vimrc, but just like Emacs' init.el reloading it doesn't actually reset the state. But where Vim can't just eval a whole function you can write very complex keybindings on the fly in a much simpler syntax, which made up for it in a few situations for me.

And it's very similar in how the configuration and plugins work - it's all just a scripting language spread across files, and instead of having separately developed plugins you just write a function and run it, more or less.

Emacs is more flexible still, but with its own quirks.

dredmorbius• 5 years ago

The passage that stands out most to me is this:

[W]hatever I've learned for technologies like Emacs, LaTeX, GNU/Linux, and so forth in the nineties, is still valid and useful to me nowadays. This can not be stressed enough: instead of un-learning and re-learning, I was able to improve and learn new things. This scales much better than any proprietary or temporary knowledge.

Even though I don't use emacs,[1] the point here is one that I've long realised and was instrumental when I was looking at potential directions to go with technology in the early 1990s.

I'd had experience across a number of computer systems, small and large, and all but Unix were proprietary. I'd already seen hard-won knowledge expired, often in a few years, as platforms or tools were eclipsed. And Unix was more fun...

Learning vi on the uni shared-access Unix server in the 1980s was a few weeks of pain and confusion. It's paid off handsomly over the subsequent 35+ years, as did basic fluency in the shell and its tools. Over time I've added to my toolset. Very occasionally old tools are replaced entirely, though quite often replacements themselves seek to retain interface (commands, keystrokes) compatibility.

I've also spent time (and occasionally money) learning proprietary systems ... virtually all of which are not entirely dead to me. Some still exist in small niches, others have all but disappeared.

In Future Shock, Alvin Toffler argues that in the future (that is, now), success will be determined not by those who can learn, but by those who can successfully unlearn old patterns. The older I get, the less likely this seems to be true. Unlearning is vastly more difficult than learning. Far better to get on a technological track in which basic principles, tools, and interfaces are adopted and retained as long as practicably possible, in a modular fashion. This avoids requiring wholesale skills obsolescence, provides for maximal skills retention and accretion, and where unlearning is absolutely required, tends to localise it to specific areas.

Voit's essay touches on several useful concepts directly or by reference (learning, unlearning, knowledge capital). I'd like to add another: the Lindy Effect. That's the tendency of things which have existed for a long time to continue existing. In technology it seems to be largely true. In particular, long-lived free and open tools seem to be good bets for continued relevance.

________________________________

Notes:

1. I did pick it up at one point and used it with some facility for a number of months. This was at a time that having ones own Unix or Linux server was still quite a novelty, and my manager at the next gig was an idiot who didn't believe in installing any software which wasn't shipped by the vendor. Life lesson: don't work for idiots, or let them dictate your opportunities.

hnarn• 5 years ago

This is of course anecdotal but one of the reasons I never got into emacs is because every person I’ve met who was really into it was a pathological tinkerer. I’ve worked with people who got no work done in half a day because they were remaking their config for the third time, or reinstalling their Linux distribution.

I’m not trying to insinuate that all emacs users are like this but it brings me to the point of why I don’t want to learn it: sometimes the ugly way is still the fastest way, and if it works it ain’t stupid. For me, the more time something takes to get into, the higher the payoff has to be to make it worth it. For this reason, emacs has never seemed interesting to me, because it seems like the only people “saving time” in it are those that spent a decade learning it first.

yung_steezy• 5 years ago

I only started using emacs relatively recently, maybe since 2016 or so, but I use it every day. I've worked in a couple of different places in that time, first using Debian and now I've got a company macbook. By using emacs I didn't need to change my workflow at all between the two operating systems. What's more, even though I dislike macOS, I am able to enjoy using my work PC without grumbling about the OS like some of my colleagues do.

As other comments have pointed out, there are some limitations to the amount of productivity that you can squeeze out of emacs vs. modern dedicated software. I can appreciate this point as a senior developer often scrambling to work to deadlines. That said, those potential gains in productivity need to be weighed against the potential loss in passion for my job that might occur if I dropped emacs.

BeFlatXIII2• 5 years ago

As someone who is a basic vim editor and uses the occasional Idea IDE, would it be worthwhile to invest myself in an emacs environment?

johannboehme• 5 years ago

Not an answer but an anecdote: I am a long time vim user and wanted to learn clojure. Everyone recommended emacs, because of it's lisp and repl abilities and ease of use.

I spent two weeks learning emacs, elisp and the ecosystem. I was not able to get it to run via WSL with Frontend integration (shadow-cljs). Several help channels where unable to assist, since they all just blamed other parts of the environment (WSL, the LSP, DoomEmacs or the clojure plugin..)

I eventually got it to work, just to find out, that vims minimal plugins that i used (vim-iced, sexp, and a Coc plugin) where faster, more reliable and better to use than the emacs counterparts.. and they just worked, without any troubleshooting.

lytefm• 5 years ago

I'd say that learning vanilla Emacs and all the internals is probably not worth it.

But if you'd like to try out Emacs, have a look at Doom Emacs or Spacemacs - then you can still use vim keybindings for most stuff.

And just activating some of the included modules will give you enough to easily try out some of the best emacs packages out there.

I wouldn't bother setting up emacs for programming, but org-mode is amazing.

jeffyang2• 5 years ago

I use both Visual Studio and Emacs. In general Visual Studio does a pretty good job and it is my day to day editor. But there are some things that it's simply not worth bothering with in Visual Studio.

The problem with most editors is that every buffer and every command is different. Code is different than the terminal which is different than your source control. Sorting text is different than copying text is different than formatting text. That means every new thing you want to do, even if it's small, requires you to learn how to do it the way that tool wants you to do it.

In Emacs, every buffer is the same. Which means I can do all sorts of mini workflows without learning anything new. I can navigate the buffer the same way and I can copy text the same way. I can run arbitrary linux commands from my scratch buffer on buffers on multiple machines and massage the output and put it in my code buffers. I can run a macro to repeat that 1000x. Then I can tweak it slightly and run it another 1000x. I don't need to learn anything specific to my editor. I can whip this up in a minute then move on with my day because it's a one off.

Yes, sort lines is available in all editors. What if you wanted to sort all the import statements in every file? In Emacs you can do a quick macro to do that. It would take you a couple of minutes MAX. You wouldn't have to even think. All because sort-lines is text that you can copy and paste. In Visual Studio... I don't even know what I would do... probably find a plugin or write a program. Imagine you found a plugin. Then imagine you didn't want to sort ALL imports, there's one import you always want at the top. Trivial to change in Emacs, not so trivial for a plugin.

stakkur• 5 years ago

I’ve used Emacs for several years now, primarily on Linux but also MacOS.

I never recommend it to new users without the caveat of time investment; it’s a disservice to just say ‘Emacs is great’. It’s great in the same sense as a large box of Legos is great—for potential, not OOBE, which is (in my opinion) fairly mediocre.

My second unpopular opinion: Elisp is a significant barrier to entry for users. Changing this would blow open the doors to adoption and evolving the tool, I think. But it will never happen.

The Emacs Lock-In Effect or the Emacs Sunk Cost Fallacy

Related Stories