Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

karl-voit.at

Post reply on HN
Print view View original

141–150 of 267 posts

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

#141

Post by tgbugs »

danShumway wrote: post #9

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

> 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

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

#142

Post by ilovecaching »

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.

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

#143

Post by Jtsummers »

yissp wrote: post #132
flurie wrote: post #113

Earlier quoted context omitted.

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

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.

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

#144

Post by ellyagg »

stouset wrote: post #95
anyfoo wrote: 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…

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

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.

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

#145

Post by _huayra_ »

Jtsummers wrote: post #21
grae_QED wrote: post #12

Earlier quoted context omitted.

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

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

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

#146

Post by singingfish »

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.

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

#147

Post by _huayra_ »

tsimionescu wrote: post #29
grae_QED wrote: post #12

Earlier quoted context omitted.

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.

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

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

#148

Post by komali2 »

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

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

#149

Post by komali2 »

xenodium wrote: post #75
samatman wrote: post #22

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…

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/

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

#150

Post by danShumway »

neolog wrote: post #135
danShumway wrote: post #115

Earlier quoted context omitted.

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…

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

Post reply on HN