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

111–120 of 267 posts

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

#111

Post by bborud »

pkulak wrote: post #18

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

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.

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

#112

Post by bsder »

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…

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.

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

#113

Post by flurie »

chipotle_coyote wrote: post #106
taeric wrote: post #91

Earlier quoted context omitted.

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.

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

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

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

#114

Post by taeric »

flurie wrote: post #113
chipotle_coyote wrote: post #106

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. :) 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 th…

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

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

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

#115

Post by danShumway »

neolog wrote: post #98
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…

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.

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

#116

Post by PaulDavisThe1st »

axiosgunnar wrote: post #109
PaulDavisThe1st wrote: post #67

Earlier quoted context omitted.

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

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

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

#117

Post by andrepd »

CalChris wrote: post #33
cpach wrote: post #14

Earlier quoted context omitted.

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.

>installation and configuration

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

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

#118

Post by ThinkBeat »

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.

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

#120

Post by zrail »

anyfoo wrote: post #64
chipotle_coyote wrote: post #56

Earlier quoted context omitted.

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

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

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