The Emacs Lock-In Effect or the Emacs Sunk Cost Fallacy | Hacker News Reader

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

karl-voit.at

175 pointsfipar265 comments

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.

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.

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.

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

Yes, Overleaf. I'd always had LaTeX envy but when faced with installation and configuration, I gave up again and again. Overleaf solved all that.

In college we were required to typeset assignments in LaTeX for all the math classes past multivariable calculus. I started out with Overleaf, but switched to local compilation about a year in. It's much nicer to be able to write in my usual text editor and compile documents instantly. On Arch, all I had to do was install texlive-most. It includes every package I have ever needed to use. To compile a document, I just run 'pdflatex *.tex'. Sometimes bibtex too. If you're having trouble with setup and configuration, I recommend texlive.

>installation and configuration

On Linux, literally run the texlive installer script and install an editor like TexStudio if you'd like. That's it.

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

There’s mastering the use of your tools and there’s tinkering with the windings on the electric motor inside your tools. Emacs offers users both.

How common is it for carpenters to make their own tools? I actually don't know!

Did you write Emacs? Did I write Emacs?

For a lot of custom carpentry, it's pretty common for carpenters to make their own jigs to solve specific problems (e.g., if you need to use your router a bit like a thickness plane to mill down some object by a couple of millimetres along some axis so it fits somewhere, you probably want to build a jig first).

Pretty common, I think. I've made clamps and rove punches for instance, and I've been tempted to make drill bits. (But this is for wooden boatbuilding, which is its own uniquely crotchety corner of carpentry. Not unlike emacs...)

For most woodworkers, I'd say the analogy is closest to making "plugins" for existing tools. They require a little knowledge (which easily obtained on YouTube), and can greatly increase your ability to use the base tool.

One example is a table saw sled, which helps you make clean, repeatable, 90º cuts. It's one of the most useful "plugins" you can have for your table saw, and relatively easy to make. Making the actual table saw, on the other hand, would be expensive and very difficult, and would require knowledge of many fields (metal working, electrical systems, etc.).

It's more like a carpenter saying "I don't want to master my car, I just need to be able to get from place to place". A mathematician isn't payed to typeset papers, they're payed to do mathematics and typesetting in LaTeX is just a means to an end.

I once worked with a pretty amazing older Common Lisp programmer who used some IDE (Xanalys?) He selected forms by dragging with the mouse. Watching that felt uncomfortable, almost like physical pain.

I tried to get him into paredit, but he smiled a little and said his brain isn't so fast that it could keep up with frantic fingers like mine.

Indeed, he worked out things in his head before splashing into the buffers and mostly got things right by doing just a few things, slowly. Of course CL is one of the better languages for that.

I think programmers overestimate the importance of editors or typing. Comfort is more important than speed or efficiency, but of course you feel discomfort if you lose the speed you are accustomed to! If you feel comfortable in whatever editor you use, congrats, your quest is complete.

I can definitely sympathize with this. Typing in things has never been the bottleneck. Rather, deciding what needs to be typed in takes up the majority of the time. It probably helps that neither of my main two languages (Ruby for work/Haskell for fun) is all that verbose.

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.

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.

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

How do you do package (version) management for LaTeX? There's more than a few documents I've come across that won't build on my system, giving often-indecipherable compilation errors. Overleaf at least ensures everyone involved is using the same environment without needing to ship a Docker container or the like, or try to pin down versions.

I suppose it should be fairly portable, except for missing packages maybe. In my case I have literally every common package installed so that's not an issue. But LaTeX errors are a real pain, I'll admit that.

Nix has a decent solution here, i.e. turn the document into a nix derivation.

  with import <nixpkgs> {};
  
  pkgs.runCommand "cv.pdf" rec {
    src = ./cv.tex;
    bin = with pkgs.texlive; combine {
      inherit scheme-medium collection-latexrecommended collection-fontsextra
              moderncv etoolbox;
    };
    buildInputs = [ bin ];
    allowSubstitutes = false;
  } ''
    ln -s $src cv.tex
    latexmk -pdf cv.tex
    mkdir $out
    mv *pdf $out/
  ''

These days I'd probably use flakes to pin down the latex version.

Lol, that's not the command for making a LaTeX document. The command for making a LaTeX document fills a sheet for all the shit you have to install--half of which isn't correct on whatever documentation you're reading--and THEN you can `latexmk`.

And I do mean you. I gave up after a solid week. I'll just make whatever I want in PowerPoint, save it to a PDF, and be done in 15 minutes.

Yes, I said PowerPoint. Set you're slides to 8.5x11 and it became a typesetting program. I've started getting my coworkers to use it for such and they are absolutely delighted by the bump in design quality they are getting because they aren't fighting Word anymore.

$ sudo apt install texlive latexmk $ latexmk -pdf main.tex

I didn't try it, but it wasn't much harder than that if I recall... If you're on Windows, well, it's your loss :(

Excuse me for being one of the 80% of working Americans

So download whatever latex distro you prefer for windows, open your document, click the button. It will automatically download missing packages in the background. Done.

Highly relevant username.

> Yes, I said PowerPoint. Set you're slides to 8.5x11 and it became a typesetting program.

That won't print sensibly on the paper in your printer, in most of the civilised world.

> I'll just make whatever I want in PowerPoint

If you use PowerPoint, you might try TeXmacs (WYSIWYG, structured and programmable).

> they are absolutely delighted by the bump in design quality

I expect them to be even more delighted :-)

> The only thing Overleaf adds here is a button and a 10x compilation time overhead.

Overleaf removes the need for local install. A full MacTex.pkg install is 4.4GB. I've lived in LaTeX for more than 30 years, and I love the ability to edit docs from any browser.

4GB today is not that much. Current OpenBSD and NetBSD install recommend 2-3GB at minimum for a base OS and 10-16GB for a confortable usage (installing a bunch of pkgs/ports, swap partitions, and so on).

Maybe it's just me, but 4.4 GB does feel like a not insignificant amount of space for something I don't have to install locally. Or for people that use it rarely.

I'm not a huge fan of Overleaf, mind you, but I agree with those that say it does have its uses. The easy collaboration for people that don't like -- or don't get how -- to use git. I wish everyone I collaborate with liked git...

I've used LaTeX for about as long as I've used Emacs, and really, the thought of editing LaTeX from my browser is rather painful. You can still use Overleaf via git, though admittedly the experience isn't as smooth.

Overleaf allows you to work with several authors at the same time on the document. I was skeptical (after all, git allows that too). But after using that feature, well, it is just the killer thing. Now Overleaf doesn't add much on top on my own Latex installation. But the collaborative thing is just spot on (much like Google docs which I have discovered not a long time ago; same analysis : not that good presentation tool, but working together is just incredibly useful).

In my experience, Overleaf is actually awful for collaboration. Maybe my workflow is weird, but I tend to look at the diffs after my colleagues make changes. Also, we mainly use pull requests to add to our papers. This way, everyone can see and comment on changes.

This kind of workflow is not really usable with Overleaf. Overleaf uses Git in the background, but every commit is named "changes on Overleaf" and the individual commits do not really make much sense. In addition, everything is immediately put into the master branch and there's no way to summarize or group changes (like with commits and/or pull requests).

My next problem is, that Overleaf just uses latexmk so if you have some code to generate graphics or tables, you have to compile and add them manually all the time.

my workflow is different : we use voice chat to share and we edit collaboratively. Both these allow to actually work together and, more importantly, think together.

That's very interesting. I honestly didn't think of that, since we often worked asynchronously or at the same machine (which doesn't work at the moment, of course). I can see how Overleaf can be nice for that purpose.

Use pandoc

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

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.

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.

> Fortran has seen major changes over the 64 years it's been in use.

And yet most Fortran programmers reject/ignore those changes and stick to Fortran 77. When I was in academia, I couldn't find a single person writing Fortran code in anything newer than 77.

My experience with that convinced me that many academic Fortran users are cargo cult programmers to the extreme. They're "taught" by examining the code written by their advisor's advisor's advisor who may have properly learned F77 back in 1980, but no one else did.

Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66). Specifically, that's the version that got structured programming elements added to the language. Having once inherited some pre-F77 code (well, it was F77 by the time I got it, but was started before then and that was obvious by its almost complete lack of structured programming), I can say that F77 is a substantially improved language over the prior versions.

> Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66).

That's because FORTRAN is one of the oldest languages, and you'd expect lots of changes as the whole field develops. If you use that as a metric, most languages will appear stagnant. Python hasn't changed much in the last 20 years, for example.

Yep, folks often fail to distinguish between old and OLD.

One might think Eclipse IDE is old. But Fortran predates the three-point seatbelts. The Vietnam War. Berlin Crisis. The Space Race.

Interesting, my experience was the opposite, everyone (1) was writing Fortran 95'ish. Might not have been the most beautiful code, but they took extensive advantage of the major F95 features like modules and array syntax.

(1) Except that one old beard who was convinced F77 was the ultimate, and everything newer was crap.

> 1. A good concurrency model.

This is definitely the biggest pain point, especially as people go to expand their use of Emacs (e.g. with Doom, adding more modules and integrations, one has to be careful to lazily evaluate config blocks to avoid loading everything at startup).

Even without such extensive configs, working on a large repo with a slow I/O (e.g. some network mount) with magit will cause large pauses once a command finishes if it has to refresh the magit buffer, or trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.

I do at least look forward to Emacs 28, which iirc is going to get native-comp (although that is already available as an experimental branch perhaps?).

Native comp was merged to the mainline a few months ago. It's behind a config flag `--with-native-compilation`. There is not yet an official release that includes it, but it's fairly common for people to run Emacs built from the mainline source.

> trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.

Please try `org-ql` and `helm-org-ql`; these newer search tools perform better than `org-rifle` and generally supersede it.

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

Exactly, if it wasn't for the community building and maintaining great packages like org/magit/lsp-mode etc, I would've dumped Emacs long ago. Building that as someone who has other responsibilities than editor hacking is just a non-starter, so I stick with Emacs despite it's event-loop-blocking quirks because of it.

I wonder if there will be a way to sidestep these limitations or if something in the language semantics would forbid it (e.g. the way Python is basically limited with the GIL because current updates are basically not tolerated by the semantics).

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.

I should have clarified...

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

I was really responding to this. You're right though: there are aspects of Emacs that are dated, the UI isn't very spiffy, and I've never dealt with elisp before so I'll take your--and everyone else's--word for that. I was just suggesting that it gets the job done for a lot of people and maybe, as a result, shouldn't be classified as outdated.

It's true that I maybe made it seem a bit too much like emacs itself was outdated. But really I think that it is built on outdated paradigms, which hinders its development and presentation a bit. I was fully serious when I said I cannot imagine switching to anything else (and I'm not afraid of switching otherwise), it's still the best we have in my mind.

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

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

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.

Once you've hit C-x e once you can keep bouncing e to repeat the macro as well.

Thanks for the reminder. I knew that once, but completely forgot about it!

Using non-standard notation for describing keyboard shorcuts doesn't help.

This is the notation that emacs has been using forever, and also displays to the user, so every user should be well comfortable with it. It even says “Press C-x C-c to exit emacs” at startup.

It's still non-standard, and is yet another barrier to adoption.

I found it handy and I often use it outside of emacs as well when describing shortcuts to people. Mainly C-something for ctrl.

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.

I'll second this. Take a look at Vertico [1] and Consult [2] which really improve discoverability. Other nice packages (links found on the Vertico page) include Marginalia and Orderless.

[1]: https://github.com/minad/vertico

[2]: https://github.com/minad/consult

Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :)

Even so, the "sort lines" example works well with even the out-of-the-box completion. But, Emacs sometimes has its own language for things. If I didn't know the keyboard commands for "make region uppercase" and "make region lowercase" (which in fact I'd forgotten, although they're pretty trivial), then as far as I could tell the best way I could find them would be: Google. Inside Emacs, I could type "M-x up" and get the correct "upcase-region", but if I'd typed "M-x upp", I'd be out of luck. And Emacs-ese for "lowercase" is "downcase"; I wouldn't have guessed that at all!

So I'm not sure the flow looks nigh identical for that many cases like this. The way I remember learning Emacs basics many years ago was actually through menus. Looking at Emacs's menus now, in v27.2, they're...kind of eclectic? The basics are there, but a lot, well, isn't. BBEdit is admittedly somewhat at the other extreme, with possibly just too damn much in its menus, but that does make a lot of its functionality very easily discoverable.

At any rate, I should be clear that I think this is a mild knock against Emacs; I bounce off it in part because of this relative lack of discoverability, and also because it just seems like it takes a lot of effort relative to most other editors to set up comfortably. The flip side of that is that, as the "Lock-In Effect" article notes, once you do have it set up the way you like it, you are probably never going to have any motivation to switch. That is absolutely not a knock -- it's configurable and extensible in a way nothing else is.

Right, I was assuming something like helm or ivy. I only have experience with helm.

I should also highlight that I think folks should lean on apropos way more than they typically do.

Apropos is definitely a great feature!

> Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :)

This is not quite true.

The minibuffer, which is what vanilla Emacs uses for M-x command completion, has a set of completion styles, ordered by preference. You can find the full set of completion categories supported by Emacs in the variable completion-styles-alist. Among those is one called flex, which allows for full fuzzy matching between provided tokens.

This is not a default minibuffer completion style, but it provided without additional packages. One would add it by adding it to the list of completion styles used by the minibuffer as specified by the variable completion-styles. I recommend trying it out.

TIL. Planning to play with that in the near future. Thanks!

Interesting! It still doesn't quite shake my suspicion that the best documentation for Emacs is "find somebody else who knows more about Emacs than you do," but to be fair that's not unique to Emacs. :)

Honestly, I wouldn't have been able to tell you this two weeks ago. I know all this now because completions in a language I don't normally use felt off somehow, and figuring out the solution involved going deep on how Emacs handles completions. That ended up not being relevant to the root cause, which was a change in Doom causing snippets to be overvalued in LSP completion, but at least I know a lot more about vanilla completion methods now!

This is a helpful tip, but I feel like it kinda reinforces the broader point about emacs's lack of discoverability. I've been using it for years and wasn't aware of this feature until today.

  M-x customize-apropos some-string

This is how I've discovered most things outside of just reading the documentation (and usually I go to the documentation once I find it). It's also helpful that the info pages in emacs are also searchable with:

  M-x info-apropos some-string

Both are kind of firehoses, but C-s inside the resulting buffer can usually narrow it down pretty quickly.

I'd like to know what other editors have a discovery system like this built-in.

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.

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

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.

How does the old joke go -- "Now if Emacs only had a decent text editor, it would be a pretty decent OS."

Evil mode

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

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.

About point 2, this can be done with vscode using this extension

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

This explains it https://code.visualstudio.com/docs/remote/ssh-tutorial

There's a similar extension to work within containers https://marketplace.visualstudio.com/items?itemName=ms-vscod...

Emacs has TRAMP as well out of the box, but for some reason they want o launch a lightweight cli instance of emacs on the serverside, which VSCode can't do.

If you have more than one ssh hop or a remote desktop in-between Tramp isn't an option.

Tramp works through multiple SSH hops just fine:

https://www.gnu.org/software/tramp/#Ad_002dhoc-multi_002dhop...

TIL! Thanks.

Any good videos as examples of the window partition practice?

> buffers and windows

How is this different from tabs? You have global search to open files in new tabs, you can opt to leave a trail of new tabs as you follow links through your code, you create arbitrary new tabs and plop snippets in, and have an option to persist to a file whenever you wish. You can reorganize your tabs layout, create an arbitrary number of rows and columns, move tabs back and forth between different groups, splitting and merging groups as you need.

I haven't found any editor that makes handling of split panes as streamlined as Emacs, and that's because while having the tabs tied to a single document is a sensible metaphor, it's just way faster to have two or three panes whose contents you can switch from an autocompleted list of buffers. No clicking around, no squinting your eyes at the little tab titles, no dragging and dropping the tabs to switch them from pane with awkward snapping in and out.

(buffers can be files, configurations panels, terminals, applications, whatever really)

But editor ergonomics are always trumped by tool support, and Emacs' can be good, but it's never reliable in supporting environments that aren't Lisp and academic stuff like R and LaTeX.

Ah, excellent, just wanted to make sure there wasn't some magical insight i was missing out on by not being familiar with emacs.

re: clicking/squinting/dragging/animations those i would usually handle by things like keyboard shortcuts, configuring your global search to list tabs first, configuring animation.

I think what is more interesting is the idea to use the same buffers/windows for non-text-files. So, the first half is the idea of having all your tooling be text-based. There's some slider along, text driven by keyboard => gui driven by keyboard => gui driven by mouse. And then the second half of the idea seems to be how you separate text-editing/config/applications. So maybe along that slider, emacs mixes all sources / IDE groups sources within an application / separate applications for each source.

Maybe pushing everything to one edge of the slider is able to put one in a zen-like state. I guess for now I just try to find a sweet spot with my tools, where stuff i want to do fast i can do fast, and everything else is ok as is.

> No clicking around

Every modern graphical editor I'm aware of lets you jump around in tabs/windows/panes etc. exclusively with hotkeys.

I don't know why people keeping talking about clicking around. They are all completely operable without resorting to clicking. Maybe not with IDEs, but with VS Code / Sublime / Atom, you don't need a mouse for anything I'm aware of.

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.

I don’t think I’ve ever used a mouse to operate a single function in VS Code. Literally everything (in the actually literal sense) is available through a keyboard shortcut.

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.

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

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.

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.

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.

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.

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

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?

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)

Might the {\rm text} notation be LISP-inspired syntax? Replace the braces with parentheses and remove the slash and you get `(rm text)`

Somehow \mbox is the opposite though (see the examples) : https://www.tutorialspoint.com/tex_commands/mbox.htm

Honestly I think I am missing all the points about brackets in Latex, if somebody knows the Syntax (and the 'why' pls tell me).

> 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

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.

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

Seems like you haven't heard of the "-interaction=nonstopmode" flag...

If you're pressing X for each error, this will be life-changing.

Thanks, I have actually never heard of that.

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

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.

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

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

Can it be used without elisp?

It can be used as a "dumb" format and even then it's superior to e.g. markdown.

The real magic requires code of course, but it doesn't have to be elisp.

Pandoc can read from and export to Org format. As well, there are a number of Org parsing libraries in other languages; see https://alphapapa.github.io/org-almanac/#Parsing

> 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

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/

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.

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.

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.

I admire your efforts and passion on the subject. I myself would like the Org format more widely supported in other environments. (I personally do run Emacs headless in a couple of CI processes to get at its superior Org support, but it's hard to convince others of its greatness!)

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

Not only do I take it too seriously -- it's not even a joke in my book. Let's agree to disagree on that bit and you can spend your time better than arguing about it!

FYI, there are a variety of Org parsing libraries outside of Emacs. Some of them even appear to be robust and well-developed. I collected a list here: https://alphapapa.github.io/org-almanac/#Parsing

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.

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.

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.

I tried org-roam too and it just feels like a bad joke compared to VSCode's foam. Foam has a real time graph of your notes. In org-roam, you need to call a method to get a static graph open in your browser. In theory, you can click the nodes in the org-roam graph to go to your notes... but it doesn't work out of the box for me. Whereas in Foam I can just ctrl+click on a node and bam, i'm in the file I want to be.

I also really like that Foam lets me edit files in markdown in the left window while seeing the rendered version in the right window. The trade-off is this seems to waste screen real estate like there's no tomorrow, but with a 4k screen, I think it's worth the trade-off.

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.

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

I switched from Emacs to VSCode to doom emacs and will not be going back anytime soon. For people who mainly want to focus on development, I would say it is fine to break the conventional vim/emacs wisdom that you should start from scratch.

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.

JavaScript: "Lisp in C's clothing"

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

No, it's not. It's nothing like Lisp and will never be, simply because it misses the biggest (arguably most important) feature of Lisp - homoiconicity.

But sure, if you squint your eyes - pretty much every single modern programming language would be "like a Lisp" Why? Because there's not a single programming language in use today that was not influenced by ideas first pioneered in Lisp.

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.

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

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

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

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.

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

Probably just about a couple of million lines of existing elisp (or more relevantly, the functionality therein).

If you're not a professional web developer, spending 80 hours learning how to modify Emacs will give you much more control over Emacs than the control you get from spending 80 hours learning how to modify VSCode.

Or ar least that was my experience though I was in my prime when I learned Emacs decades ago and almost 60 years old when I spent the 80 hours learning how to modify VSCode.

(I feel I have barely scratched the surface of VSCode and of web tech.)

Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.

One more thing. For years I went without internet access in my home, yet during those years I continued my habit of doing my emacs modifying at home: all I needed to do was make sure I had the Emacs Lisp reference manual and the Emacs Lisp source-code package installed. On every Linux distro I have used, these are standard packages, and they are all the information I needed to make most of the modifications I made to my local Emacs environment. In contrast, although there are troves of documentation on web tech, I have never succeeded in making a usable offline local copy of any of these troves, and wouldn't consider trying to modify (or explore the internals of) VSCode without constant access to the net.

While true it also means that there is a way larger group of people skilled enough to develop new plugins in js.

> Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.

Emacs can certainly apply red squiggles and many other rich text formatting, through the use of faces (which is how all syntax highlighting is implemented). Emacs also has a rich text-properties API through which any part of a buffer's text may be propertized with metadata. And it also provides overlays, which "overlay" text, also optionally with additional properties, without modifying the buffer text itself.

Together, these features are used to implement GUIs such as the Customization system with widgets, buttons, clickable links, collapsible sections, etc., as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.

Do you have a screenshot or a sexpr I can eval to produce the red squiggles in my Emacs?

> as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.

Thanks. I now know how to make red squiggles in my Emacs.

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.

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

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!

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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)

The question is almost like asking a fish to describe water. It's the sudden lack of it that produces a really clear example. :)

Anyway, here's a random example that comes to mind: I have some sexps in a Lisp file and I want to sort them alphabetically. Each sexp (usually a top-level form, but not necessarily) usually spans multiple lines, so line-sorting won't do it. Since they may be top-level forms, there may be comments between them that would lose their context if their position relative to sexps were lost, so comments need to "stick to" sexps they're above.

How would you solve this in a random text editor?

In Emacs, I would develop a command that does what I need. At each stage of the development process, I evaluate the command's definition, and it's instantly available to be used and tested. I could even test the function on its own definition, if I wanted to be silly (undoing the sorting after testing, of course).

When I'm done, I save the command definition to my configuration, and it's now a permanent tool in my toolbox. I didn't have to recompile the editor and start a new process, nor did I have to submit a patch to an upstream and ask for it to be merged. Similarly to a carpenter (forgive me if it sounds silly), my editor is my workbench, and as wood is malleable, so is my editor.

So, here's the command I came up with (maybe not the prettiest implementation, but maybe not the worst): https://github.com/alphapapa/unpackaged.el#sort-sexps And using Emacs and Org mode, I publish it into this "unpackaged" package, which I then install into my configuration as a package, and other users can then easily install it into theirs, too.

I don't know of any other editor that can do all of this, certainly not so easily.

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

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.

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.

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

Emacs comes with everything you need to learn emacs-lisp. Take some time to familiarize yourself with the help facilities* and then jump over to info, start with "Emacs Lisp Intro" and eventually continue with "Emacs" and "Emacs Lisp".

* At the very least, familiarize yourself with "C-h f (describe-function)", "C-h v (describe-variable)" and how to read info pages. To view what other help facilities emacs provides glance over "C-h ? (help-for-help)".

I've been able to get by so far with the inbuilt doc and reading the code for installed packages, etc. I can read other people's config and reasonably copy needed chunks, debug issues (I've submitted PRs to magit, org mode, and Doom to fix various issues).

The problem is that the last little bit to get to a fluent understanding has been elusive, e.g. how some of the macro-heavy features work (e.g. the common lisp stuff), or how to handle async code (e.g. how magit runs a command, and then refreshes the buffer after it completes). I have this fluency to some degree for the languages I'm paid to produce code in (e.g. C++, to some extent; Stroustrip himself said his knowledge of C++ was "7 out of 10 on a good day" or something like that), but these last few advanced features have been a tough nut to crack in elisp.

The good thing is that the source is always right there and you can read it or set breakpoints and step through it to see how things work.

> how to handle async code (e.g. how magit runs a command, and then refreshes the buffer after it completes)

Emacs's primary mechanism for async code is: spawning an asynchronous process and interacting with them using a process filter/sentinel. This allows you to do things like detect when that process has emitted a certain output or signal and run some code based on that.

For example, magit user the process-sentinel for a pull/fetch command to call (magit-refresh) to refresh the buffer. (How to fish: I guessed that magit-refresh was probably the function refreshing the buffers, set a breakpoint in it, and voila now I have the entire stackframe.)

Relevant pages from info: "(elisp) Filter Functions", "(elisp) Sentinels".

As someone who's very comfortable writing Elisp and reading the Emacs documentation, I must disagree. Emacs documentation is comprehensive and it is very clearly written, some of the best I've seen -- but as reference documentation.

It is still somewhat short on examples/practical how-tos. You need to be comfortable with the system and have some idea what you're looking for. A great example is [`display-buffer-alist` actions][0]. Thoroughly described, with appropriate cross-linking, but still kinda [hard to really grok without resort to existing code][1].

[0]:https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... [1]:https://www.reddit.com/r/emacs/comments/cpdr6m/any_additiona...

Hmm, window management is just one of those corners of emacs I have not gotten around to grokking yet. Yes, I am annoyed by it, but I usually keep things sane by just having upto 3 windows at a time and just manually fix things (usually just winner-undo) when emacs functions do whatever with the windows they like to do.

In my opinion, usually the manual contains sufficient examples and motivations to explain the topic, apart from the detailed reference documentation.

Even for your example, there is this page, which seems to give an overview of the topic. (Granted I haven't really delved in these parts of Emacs, so it is not possible for me to know whether the page does a good enough job.)

https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

>hard to really grok without resort to existing code

But the code also ships with emacs, so technically...

An Introduction to Programming in Emacs Lisp[0] is how I've been learning it recently.

[0]https://www.gnu.org/software/emacs/manual/eintr.html

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

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.

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.

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.

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.

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

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.

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.

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

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.

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

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.

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.

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

"Megabytes And Constantly Swapping".

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.

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

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.

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

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.

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

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

Virgin Islands, cough.

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

Indeed:

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

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

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.

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

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.

Using `cat` is fine but having a format-aware cli dumper would be better. And I never edit org files outside an editor that knows how to handle org files.

I think Clojure's EDN format as used in Roam and Athens does a better job since it avoids the parsing problem while still being easy to fix if the file gets corrupted (though how much of a risk is that these days).

> I never edit org files outside an editor that knows how to handle org files.

I guess I'll also add, I use Emacs in environments where not everyone else uses Emacs, and I like to make TODO lists, write up docs.

Yeah, I can export to HTML, but it's a nice bonus to Org that I don't really have to -- I can write all of my docs and share them with people as plain Org files or stick them on a random flash-drive, and I know they'll still be readable.

Could just be my own disorganization/laziness :shrug:

> having a format-aware cli dumper would be better

My opinions have lately been jumping around a lot on this. In theory, having a good machine-readable format that you can dump out from a command line is enough, because you can turn that format into plain text if it's ever important to do so. So I sort of see where you're coming from.

In practice, I still feel like the lack of friction working with pure text adds something? I do occasionally boot up Vim or stick files on a flash drive and edit them on someone else's laptop when I'm away from Emacs.

But I don't know. Regardless, I do want a format-aware cli dumper, so you're absolutely correct on that point :)

The other thing I meant to say, it's too easy to accidentally mess up an org file while editing it. Manual errors are the most common source of the corruption you mentioned, IME. That doesn't happen with structured editors like paredit.el or Word or Roam.

Word is the worst for accidental manual edits screwing the whole document. I cannot count the number of tines I've watched my classmates manually adjusting dozens of graphs and images in as many pages one by one because they shifted something in inititial pages.

> 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

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.

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?

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.

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.

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.

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

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.

> My Emacs was heavily customized

> several hundreds of lines

amateur

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

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.

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.

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.

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.

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.

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.

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.

> The ideal tool is one that you can start using right away,

There's a strong correlation between things that are not so easy to get into but the gained efficiency later. Conversely, very often, something that is very intuitive off the bat starts feeling cluttered and not very efficient later.

Imagine if you go to a nuclear power plant control room (or the cabin of an industrial excavator) and tell them - "Jeez. So many knobs, buttons, and switches. Why can't someone design a single, incredibly intuitive interface with a huge touch-based display?" For them, those knobs, buttons, and switches are probably the most efficient way to operate their machinery, even though initially, it requires training, certification, etc.

You cannot prioritize both - for the novice and the professional at the same time. You either convince beginners to learn the tool or make a simplified version of the tool for beginners. But it will never be an ideal tool for a hardcore professional.

Yup. I personally bounce between Vim and many CUA-compliant Linux editors for editing text, and Zim-wiki for "what org-mode" can do:

I gave Emacs+Org-mode about a year or so, and I saw a whole lot to like, but lack CUA-compliance is literally the thing that stopped me, I just use too many other programs that aren't Emacs for this to work.

But look, you've been using Emacs for 10 years! That's ages in software time these days.

The downside to software that lasts a long time is that yes, vocabulary will change. So now you change to CUA compliant keybinds. Then the world changes again and now you're constantly chasing whatever is new and disrupting your users by throwing your whole "can use for 10+ years" value prop out the window.

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

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.

Again, as in your GGP post, you mention set up time. Have you seen the myriad comments on this page to the effect of "Just use it as-is!", and what do you think of that?

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

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

git-link.el

> What if you're already browsing code on GitHub and want to check out this specific file

github.com/agzam/forge-visit-here.el

> I want to send a YouTube link to my colleague

org-cliplink.el

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

github.com/agzam/.spacemacs.d/blob/master/layers/ag-general/funcs.el#L99

> how can I quickly translate any word or a phrase

google-translate.el

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

mw-thesaurus.el

> I use and love Grammarly

lsp-grammarly

> github.com/

Thanks!

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

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

> 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? :\

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

Erm, yes. Their complain was about aesthetics, and GNU Emacs has been much more aesthetic than XEmacs since forever.

True enough.

Do you mean it had much better aesthetics? Something can't be more aesthetic, that's like saying it's more temperature outside when you mean it's hotter.

Yes, considering what XEmacs looked like, I would say that newer Emacs look considerably more aesthetically pleasing. And with certain themes, Emacs can look outright gorgeous.

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

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.

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.

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.

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.

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.

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.

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.

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.

I would argue that Emacs is more than just programming. I use it for:

- GTD with org-mode

- Git client

- Mails with mu4e

All of it not because I can do it in emacs, but just because it is the most comfortable solution out there: I have used OmniFocus for years before, several git clients and obviously all kind of mail clients, including web abdominations.

Again, Emacs is not an IDE and never was one. I don't know what "a job of IDE" is, but for Java it was certainly never on the the level of Eclipse. The same is true for Python - PyCharm is an IDE, Emacs and VSCode are glorified editors with mediocre hinting.

On the other side, today's development environments are complex and people want them more and more integrated in their editors. Keeping a configuration needed for such an advanced editor across multiple languages is not a trivial task an maybe beyond capabilities of a single person. This is the reason why Emacs distributions exist and are increasingly gaining popularity. I also have more confidence in Doom Emacs and it's team of contributors than in Microsoft.

I used to use Emacs for all of those things and more.

I think I used Emacs as my email client for around 20 years. There was never really any email client that did IMAP well and storing mail locally doesn't work when you have a couple of laptops, two home machines you use for work, a couple of workstations at work. I can't remember which email client I originally used, but over the years there wasn't much left of it since I had rewritten large parts of it to offer tolerable IMAP support that could deal with having 3-4 different accounts for work, personal, hobby etc.

What broke things was when maintaining a mail infrastructure became too much work and I that I had to use services for work that didn't play nice with most mail clients.

And this sucked since I had something like 10kLOC of elisp to deal with sorting, categorizing, prioritizing and filtering email. So I had this specialized email client nobody was willing to touch (can't blame people since the code was probably garbage) and I had a choice between continuing to spend time maintaining it and just use more convenient options.

It depends on what people think when they say IDE.

I would say I used Emacs as an IDE for C, C++, Java and to a certain degree, Go. For me an IDE needs to do syntax highlighting, have some semantic understanding of the language, be able to do sensible completion, understand symbols (find definition, find uses), show me documentation, interface with version control, be able to do simple refactoring, run builds, tests, perform debugging etc. It doesn't matter whether it is a clicky or GUI'y interface - what matters to me is that I can have 90% my needs as a developer served within the same environment.

Or let me put it another way: I don't use VS code for anything I didn't use Emacs for in the past when I develop.

But the thing is that Emacs doesn't have enough active developers maintaining stuff. For instance, if you program Go, things worked okay - and then the semantic bits moved to language servers and Emacs extensions were slow to adopt this. Making Emacs a lot less useful. Every so many weeks you'd sit down a weekend to try to cobble together something that would minimally work and it became tiring.

And yes, a lot of basic stuff is missing or simply just too low quality. From how you configure stuff to how you install and manage extensions to how you manage configuration across workstations. This isn't a new problem and the fact that Emacs has struggled with this for too long suggests that you won't see this solved in, for instance, GNU Emacs any time soon.

If you are a developer today learning VS Code is a better investment than learning Emacs. It has nothing to do with disliking Emacs - it is a simple matter of what environment manages to attract a sufficiently large active developer base for developing extensions and tools.

As I said, I still love Emacs. But evolution is making it a dead end.

>If you are a developer today learning VS Code is a better investment than learning Emacs.

That is something which only time will show. Over the course of my life I've seen several hyped editors and IDE come and completely vanish: TextMate, Sublime, Atom, Eclipse, Netbeans. I have zero confidence that VSCode will still be hot in 10 years, especially given their poor choice of technology to write VSCode in and that MS is the sole driver of the project and can do or throw it out as it pleases.

A new developer is of course free to choose any tool, but in my experience every editor knowledge which is not vim or emacs can be treated as disposable, since it will not pay off in the long term. Thus, I would treat VSCode the same way as an IDE: use it for things which work out of the box and avoid investing time in any kind of fine-tuning. But certainly, if the experience out of the box is sufficient to solve problems, why not use it? An editor is not a religion and more than one or two can be used simultaneously. My "glue" for different editors are vim-keybindings. I use them in Emacs, IDEA and used them in VSCode, when I still had an usecase for it.

I agree that the choice of implementation language was unfortunate.

Which is a statement that is equally valid for VS Code and Emacs, so you get to interpret that any way you like.

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.

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.

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.

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.

The alternative could be vi/nvi.

or elvis

https://en.wikipedia.org/wiki/Elvis_(text_editor)

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.

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)

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.

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.

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

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?

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.

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.

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.

Reply on news.ycombinator.com