Merge workspace and client structures. #289
Conversation
There doesn’t seem to be any conceptual difference between workspaces and clients, so let’s get rid of one of the concepts.
|
This is a backwards incompatible change and is likely breaking company-lsp. Please consider providing alias functions and bump the version. |
This refactoring only affects internal data structures, which other packages shouldn't rely on. If |
|
There is no proper public APIs for tools like company-lsp to work with lsp-mode. This change not only breaks company-lsp, but also lsp-ui hosted in this very same organization. These two packages are well-received by the lsp-mode users. Breaking them causes undesirable pains to the users. Refactoring is good and I don't want to block it. But please consider doing it in a less harmful way. Either a) define true public APIs that company-lsp and lsp-ui can rely, wait until packages migrate to using them, or b) provide backward-compatible function aliases so that they are not broken. If you are taking option a), I'm happy to list all private APIs company-lsp is using. cc @sebastiencs |
|
I think we should definitely move toward option (a). Not distinguishing between public APIs and private implementation details makes refactorings too onerous. |
|
I agree that with this PR, the name "client" captures more of the intuitive meaning. The specification does use both "workspace" and "client", but in a different way.
|
|
Closing in favour of #469 . |
* Don't use `lsp-execute-command' `lsp-execute-command' is a liability that needs to be removed; use lsp's :action-handlers for the reference and implementation lenses instead. Also remove the duplicate definition of the reference and implementation lens action functions. * `lsp-show-xrefs': supply DISPLAY argument * Fix CI byte-compile Declare `lsp-lens-backend' where necessary.
There doesn’t seem to be any conceptual difference between workspaces and
clients, so let’s get rid of one of the concepts.