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

171–180 of 267 posts

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

#171

Post by gumby »

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 find the overhead of selecting a pop up, having it appear, often then using the mouse to select something, then pressing do is just clumsy compared to the low overhead command structure of Emacs. Search is a primary cursor move operation, for example.

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

#172

Post by tome »

iLemming wrote: post #83
playcache wrote: post #8

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…

:-o Can you share links to the packages you use to do these things?

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

#173

Post by alex_smart »

resoluteteeth wrote: post #140
lkrubner wrote: post #137

I'm currently hiring 5 software developers for a startup that I'm consulting with. On some level, I'm aware that it would help team cohesion if we could all use one text editor. But for the most part, it's a decision that I leave to each developer, as it is a decision that can be left to individuals. If we were going to use a language such as Clojure, where the whole eco-system tends to use emacs and offers examples…

> I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp). Is there some reason you don't consider this to apply to vs code?

The process of writing Emacs-Lisp: open the scratch buffer, write a function and eval. The process of understanding what any part of the editor is doing: C-h f , read the documentation and link to the source is again right there. You can go to the source, set up a breakpoint, step through the code, understand it and even modify in place if you feel like it.

There is no other environment I know of, apart from smalltalk, that makes the process of extending and customizing the environment that frictional-less.

I have tried to understand the process of extending vs code, but it seems to require a lot of ceremony.

https://code.visualstudio.com/api/get-started/your-first-ext...

For instance, everything needs to belong in an extension, and you run the extension in different instance of vscode rather than the one in which you are editing the extension, which you have to reload/restart everytime you change the extension's definition.

The difference in experience is similar to the difference in experience in REPL-driven development in an interpreted language v/s developing in a compiled language with the whole edit/compile/run cycle.

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

#174

Post by monsieurbanana »

lkrubner wrote: post #137

I'm currently hiring 5 software developers for a startup that I'm consulting with. On some level, I'm aware that it would help team cohesion if we could all use one text editor. But for the most part, it's a decision that I leave to each developer, as it is a decision that can be left to individuals. If we were going to use a language such as Clojure, where the whole eco-system tends to use emacs and offers examples…

Calva on vscode is probably the most beginner-friendly way to start doing Clojure, and has a lot of features thanks to the use of clojure-lsp.

It even includes a quick interactive tutorial for Clojure and structural editing (which is something mandatory to really give lisps a try, IMO).

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

#175

Post by kqr »

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…

The sticking point for me is that if I discover some functionality is missing, I can add it to Emacs on the fly with often just a few (1--25) lines of Lisp.

So there's several tiers to this convenience:

1. Does it do the obviously important things out of the box, or with easily installed add-ons? For most editors, this is yes.

2. Does it do the little things out of the box, or with easily installed add-ons? For some editors, this is yes.

3. If none of the above, can you create the thing you need as an add-on without breaking your step, almost as part of what you were already doing? To get to this point it takes a very dynamic system like Emacs.

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

#176

Post by alex_smart »

SquibblesRedux wrote: post #155

I used to use Emacs for large files and vi for small, quick edits. I am now using VS Code for large files and still vi for quick edits. The single feature that got me to switch from Emacs to VS Code was the ability to use a mouse for navigation and selection. (My Emacs and vi usage was always in a terminal.) I had tried XEmacs for a while, but found it too aesthetically displeasing. I would be happy to return to Emac…

> I had tried XEmacs for a while, but found it too aesthetically displeasing.

Why would you even bother with a fork whose last release was 12 years ago? :\

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

#177

Post by kubanczyk »

zibzab wrote: post #90
ta_emacss wrote: post #49

Earlier quoted context omitted.

i just copy the .dot file and launch emacs. in a few minutes without touching anything i have the same environment.

Yeah, that's me 3-4 years ago. Then I ran emacs on a new machine for months before realising my .emacs refused to load correctly because I had not installed the correct fonts and cscope. So dot files are not foolproof. (Throwaway account to discuss emacs? Do you live in a vim-only country?)

Virgin Islands, cough.

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

#178

Post by AtticHacker »

rrock wrote: post #119

One of the major things that keeps me in Emacs is the keyboard macros. Being able to record a key sequence is something that I use regularly, and I don’t think the major competitors have it yet.

Keyboard macros are great! Although after discovering multiple cursors I found less use for them. 90% of (my) use cases were easier to solve using MC rather than keyboard macros.

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

#179

Post by ernst_klim »

nextaccountic wrote: post #152
ellyagg wrote: post #144

Earlier quoted context omitted.

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…

About point 2, this can be done with vscode using this extension https://marketplace.visualstudio.com/items?itemName=ms-vscod... This explains it https://code.visualstudio.com/docs/remote/ssh-tutorial There's a similar extension to work within containers https://marketplace.visualstudio.com/items?itemName=ms-vscod...

Emacs has TRAMP as well out of the box, but for some reason they want o launch a lightweight cli instance of emacs on the serverside, which VSCode can't do.

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

#180

Post by kqr »

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…

Thinking of Org as "living in an editor" is the mental mistake that leads to that confusion.

Org is a full blown task manager and note taking application, written for the Emacs platform.

Emacs is a platform much like the JVM. Someone happened to write Minecraft for the JVM, and someone happened to write Org for the Emacs platform.

People have written editors for Emacs (evil-mode is one I like) just as people have written search engines for the JVM (I use ElasticSearch at work.) But you shouldn't say org "lives in an editor" any more than you would say "Minecraft lives in a search engine". They're just two different applications built on the same platform.

Granted, the Org application reuses much more code and integrates better with the editors available for Emacs, making the comparison a bit odd, but I'm sure there are examples like that for the JVM too.

Post reply on HN