Live data from Hacker News

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

karl-voit.at

161–170 of 267 posts

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

#161
post #112
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 i…

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.

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

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

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

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

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.

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

#164
post #123

Earlier quoted context omitted.

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

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

#165

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…

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

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.

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

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

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.

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

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

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

#168
post #167

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

> My Emacs was heavily customized

> several hundreds of lines

amateur

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

#169

Earlier quoted context omitted.

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

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

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

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

#170
post #167

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

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.

Post reply on HN