Live data from Hacker News

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

karl-voit.at

51–60 of 267 posts

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

#51
post #15
post #4

Earlier quoted context omitted.

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

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

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

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

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

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

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

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.

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

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

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

#55

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…

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

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

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

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

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

#57
post #28

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

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.

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

#58

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…

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

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

#59

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…

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.

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

#60
post #55

Earlier quoted context omitted.

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…

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

Post reply on HN