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

251–260 of 267 posts

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

#251

Post by wiz21c »

ranaexmachina wrote: post #241
wiz21c wrote: post #182

Earlier quoted context omitted.

Overleaf allows you to work with several authors at the same time on the document. I was skeptical (after all, git allows that too). But after using that feature, well, it is just the killer thing. Now Overleaf doesn't add much on top on my own Latex installation. But the collaborative thing is just spot on (much like Google docs which I have discovered not a long time ago; same analysis : not that good presentation…

In my experience, Overleaf is actually awful for collaboration. Maybe my workflow is weird, but I tend to look at the diffs after my colleagues make changes. Also, we mainly use pull requests to add to our papers. This way, everyone can see and comment on changes. This kind of workflow is not really usable with Overleaf. Overleaf uses Git in the background, but every commit is named "changes on Overleaf" and the indi…

my workflow is different : we use voice chat to share and we edit collaboratively. Both these allow to actually work together and, more importantly, think together.

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

#252

Post by Tainnor »

tincholio wrote: post #239
Tainnor wrote: post #222

Earlier quoted context omitted.

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

> - when you encounter an error you have to enter "X". if you're using latexmk, you have to enter "X" multiple times Seems like you haven't heard of the "-interaction=nonstopmode" flag... If you're pressing X for each error, this will be life-changing.

Thanks, I have actually never heard of that.

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

#253

Post by johannboehme »

BeFlatXIII wrote: post #203

As someone who is a basic vim editor and uses the occasional Idea IDE, would it be worthwhile to invest myself in an emacs environment?

Not an answer but an anecdote: I am a long time vim user and wanted to learn clojure. Everyone recommended emacs, because of it's lisp and repl abilities and ease of use.

I spent two weeks learning emacs, elisp and the ecosystem. I was not able to get it to run via WSL with Frontend integration (shadow-cljs). Several help channels where unable to assist, since they all just blamed other parts of the environment (WSL, the LSP, DoomEmacs or the clojure plugin..)

I eventually got it to work, just to find out, that vims minimal plugins that i used (vim-iced, sexp, and a Coc plugin) where faster, more reliable and better to use than the emacs counterparts.. and they just worked, without any troubleshooting.

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

#254

Post by blacktriangle »

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…

But look, you've been using Emacs for 10 years! That's ages in software time these days.

The downside to software that lasts a long time is that yes, vocabulary will change. So now you change to CUA compliant keybinds. Then the world changes again and now you're constantly chasing whatever is new and disrupting your users by throwing your whole "can use for 10+ years" value prop out the window.

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

#255

Post by lytefm »

BeFlatXIII wrote: post #203

As someone who is a basic vim editor and uses the occasional Idea IDE, would it be worthwhile to invest myself in an emacs environment?

I'd say that learning vanilla Emacs and all the internals is probably not worth it.

But if you'd like to try out Emacs, have a look at Doom Emacs or Spacemacs - then you can still use vim keybindings for most stuff.

And just activating some of the included modules will give you enough to easily try out some of the best emacs packages out there.

I wouldn't bother setting up emacs for programming, but org-mode is amazing.

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

#256

Post by githubalphapapa »

_huayra_ wrote: post #145
Jtsummers wrote: post #21

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…

> trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.

Please try `org-ql` and `helm-org-ql`; these newer search tools perform better than `org-rifle` and generally supersede it.

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

#257

Post by githubalphapapa »

kqr wrote: post #231
samatman wrote: post #204

Earlier quoted context omitted.

I understand what you're saying, but I'm not making a mental mistake, and I'm not confused. I'm working on something which takes the -mode out of org and builds something meaningfully similar which isn't wedded to emacs. > But you shouldn't say org "lives in an editor" Except it does. If you want to use the org format in any sort of full-fledged way, you're going to be doing it in Emacs. Which, ok, it's a platform. B…

I admire your efforts and passion on the subject. I myself would like the Org format more widely supported in other environments. (I personally do run Emacs headless in a couple of CI processes to get at its superior Org support, but it's hard to convince others of its greatness!) > You seem to be taking the old joke "Emacs is a great operating system which just needs a good text editor" a bit too seriously here. Not…

FYI, there are a variety of Org parsing libraries outside of Emacs. Some of them even appear to be robust and well-developed. I collected a list here: https://alphapapa.github.io/org-almanac/#Parsing

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

#258

Post by githubalphapapa »

Kinrany wrote: post #198
na85 wrote: 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?

Pandoc can read from and export to Org format. As well, there are a number of Org parsing libraries in other languages; see https://alphapapa.github.io/org-almanac/#Parsing

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

#259

Post by githubalphapapa »

andi999 wrote: post #209
kqr wrote: post #187

Earlier quoted context omitted.

I'm not that surprised. It's the sort of thing you won't appreciate until you've tried it. Ask people what they want, and they'll tell you "a faster horse". Ask people what they want, and they'll tell you "a better editor" so that's how Emacs markets itself. Unless you've tried one, "a car" or "a fully dynamic, programmable editing environment" is just not on people's minds.

I don't understand it. Any examples how to do that in practice? (used emacs for a couple of years, but just as a editor)

The question is almost like asking a fish to describe water. It's the sudden lack of it that produces a really clear example. :)

Anyway, here's a random example that comes to mind: I have some sexps in a Lisp file and I want to sort them alphabetically. Each sexp (usually a top-level form, but not necessarily) usually spans multiple lines, so line-sorting won't do it. Since they may be top-level forms, there may be comments between them that would lose their context if their position relative to sexps were lost, so comments need to "stick to" sexps they're above.

How would you solve this in a random text editor?

In Emacs, I would develop a command that does what I need. At each stage of the development process, I evaluate the command's definition, and it's instantly available to be used and tested. I could even test the function on its own definition, if I wanted to be silly (undoing the sorting after testing, of course).

When I'm done, I save the command definition to my configuration, and it's now a permanent tool in my toolbox. I didn't have to recompile the editor and start a new process, nor did I have to submit a patch to an upstream and ask for it to be merged. Similarly to a carpenter (forgive me if it sounds silly), my editor is my workbench, and as wood is malleable, so is my editor.

So, here's the command I came up with (maybe not the prettiest implementation, but maybe not the worst): https://github.com/alphapapa/unpackaged.el#sort-sexps And using Emacs and Org mode, I publish it into this "unpackaged" package, which I then install into my configuration as a package, and other users can then easily install it into theirs, too.

I don't know of any other editor that can do all of this, certainly not so easily.

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

#260

Post by githubalphapapa »

hollerith wrote: post #184
axiosgunnar wrote: post #109

Earlier quoted context omitted.

VSCode allows you to write in Javascript what Emacs allows you to write in elisp. What's missing?

If you're not a professional web developer, spending 80 hours learning how to modify Emacs will give you much more control over Emacs than the control you get from spending 80 hours learning how to modify VSCode. Or ar least that was my experience though I was in my prime when I learned Emacs decades ago and almost 60 years old when I spent the 80 hours learning how to modify VSCode. (I feel I have barely scratched t…

> Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.

Emacs can certainly apply red squiggles and many other rich text formatting, through the use of faces (which is how all syntax highlighting is implemented). Emacs also has a rich text-properties API through which any part of a buffer's text may be propertized with metadata. And it also provides overlays, which "overlay" text, also optionally with additional properties, without modifying the buffer text itself.

Together, these features are used to implement GUIs such as the Customization system with widgets, buttons, clickable links, collapsible sections, etc., as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.

Post reply on HN