undefined | Better HN

0 pointsiLemming1y ago0 comments

> Emacs is also objectively dogshit in a lot of ways compared to most modern editors

Yet not a single modern editor can even come close to it when it comes to extensibility and customization; self-documenting; complete programmability; malleability; ability to perform virtually any computing task without leaving the editor. Modern editors excel at being user-friendly out of the box. Emacs excels at becoming exactly what each user needs it to be. While you find yours to be "objectively dogshit" in comparison, I can probably easily demonstrate to you how mine eats their "modern" shit without even chocking.

> LSP is ridiculously slow

Have you tried to get to the bottom of it? Sometimes it just the lsp-server implementation that is slow. Have you tried https://github.com/blahgeek/emacs-lsp-booster? Did you build Emacs --with-native-comp flag? Have you tried using plists for deserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#use-p...? Have you used Emacs' built-in profiler? Sometimes the issue might be somewhere else, e.g., some fancy modeline settings.

> Things that would be trivial to do in most other languages or contexts

Sure, that's why we see so many "Emacs killers" built in Java, because replicating Org-mode is so trivial in it. /s

0 comments

IceDane1y ago

Yes, I've wasted a considerable amount of time trying to get to the bottom of the performance problems. So have multiple other avid emacs users I know that regularly have to deal with these problems. One of them is trying to live with eglot because it feels a lot faster - now they are also trying to use a sidecar process multiplexer to support multiple language servers. This is like the emacs experience in a nutshell.

My conclusion is basically: some language servers are slow, which doesn't help, and some are also very noisy. Both scenarios are handled extremely poorly by emacs, i.e. locked ui when parsing or waiting sometimes, stuff like that.

You really have to be a special kind of oblivious to argue so vehemently while literally suggesting I run a separate program on the side to get what most would consider to be a basic, functioning editing environment.

Re the org-mode argument: I really think you mistake lack of interest for insurmountable complexity. Emacs is not a magic machine that can do things no other software can do. You can probably count the number of people who genuinely care about org-mode in the world on 10 sets of hands.

iLemmingOP1y ago

> I've wasted a considerable amount of time

Okay, I'm just trying to help. I, for one, don't experience extremely vexing problems with performance like you're describing. But of course, I'm not going to pretend that I'm unaware that Emacs needs to improve on that front, and over the years there have been numerous improvements, so it's not a completely hopeless situation.

> basic, functioning editing environment

Different priorities. For me, "basic, functioning editing environment" means stuff like indirect buffers - which not a single other modern, popular editor offers.

> Emacs is not a magic machine that can do things no other software can do.

In some cases, it literally feels exactly like that. So while not literally magical, Emacs enables workflows and capabilities that can feel transformative and, yes, almost magical to its users. The "magic" comes from its architecture and philosophy. I can easily list dozens of use cases I've adopted in my workflow that are simply impractical to even try to replicate in other editors.

One can criticize pretty much any software product. Yet Emacs still falls in the category of "successful systems that have been maintained for ages". Anyway, we're getting sidetracked. My main point in the comment wasn't about Emacs, the main point is in the last paragraph. Maybe you just didn't even get to it.

j / k navigate · click thread line to collapse