For example, how do you use a feature like "Navigate to derived symbols" without the required UI integration (prompt for which derived symbol to go to, opening up the correct code location...)? How do you define an "Extract interface" or "Extract base class" refactoring (name of new class/interface, members to extract, abstract or not...)? There are tons of UX aspects to good code navigation and refactoring. In order to get the equivalent of the feature set of, say, Resharper into vi or emacs, you'd have to add tons of new UI stuff. And once you do that, you are back to pretty tight coupling.
The necessary UI capabilities for the features you describe already exist in emacs. Multiple alternative implementations of them, actually (lsp-mode vs eglot). It's the editor's job to provide the UI and the LSP server's job to provide the backend. The interface between them is easy to standardise and it has been done (yes, even for the features you mention).
(Seems I can reply after all so have done so, and now I appear unable to edit the GP and remove the text above from it :-/)
Emacs can be described as an interactive, lisp-based environment for building textual UIs (TUIs). It's very easy to extend it with arbitrary, dynamic behaviours, including ones that need to collect information from the user.
As a trivial example, let's say for some reason I keep needing to generate the sha256 hash of a password and add it to the current file. I could add this to my .emacs:
Now if I hit Ctrl-C followed by p then h I will be prompted for a password in the minibuffer and the hash of the string I provide will be added where my cursor is. I didn't need to write any GUI code.
This kind of user interaction can equally easily allow the user to select from lists of dynamically determined options, including very large ones (with nice fuzzy matching menus if you use ivy, helm or similar). It's also trivial to write functions that prompt for several pieces of information, ask for different information depending on context, etc.
In the case of LSP, the server only has to provide information about what options are available and what possible responses are permitted. It's easy for emacs to dynamically provide the corresponding UI.
Ok, so you're not pointing to an implementation of the feature that I asked about. Instead, you're asking me to implement it as a special case. That's backwards.
You're effectively confirming that there needs to be feature-specific integration code for each and every navigation/refactoring/... feature in the editor. Once you have that, you again have tight coupling.
Not at all. The server allows for discovery of code actions and their parameters and the UI is displayed in response, by code that knows nothing about particular actions. It goes something like this (won't be accurate in the details, check the lsp spec [1] under Code Action Request if you want chapter and verse):
User to emacs: I want to perform a code action.
Emacs to server: The selection is this. What code actions can you perform?
Server to emacs: I can perform actions called "Extract Method", "Extract Base Class", etc.
Emacs to user: Choose an action from this list
User to emacs: I'll do "Extract method"
Emacs to server: We're going with "Extract Method", what info do you need.
Server to emacs: I need an item called "method name" which is a string and an item called "visibility", which is one of the following: "public", "private", "protected".
Emacs to user: Enter method name... Select visibility...
Emacs to server: Here are the parameter values.
Server: Here are the edits necessary to perform the code action
Emacs: Updates code.
No special per-action code is required. If you want to see an implementation have a look at lsp-mode[2].
I hope that makes it clear. I've spent more of my day explaining this than I should have now, so I'll leave it there.
Please forget "Extract Method" as an example. It's simply far too trivial. Imaging extracting a new superclass or interface from a class with 100 methods and you need to pick the set of methods to extract. You can't do that with 100 y/n choices.
