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

#231

Post by kqr » Sat, Aug 07, 2021, 7:41 PM UTC

samatman wrote: post #204

kqr wrote: post #180

Earlier quoted context omitted.

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

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 only do I take it too seriously -- it's not even a joke in my book. Let's agree to disagree on that bit and you can spend your time better than arguing about it!

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

#232

Post by bborud » Sat, Aug 07, 2021, 7:58 PM UTC

lycopodiopsida wrote: post #220

bborud wrote: post #108

I've used Emacs for 32-33 years and I can't even imagine how many lines of code I've written in it. Every 2-3 years since the early 2000s I would try an IDE for 1-2 months, but then go back to Emacs again because I was simply faster in Emacs and because the IDEs were supremely ugly, resource intensive and slow. A few years ago things started to change. IDEs started to become less clumsy. Less horrible to de-fang to t…

To summarize your post: it is OK to use another editor, if it has better support for the language you you want to write your code in. I see no drama here: I haven an emacs instance always running as my to-go editor but would start IntelliJ IDEA if I have to write even a single line of code in Java. Because it is so much better. Even if I would always reach for emacs if I have to write in Clojure or Racket. Would I st…

It was my development tool of choice for decades. And it very much did the job of IDEs better than any IDE. But it no longer does. In part because IDEs became better editors.

I’d love to use Emacs. But it is more work to use it now than just a decade ago.

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

#233

Post by alex_smart » Sat, Aug 07, 2021, 8:51 PM UTC

b3morales wrote: post #228

alex_smart wrote: post #84

Earlier quoted context omitted.

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

Hmm, window management is just one of those corners of emacs I have not gotten around to grokking yet. Yes, I am annoyed by it, but I usually keep things sane by just having upto 3 windows at a time and just manually fix things (usually just winner-undo) when emacs functions do whatever with the windows they like to do.

In my opinion, usually the manual contains sufficient examples and motivations to explain the topic, apart from the detailed reference documentation.

Even for your example, there is this page, which seems to give an overview of the topic. (Granted I haven't really delved in these parts of Emacs, so it is not possible for me to know whether the page does a good enough job.)

https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

>hard to really grok without resort to existing code

But the code also ships with emacs, so technically...

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

#234

Post by opan » Sat, Aug 07, 2021, 10:22 PM UTC

frosted-flakes wrote: post #186

anyfoo wrote: 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.

I found it handy and I often use it outside of emacs as well when describing shortcuts to people. Mainly C-something for ctrl.

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

#235

Post by jeffyang » Sun, Aug 08, 2021, 4:35 AM UTC

I use both Visual Studio and Emacs. In general Visual Studio does a pretty good job and it is my day to day editor. But there are some things that it's simply not worth bothering with in Visual Studio.

The problem with most editors is that every buffer and every command is different. Code is different than the terminal which is different than your source control. Sorting text is different than copying text is different than formatting text. That means every new thing you want to do, even if it's small, requires you to learn how to do it the way that tool wants you to do it.

In Emacs, every buffer is the same. Which means I can do all sorts of mini workflows without learning anything new. I can navigate the buffer the same way and I can copy text the same way. I can run arbitrary linux commands from my scratch buffer on buffers on multiple machines and massage the output and put it in my code buffers. I can run a macro to repeat that 1000x. Then I can tweak it slightly and run it another 1000x. I don't need to learn anything specific to my editor. I can whip this up in a minute then move on with my day because it's a one off.

Yes, sort lines is available in all editors. What if you wanted to sort all the import statements in every file? In Emacs you can do a quick macro to do that. It would take you a couple of minutes MAX. You wouldn't have to even think. All because sort-lines is text that you can copy and paste. In Visual Studio... I don't even know what I would do... probably find a plugin or write a program. Imagine you found a plugin. Then imagine you didn't want to sort ALL imports, there's one import you always want at the top. Trivial to change in Emacs, not so trivial for a plugin.

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

#236

Post by jeffyang » Sun, Aug 08, 2021, 5:03 AM UTC

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 thing with Emacs is that sort-lines is a string you can copy and paste into a buffer, whereas in Visual Studio it's a command that you have to execute.

Disclaimer: I don't know Visual Studio that well. Still, I suspect what I'm writing is true.

I wrote about this in a separate comment: https://news.ycombinator.com/item?id=28104243

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

#237

Post by [deleted] » Sun, Aug 08, 2021, 5:59 AM UTC

anthk wrote: post #215

robotresearcher wrote: post #126

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

[deleted]

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

#238

Post by tincholio » Sun, Aug 08, 2021, 7:28 AM UTC

robotresearcher wrote: post #126

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…

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

I've used LaTeX for about as long as I've used Emacs, and really, the thought of editing LaTeX from my browser is rather painful. You can still use Overleaf via git, though admittedly the experience isn't as smooth.

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

#239

Post by tincholio » Sun, Aug 08, 2021, 7:32 AM UTC

Tainnor wrote: post #222

impendia wrote: post #195

Earlier quoted context omitted.

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

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

#240

Post by e3bc54b2 » Sun, Aug 08, 2021, 8:20 AM UTC

neolog wrote: post #153

danShumway wrote: post #150

Earlier quoted context omitted.

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

Word is the worst for accidental manual edits screwing the whole document. I cannot count the number of tines I've watched my classmates manually adjusting dozens of graphs and images in as many pages one by one because they shifted something in inititial pages.