The Emacs Lock-In Effect or the Emacs Sunk Cost Fallacy • Hacker News Board

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

#131

Post by chipotle_coyote » Sat, Aug 07, 2021, 1:54 AM UTC

taeric wrote: post #107

chipotle_coyote wrote: post #106

Earlier quoted context omitted.

Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :) Even so, the "sort lines" example works well with even the out-of-the-box completion. But, Emacs sometimes has its own language for things. If I didn't know th…

Right, I was assuming something like helm or ivy. I only have experience with helm. I should also highlight that I think folks should lean on apropos way more than they typically do.

Apropos is definitely a great feature!

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

#132

Post by yissp » Sat, Aug 07, 2021, 1:56 AM UTC

flurie wrote: post #113

chipotle_coyote wrote: post #106

Earlier quoted context omitted.

Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :) Even so, the "sort lines" example works well with even the out-of-the-box completion. But, Emacs sometimes has its own language for things. If I didn't know th…

> Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :) This is not quite true. The minibuffer, which is what vanilla Emacs uses for M-x command completion, has a set of completion styles, ordered by preference. Y…

This is a helpful tip, but I feel like it kinda reinforces the broader point about emacs's lack of discoverability. I've been using it for years and wasn't aware of this feature until today.

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

#133

Post by dleslie » Sat, Aug 07, 2021, 2:04 AM UTC

BeetleB wrote: post #50

dleslie wrote: post #40

Every so often I would start my Emacs config over from scratch. I might port over some old defuns from the previous, eventually, but I would always endeavour to try the latest tools and best language configurations. Consistently I found myself using Emacs and sticking to it because it offered the best developer experience. And then came Microsoft's Language Server Protocol. Emacs was late to adopt it, and still has g…

This makes sense primarily if you assume people who stick to Emacs do so because of its SW development capabilities. As a person who hangs out amongst Emacs communities, this profile is not the norm.

I used Emacs for software development and git interfacing.

I tried organizing my knowledge with org-roam. I tried maintaining org todo lists. I tried having an active org-agenda. I tried...

But what I do more than eight hours a day, every week day, is read, write and debug code. Emacs was once the best, it is now not so great.

I've been using Emacs for over two decades, now. It's painful that it fell behind so quickly.

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

#134

Post by teunispeters » Sat, Aug 07, 2021, 2:06 AM UTC

I haven't sunk much "effort" in it. I use it as a syntax highlighted code editor that can load multiple effectively unlimited size files without usually too much issue, recover cursor positions on restart and doesn't suddenly pause and lock up when scrolling. Oh and I need page up/down, home and end of a line as well as doc, and reasonably good cut and paste.

Note : to date, this means it has no competition, except in much more limited editors, like vi and jed. None at all. So far every other package has lost out. And when it's gotten close in capability, it's required it's own walled gardens and can't handle project structures outside of its own.

So yeah, as yet there is no competition to emacs. Maybe someday there will be. Some givens: - it cannot be nodejs based. Has halting randomly, random crash, inability to save and recover and excessive CPU and memory consumption, even with other features covered. - it cannot be one of the many code suites. They all (so far) require projects to be in their Pet Project Format. Useless if one's working on corporate git trees (or other repos), or for that matter linux kernel. - it needs to support many code languages. I do work with lisp, python, bash, C, C++, C#, Java and who knows what else. Just not elisp, not if I can help it ;) - it needs to coexist with the rest of the environment. Cut and paste has to go between apps, not just itself. (you'd think this was common, but eclipse showed me otherwise) - It has to be either UTF8 capable, or binary. Or both.

I mean I've locked emacs up a few times - always with particularly large files ... but this is very rare. oh yeah, emacs user since 1991. I've tried Visual Studio (still have hope on that one, should their linux support finally be good), Eclipse and family, Atom, Code (see Visual Studio), vi, jed, edlin, wordpad, borland C++, turbo pascal and too many other better forgotten systems.

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

#135

Post by neolog » Sat, Aug 07, 2021, 2:09 AM UTC

danShumway wrote: post #115

neolog wrote: post #98

Earlier quoted context omitted.

What is the advantage of plain text? Other than that Emacs is bad at editing other file types.

The ability to hand-parse/edit outside of Emacs, lower risk of data corruption, the ability to read the data visually even if printed or displayed raw. It's nice to be able to `cat` an org file to a terminal or `grep` from the command line, and if a file gets corrupted or messed up it's pretty easy to recover the data. So basically: transparency, flexibility, portability. Plain text is great, it's just not enough on…

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

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

#136

Post by Filligree » Sat, Aug 07, 2021, 2:14 AM UTC

remexre wrote: post #97

eulgro wrote: post #47

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). $ latexmk -pdf main.tex How hard is that? The only thing Overleaf adds here is a button and a 10x compilation time overhead. > I don't always remember what that magic meant. Overleaf mostly won't help you here, unless I'm mistaken. I don't mean to be aggressive here, I just don't get th…

How do you do package (version) management for LaTeX? There's more than a few documents I've come across that won't build on my system, giving often-indecipherable compilation errors. Overleaf at least ensures everyone involved is using the same environment without needing to ship a Docker container or the like, or try to pin down versions.

Nix has a decent solution here, i.e. turn the document into a nix derivation.

  with import  {};
  
  pkgs.runCommand "cv.pdf" rec {
    src = ./cv.tex;
    bin = with pkgs.texlive; combine {
      inherit scheme-medium collection-latexrecommended collection-fontsextra
              moderncv etoolbox;
    };
    buildInputs = [ bin ];
    allowSubstitutes = false;
  } ''
    ln -s $src cv.tex
    latexmk -pdf cv.tex
    mkdir $out
    mv *pdf $out/
  ''

These days I'd probably use flakes to pin down the latex version.

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

#137

Post by lkrubner » Sat, Aug 07, 2021, 2:27 AM UTC

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 in emacs, then I might try to introduce emacs, but the opposite is also true: the feeling that developers should learn emacs is one of the things that makes me wary about recommending Clojure to clients, even though Clojure is the only language I use in my personal projects.

But for this current client I think we will mostly be working with Javascript, so I think most of the people we hire will be happier with their IDE of choice, or with Sublime.

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

But it seems unlikely that anything like that will ever exist, so I go on using emacs, but I don't recommend for any clients.

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

#138

Post by flurie » Sat, Aug 07, 2021, 2:31 AM UTC

chipotle_coyote wrote: post #129

flurie wrote: post #113

Earlier quoted context omitted.

> Even the current version of Emacs doesn't do fuzzy completion for M-x commands, just start-of-token completion; out of the box the completion is a little basic. I know there are packages which make this a lot better, but you have to know about the packages. :) This is not quite true. The minibuffer, which is what vanilla Emacs uses for M-x command completion, has a set of completion styles, ordered by preference. Y…

Interesting! It still doesn't quite shake my suspicion that the best documentation for Emacs is "find somebody else who knows more about Emacs than you do," but to be fair that's not unique to Emacs. :)

Honestly, I wouldn't have been able to tell you this two weeks ago. I know all this now because completions in a language I don't normally use felt off somehow, and figuring out the solution involved going deep on how Emacs handles completions. That ended up not being relevant to the root cause, which was a change in Doom causing snippets to be overvalued in LSP completion, but at least I know a lot more about vanilla completion methods now!

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

#139

Post by _huayra_ » Sat, Aug 07, 2021, 2:35 AM UTC

alex_smart wrote: post #84

_huayra_ wrote: post #79

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…

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 stuff), or how to handle async code (e.g. how magit runs a command, and then refreshes the buffer after it completes). I have this fluency to some degree for the languages I'm paid to produce code in (e.g. C++, to some extent; Stroustrip himself said his knowledge of C++ was "7 out of 10 on a good day" or something like that), but these last few advanced features have been a tough nut to crack in elisp.

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

#140

Post by resoluteteeth » Sat, Aug 07, 2021, 2:36 AM UTC

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?