Live data from Hacker News

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

karl-voit.at

71–80 of 267 posts

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

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

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

#72
post #40

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 g…

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

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

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

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

#73
post #57
post #28

Earlier quoted context omitted.

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)

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

#74
post #62
post #3

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

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

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

#75

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…

> 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

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

#76
post #2

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 s…

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.

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

#77
post #32

Earlier quoted context omitted.

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…

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

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.

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

#78

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…

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.

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

#79

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 e…

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?

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

#80
post #40

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 g…

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 :)
Post reply on HN