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

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 individual commits do not really make much sense. In addition, everything is immediately put into the master branch and there's no way to summarize or group changes (like with commits and/or pull requests).

My next problem is, that Overleaf just uses latexmk so if you have some code to generate graphics or tables, you have to compile and add them manually all the time.

I used to use Emacs for all of those things and more.

I think I used Emacs as my email client for around 20 years. There was never really any email client that did IMAP well and storing mail locally doesn't work when you have a couple of laptops, two home machines you use for work, a couple of workstations at work. I can't remember which email client I originally used, but over the years there wasn't much left of it since I had rewritten large parts of it to offer tolerable IMAP support that could deal with having 3-4 different accounts for work, personal, hobby etc.

What broke things was when maintaining a mail infrastructure became too much work and I that I had to use services for work that didn't play nice with most mail clients.

And this sucked since I had something like 10kLOC of elisp to deal with sorting, categorizing, prioritizing and filtering email. So I had this specialized email client nobody was willing to touch (can't blame people since the code was probably garbage) and I had a choice between continuing to spend time maintaining it and just use more convenient options.

It depends on what people think when they say IDE.

I would say I used Emacs as an IDE for C, C++, Java and to a certain degree, Go. For me an IDE needs to do syntax highlighting, have some semantic understanding of the language, be able to do sensible completion, understand symbols (find definition, find uses), show me documentation, interface with version control, be able to do simple refactoring, run builds, tests, perform debugging etc. It doesn't matter whether it is a clicky or GUI'y interface - what matters to me is that I can have 90% my needs as a developer served within the same environment.

Or let me put it another way: I don't use VS code for anything I didn't use Emacs for in the past when I develop.

But the thing is that Emacs doesn't have enough active developers maintaining stuff. For instance, if you program Go, things worked okay - and then the semantic bits moved to language servers and Emacs extensions were slow to adopt this. Making Emacs a lot less useful. Every so many weeks you'd sit down a weekend to try to cobble together something that would minimally work and it became tiring.

And yes, a lot of basic stuff is missing or simply just too low quality. From how you configure stuff to how you install and manage extensions to how you manage configuration across workstations. This isn't a new problem and the fact that Emacs has struggled with this for too long suggests that you won't see this solved in, for instance, GNU Emacs any time soon.

If you are a developer today learning VS Code is a better investment than learning Emacs. It has nothing to do with disliking Emacs - it is a simple matter of what environment manages to attract a sufficiently large active developer base for developing extensions and tools.

As I said, I still love Emacs. But evolution is making it a dead end.

Ah, excellent, just wanted to make sure there wasn't some magical insight i was missing out on by not being familiar with emacs.

re: clicking/squinting/dragging/animations those i would usually handle by things like keyboard shortcuts, configuring your global search to list tabs first, configuring animation.

I think what is more interesting is the idea to use the same buffers/windows for non-text-files. So, the first half is the idea of having all your tooling be text-based. There's some slider along, text driven by keyboard => gui driven by keyboard => gui driven by mouse. And then the second half of the idea seems to be how you separate text-editing/config/applications. So maybe along that slider, emacs mixes all sources / IDE groups sources within an application / separate applications for each source.

Maybe pushing everything to one edge of the slider is able to put one in a zen-like state. I guess for now I just try to find a sweet spot with my tools, where stuff i want to do fast i can do fast, and everything else is ok as is.

I’ve used Emacs for several years now, primarily on Linux but also MacOS.

I never recommend it to new users without the caveat of time investment; it’s a disservice to just say ‘Emacs is great’. It’s great in the same sense as a large box of Legos is great—for potential, not OOBE, which is (in my opinion) fairly mediocre.

My second unpopular opinion: Elisp is a significant barrier to entry for users. Changing this would blow open the doors to adoption and evolving the tool, I think. But it will never happen.

I tried org-roam too and it just feels like a bad joke compared to VSCode's foam. Foam has a real time graph of your notes. In org-roam, you need to call a method to get a static graph open in your browser. In theory, you can click the nodes in the org-roam graph to go to your notes... but it doesn't work out of the box for me. Whereas in Foam I can just ctrl+click on a node and bam, i'm in the file I want to be.

I also really like that Foam lets me edit files in markdown in the left window while seeing the rendered version in the right window. The trade-off is this seems to waste screen real estate like there's no tomorrow, but with a 4k screen, I think it's worth the trade-off.