Live data from Hacker News

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

karl-voit.at

221–230 of 267 posts

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

#221
post #58

Earlier quoted context omitted.

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

Can it be used without elisp?

It can be used as a "dumb" format and even then it's superior to e.g. markdown.

The real magic requires code of course, but it doesn't have to be elisp.

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

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

What is your criticism of LaTeX? I am a research mathematician, and I and essentially all my colleagues are LaTeX users. To me it feels like the correct tool for the job; the only widespread criticism I've heard is that it doesn't produce documents accessible to the blind. (And I've heard that work on this is in process.) I tend to be unsympathetic to criticism that a tool is "outdated"; if a tool is right for the jo…

I'm a heavy LaTeX user, but LaTeX manages to be simultaneously amazing and completely insane.

Let's get started with some negatives (the positive are well known):

- Recompilations needed. Can be mitigated by latexmk, but still.

- Choice of latex, pdflatex, xelatex, lualatex ... and documents compiled with one may or may not compile with another

- packages that are incompatible with each other in odd ways

- when you encounter an error you have to enter "X". if you're using latexmk, you have to enter "X" multiple times

- math commands are not structure-based but presentation based, despite LaTeX's (otherwise well executed) posturing of separating content from styling. If you want to change the alignment of your equations or the size of the integrals sign or just slightly tweak the appearance of the | sign in {x^2 | x € R }, be prepared for a lot of rewriting (some of this can be alleviated by defining new commands, but I don't know how many people actually do that)

- Math LaTeX input is basically unparseable in the sense that it is not really possible to take some latex math code and convert it into some actual meaningful structure (this is a corollary of the above point). Given the ubiquity of LaTeX-style math even in a range of other contexts (e.g. KaTeX), this is a bit of an issue. It's possible to do a best effort implementation that sort-of works, but it's always gonna come up short

- Error messages: "Missing $", thanks

- Outdated defaults. Unicode should just work by default.

I think I could go on, but you get the point.

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

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

One other thing about VSCode being an Electron app -- it is by far the snappiest and most responsive and least bad memory-wise Electron app I've used. This isn't like Slack or Discord. It's like magic what they've built on Electron, one of these days I'll dig into the code to see how they did it.

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

#224

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…

> 1. A good concurrency model. This is definitely the biggest pain point, especially as people go to expand their use of Emacs (e.g. with Doom, adding more modules and integrations, one has to be careful to lazily evaluate config blocks to avoid loading everything at startup). Even without such extensive configs, working on a large repo with a slow I/O (e.g. some network mount) with magit will cause large pauses once…

Native comp was merged to the mainline a few months ago. It's behind a config flag `--with-native-compilation`. There is not yet an official release that includes it, but it's fairly common for people to run Emacs built from the mainline source.

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

#225
post #64

Earlier quoted context omitted.

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…

Using non-standard notation for describing keyboard shorcuts doesn't help.

This is the notation that emacs has been using forever, and also displays to the user, so every user should be well comfortable with it. It even says “Press C-x C-c to exit emacs” at startup.

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

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

> your LSP syntax highlighting could go to roughly 99% accuracy on VSCode.

? LSP, the protocol, doesn't (yet) have a syntax highlighting aspect.

And doesn't VSCode still use TextMate grammars? https://code.visualstudio.com/api/language-extensions/syntax...

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

#227
post #225

Earlier quoted context omitted.

Using non-standard notation for describing keyboard shorcuts doesn't help.

This is the notation that emacs has been using forever, and also displays to the user, so every user should be well comfortable with it. It even says “Press C-x C-c to exit emacs” at startup.

It's still non-standard, and is yet another barrier to adoption.

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

#228

Earlier quoted context omitted.

Was there any resource that help you get over the understanding hurdle?

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…

As someone who's very comfortable writing Elisp and reading the Emacs documentation, I must disagree. Emacs documentation is comprehensive and it is very clearly written, some of the best I've seen -- but as reference documentation.

It is still somewhat short on examples/practical how-tos. You need to be comfortable with the system and have some idea what you're looking for. A great example is [`display-buffer-alist` actions][0]. Thoroughly described, with appropriate cross-linking, but still kinda [hard to really grok without resort to existing code][1].

[0]:https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... [1]:https://www.reddit.com/r/emacs/comments/cpdr6m/any_additiona...

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

#229

Earlier quoted context omitted.

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

Again, as in your GGP post, you mention set up time. Have you seen the myriad comments on this page to the effect of "Just use it as-is!", and what do you think of that?

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

#230
post #215

Earlier quoted context omitted.

> The only thing Overleaf adds here is a button and a 10x compilation time overhead. Overleaf removes the need for local install. A full MacTex.pkg install is 4.4GB. I've lived in LaTeX for more than 30 years, and I love the ability to edit docs from any browser.

4GB today is not that much. Current OpenBSD and NetBSD install recommend 2-3GB at minimum for a base OS and 10-16GB for a confortable usage (installing a bunch of pkgs/ports, swap partitions, and so on).

Maybe it's just me, but 4.4 GB does feel like a not insignificant amount of space for something I don't have to install locally. Or for people that use it rarely.

I'm not a huge fan of Overleaf, mind you, but I agree with those that say it does have its uses. The easy collaboration for people that don't like -- or don't get how -- to use git. I wish everyone I collaborate with liked git...

Post reply on HN