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

151–160 of 267 posts

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

#151

Post by danShumway »

tgbugs wrote: post #141
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

Nice, thanks for linking!

I'm excited to see stuff like this, I think a formal grammar would open a lot of doors for more tools to get built around the format.

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

#152

Post by nextaccountic »

ellyagg wrote: post #144
stouset wrote: post #95

Earlier quoted context omitted.

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

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

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

#153

Post by neolog »

danShumway wrote: post #150
neolog wrote: post #135

Earlier quoted context omitted.

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

The other thing I meant to say, it's too easy to accidentally mess up an org file while editing it. Manual errors are the most common source of the corruption you mentioned, IME. That doesn't happen with structured editors like paredit.el or Word or Roam.

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

#154

Post by RHSeeger »

I use IntelliJ every day, to program Java (and some other things) for work.

I use Emacs every day, to do other things for work. For quick, powerful text editing, there's just nothing that compares. For many things, it's faster to start up Emacs, do it, and close it... than it is to just do it in IntelliJ, which I already have open.

Different tools for different things.

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

#155

Post by SquibblesRedux »

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 Emacs if there was a front end that worked well and was standardized across all windowing systems (Linux/Mac/Windows).

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

#156

Post by jrm4 »

na85 wrote: post #69
blacktriangle wrote: post #19

Earlier quoted context omitted.

Emacs gives you back what you put into it. There's absolutely nothing wrong with using it at a very basic level, and getting to that point takes minimal time. There's a 15 minute interactive tutorial linked from the start screen at which point you're fully able to get work done. You can then reach for other goodies like Org, Magit, various interactive shells, tetris, whenever you want/need. I probably used Emacs for…

I say this as a 10+-year emacs user: The "15 minute tutorial" is emblematic of everything wrong with emacs and its community. Just make CUA-compliant keybinds the default, and you'd draw in so many more users. The ideal tool is one that you can start using right away, and incrementally dig into as you descend into madness/poweruserdom. The idea of having to waste 15 minutes before you can even start working in emacs…

Yup. I personally bounce between Vim and many CUA-compliant Linux editors for editing text, and Zim-wiki for "what org-mode" can do:

I gave Emacs+Org-mode about a year or so, and I saw a whole lot to like, but lack CUA-compliance is literally the thing that stopped me, I just use too many other programs that aren't Emacs for this to work.

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

#157

Post by ARandomerDude »

jrochkind1 wrote: post #51
User23 wrote: post #15

Earlier quoted context omitted.

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!

For most woodworkers, I'd say the analogy is closest to making "plugins" for existing tools. They require a little knowledge (which easily obtained on YouTube), and can greatly increase your ability to use the base tool.

One example is a table saw sled, which helps you make clean, repeatable, 90º cuts. It's one of the most useful "plugins" you can have for your table saw, and relatively easy to make. Making the actual table saw, on the other hand, would be expensive and very difficult, and would require knowledge of many fields (metal working, electrical systems, etc.).

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

#158

Post by yewenjie »

tgbugs wrote: post #141
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

While org-mode parsers are being written in many languages, what is the best currently available alternative to the org-element API in any other language than Emacs Lisp?

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

#159

Post by lkrubner »

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?

VSCode is very good. I could write something about Lisp being homoiconic, also I don't know the VSCode equivalent of "advise", macros rewriting core functions of the editor, but I'll let someone else make that case, if they feel like it.

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

#160

Post by stainforth »

ellyagg wrote: post #144
stouset wrote: post #95

Earlier quoted context omitted.

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

Any good videos as examples of the window partition practice?
Post reply on HN