[self_awareness]

> In Emacs I can reuse functions of one package in another

You say like it's some kind of feature, but for me it sounds like a potential for name clash, and using private API which is prone to change/break.

> You call it "a legacy editor" without the slightest clue of what Emacs hackers are capable of doing

The thing is that is was VSCode which has brought us LSP, not "emacs hackers". It was VSCode which has brought us LLM Agent mode. All editors are catching up to VSCode, not the other way around.

LSP, LLM, ssh/docker/podman remote development, what's the Emacs answer to those? (I mean, nowadays vim+emacs have their own LSP clients built-in, years after VSCode)

[NoGravitas]

I'd prefer Emacs Lisp had Common Lisp style packages (with namespaces and exports), but in practice it's not much of a problem. Emacs is intended to be programmed by its users, so you don't have "private APIs" in the same way proprietary systems do. Actually internal functions and variables are usually marked with naming conventions these days.

LSP is a great thing to have, but it's actually much less capable than something like SLIME. If you've used SLIME, you'll see there's no comparison. LSP is a lot better than the nonsense I had to go through to get Java completions in the early 2000s, and I'm thankful to have it.

[iLemming]

> You say like it's some kind of feature

Oh, you just have no idea. It feels absolutely empowering and immensely liberating to have access to EVERY single line of code running and affecting your system editor. Whenever I need to solve a problem, I don't need to ask permissions, send PRs, dig through API documentation, google for answers, yell at LLM for not giving me answers - I can modify any behavior of any function on the fly and just move on. All that "it just works™" promise of other editors quickly evaporates when I, as a programmer, feel out of control of whatever happens on MY computer. Sure, yes, there's always a possibility that my "stupid hacks" just break for no apparent reason. Except, it rarely happens in practice, and when it does, I know how to quickly fix or put a workaround, because I precisely can pinpoint the exact line of code. Last time when something broke and it took me more than ten minutes to figure it out was about two years ago - the combination of multiple upstream updates and my lousy customization on top confused me for some time - it's all about trade offs, I'm happy to spend 15 minutes once every few years to fix some shit, if that gets me complete and total control over my environment.

I'm a hacker, not a florist - I want precision and complete transparency, not pretty buttons. I don't want any magic - I can't trust some extension to "just work" on a button click, without precisely knowing what it installs, where, and to what extent.

> what's the Emacs answer to those?

Ah, just like I said before, you're talking about things as if you're staring at the surface of the calm water of a lake. Except for an ocasional splash, it may seem lifeless to you, yet you don't have the faintest idea of its depths or what lies beneath.

There's currently an implosion of different LLM packages for Emacs - gptel, gptel-agent, ECA, agent-shell, claude-code, claude-code-ide, monet, claude-repl - and numerous others I haven't even heard of, these are just off the top of my head.

Emacs community may not be big enough and may lack incentives to constantly innovate, but they have no problem borrowing ideas from other places.

> All editors are catching up to VSCode

Wake me up when they figure out things like indirect buffers and executable source blocks in different PLs that can pipe data into one another, or when someone uses VSCode to control their window manager. Or when I can use literate programming to manage my dotfiles. And I haven't even gotten to the REPL part, even with Joyride it still falls short - there's no "I can hook to everything and redefine anything" in Code.