2 ms·

Because very few people actually care about the things that emacs has to offer. Tools like VS Code do the job well enough for the majority of people, with just

Because very few people actually care about the things that emacs has to offer. Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use. Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.

__patchbit__ 1mo ago
Emacs and AI go hand in glove.
- kodoman 1mo ago
  work amazingly well, almost perfect. I have not see anything come close to what you can do with emacs and the easy to which ai can be integrated and slotted into emacs.
- iLemming 29d ago
  Because Emacs is not a text editor, it's rather a text orchestrator. And Emacs Lisp is specifically text-oriented, unlike most other Lisps that are data-oriented. It fits incredibly well for LLM-flows. I'm surprised how it remains enormously flexible even though my workflows change every day. The way how I used LLMs last year vastly differs from a few months ago and totally unlike of today, yet bending Emacs never hits the ceiling. If I had a way to send a message to my younger self, it would've been: "drop whatever you're doing, start grokking Linux, learn Emacs, and maybe Vim...". I never had any regrets about my career choices of the past, yet "fuck Microsoft!" I spent years digging dotnet, sqlserver, etc. I invested heavily into WPF and Silverlight, I believed their propaganda. I don't feel even a half-pint of value from the experiences I gained, it all turned out to be useless crap - none of it squeezed even a drop for becoming a hacker out of me. Learning FP, Lisp and Emacs brought me closer to that goal.
anon291 1mo ago
It's just easy to install on Windows. Base emacs does exactly what you want it to do. And my emacs v vscode comparison was specifically because of infinite configurability and expandability. VSCode has the same thing with its myriad javascript extensions.
iLemming 29d ago
> Because very few people actually care about the things that emacs has to offer. Most people are simply unaware of "what Emacs has to offer". Even long-time users sometimes don't realize what Emacs actually is. They treat it just like any other text editor. Well, Emacs is not an ordinary text editor in the traditional sense. It is rather a text orchestrator - you can manage any text-related tasks in its computational vicinity - text that appears in any local app you see on your screen or lives on a remote machine. > everyone's environment and tooling ends up becoming incompatible with each other. It was never a problem because Emacs packages are not extensions - they are recipe books. Yes, you can often use them as ready-to-play "products", but eventually you'd have to look under the hood. Yes, it makes it difficult to maintain transferable help because an answer written for someone else's setup may not apply to yours, but that's by design - the complete absence of interface boundaries is the point. Nobody calls out a "compatibility crisis" on shell prompts. > Tools like VS Code do the job Yes, VSCode is "easy" - you can install it and it's either useful in ten seconds or you quickly find what you hate about it. Emacs is not "easy", it is "simple", it pays off only after months of investment, and the ROI from it can be immeasurably bigger in ways that you might have not realized before it. You can inspect a hammer before buying. You cannot inspect Emacs, because its value isn't in the artifact, it's in workflows one simply cannot evaluate with their pre-emacs values. It wouldn't occur to you to want a fix for something that doesn't register as a problem. Software should never be restrictive but egalitarian and accommodating. So often do I feel like rolling my eyes whenever I pair with my colleagues - I'd do something trivial, like fetching a list of PRs related to a specific ticket when the cursor is on it. They'd be like "whoa, that's cool", and then never do anything about it - they stick to their "learned helplessness" paradigm - copy the ticket number, switch to browser, navigate to Jira, pass through SSO, find the phone to confirm it, push the button on the phone, paste the ticket number, find the linked PRs, etc. And our other teammate watching all that may say something like: "I think if you do it directly on GitHub, it'd be faster"... And here I am - pressing a key, voila - the list. Why the heck they don't do anything about it, I just don't get it. Trained engineers, they spend years dealing with cranky software, why in the world are they unwilling to do anything about these seemingly small annoyances? Why do so many programmers treat software as if it's magic? And I think I know the answer: because the software you use shapes your affordances. If there's no downloadable "get-me-list-of-prs-for-a-jira-ticket" extension and there's no simple way to build it, it would never occur to me to be annoyed. In Emacs, I can write a picker in a scratch buffer by hand and it would take me minutes.

__patchbit__ 1mo ago

Emacs and AI go hand in glove.

kodoman 1mo ago
work amazingly well, almost perfect. I have not see anything come close to what you can do with emacs and the easy to which ai can be integrated and slotted into emacs.
iLemming 29d ago
Because Emacs is not a text editor, it's rather a text orchestrator. And Emacs Lisp is specifically text-oriented, unlike most other Lisps that are data-oriented. It fits incredibly well for LLM-flows. I'm surprised how it remains enormously flexible even though my workflows change every day. The way how I used LLMs last year vastly differs from a few months ago and totally unlike of today, yet bending Emacs never hits the ceiling. If I had a way to send a message to my younger self, it would've been: "drop whatever you're doing, start grokking Linux, learn Emacs, and maybe Vim...". I never had any regrets about my career choices of the past, yet "fuck Microsoft!" I spent years digging dotnet, sqlserver, etc. I invested heavily into WPF and Silverlight, I believed their propaganda. I don't feel even a half-pint of value from the experiences I gained, it all turned out to be useless crap - none of it squeezed even a drop for becoming a hacker out of me. Learning FP, Lisp and Emacs brought me closer to that goal.

anon291 1mo ago

It's just easy to install on Windows. Base emacs does exactly what you want it to do. And my emacs v vscode comparison was specifically because of infinite configurability and expandability. VSCode has the same thing with its myriad javascript extensions.

iLemming 29d ago

> Because very few people actually care about the things that emacs has to offer. Most people are simply unaware of "what Emacs has to offer". Even long-time users sometimes don't realize what Emacs actually is. They treat it just like any other text editor. Well, Emacs is not an ordinary text editor in the traditional sense. It is rather a text orchestrator - you can manage any text-related tasks in its computational vicinity - text that appears in any local app you see on your screen or lives on a remote machine. > everyone's environment and tooling ends up becoming incompatible with each other. It was never a problem because Emacs packages are not extensions - they are recipe books. Yes, you can often use them as ready-to-play "products", but eventually you'd have to look under the hood. Yes, it makes it difficult to maintain transferable help because an answer written for someone else's setup may not apply to yours, but that's by design - the complete absence of interface boundaries is the point. Nobody calls out a "compatibility crisis" on shell prompts. > Tools like VS Code do the job Yes, VSCode is "easy" - you can install it and it's either useful in ten seconds or you quickly find what you hate about it. Emacs is not "easy", it is "simple", it pays off only after months of investment, and the ROI from it can be immeasurably bigger in ways that you might have not realized before it. You can inspect a hammer before buying. You cannot inspect Emacs, because its value isn't in the artifact, it's in workflows one simply cannot evaluate with their pre-emacs values. It wouldn't occur to you to want a fix for something that doesn't register as a problem. Software should never be restrictive but egalitarian and accommodating. So often do I feel like rolling my eyes whenever I pair with my colleagues - I'd do something trivial, like fetching a list of PRs related to a specific ticket when the cursor is on it. They'd be like "whoa, that's cool", and then never do anything about it - they stick to their "learned helplessness" paradigm - copy the ticket number, switch to browser, navigate to Jira, pass through SSO, find the phone to confirm it, push the button on the phone, paste the ticket number, find the linked PRs, etc. And our other teammate watching all that may say something like: "I think if you do it directly on GitHub, it'd be faster"... And here I am - pressing a key, voila - the list. Why the heck they don't do anything about it, I just don't get it. Trained engineers, they spend years dealing with cranky software, why in the world are they unwilling to do anything about these seemingly small annoyances? Why do so many programmers treat software as if it's magic? And I think I know the answer: because the software you use shapes your affordances. If there's no downloadable "get-me-list-of-prs-for-a-jira-ticket" extension and there's no simple way to build it, it would never occur to me to be annoyed. In Emacs, I can write a picker in a scratch buffer by hand and it would take me minutes.