This just proves that you can cram pretty much anything into the client/server dichotomy if you just define "client", "server" and "request" broad enough. Similarly, I remember how desperately people tried to argue that Emacs follows the "Unix philosophy" as long as your LISP functions are doing just one thing, and do them well. I don't know what you would gain from these things. Emacs follows the idea of LISP machines, I think that much anybody can agree on. From there, Emacs can be or do pretty much whatever you want. It's excellent in communicating with CLI tools - you can call that client/server if you want, but I wouldn't know what you'd gain from that definition. The reality is that Emacs has gone through a lot of fads and hypes over its decades of existence, and each time, it has taken something along the way. Heck, there's a whole semantic parsing engine buried within (CEDET), which nowadays is pretty much unused, because then LSPs came along, and now we have agents (which Emacs btw is a pretty decent frontend for).

> Heck, there's a whole semantic parsing engine buried within (CEDET), which nowadays is pretty much unused

In fairness that used to be common to have in most IDEs.

I don’t know if it’s still the case but i remember that the first java language server was spun off the Eclipse’s java semantic parsing engine.