Toggling the lsp-mode does not actually toggle the server

[rski]

If lsp-mode was active, doing M-x lsp-mode (toggle off) M-x lsp-mode (toggle on again) doesn't try to stop and then start the server again.

As a result of this, if the server for some reason dies, it is not possible to restart it in the current project unless you restart emacs or muck with variables.

[vibhavp]

Ah, never thought of that. I'll try adding toggle functionality, thanks

[alanz]

Also, see the approach in https://github.com/commercialhaskell/intero/issues/364

There is both a blacklist and a whitelist

[alanz]

Perhaps toggling lsp-mode in the presence of the lsp-project-blacklist should offer to add it to the lsp-project-whitelist.

[Alexander-Miller]

it is not possible to restart it in the current project unless you restart emacs

Not even closing emacs works. It tries to shut down the lsp process, sees that's it's not live, and throws an error (this happens in lsp--stdio-send-(a)sync). I've had to use xkill to exit emacs when that happened.

[astahlman]

I believe the error that @Alexander-Miller referenced is triggered in the process sentinel, here:

lsp-mode/lsp-methods.el

Line 369 in bb936fd

(dolist (buf (lsp--workspace-buffers lsp--cur-workspace))

The function references lsp--cur-workspace, but by the time the sentinel runs, the workspace has already been set to nil, here:

lsp-mode/lsp-methods.el

Line 313 in bb936fd

(setq lsp--cur-workspace nil)

Regarding the original proposal: correct me if I'm wrong, but wouldn't toggling the minor mode in a single buffer affect all buffers associated with the project workspace? In other words, if buffer A and buffer B are both visiting files under the same project root directory, and I toggle lsp-mode in buffer A, then the language server would "disappear" from the perspective of buffer B.

Is that what's intended here? As a user, I think this would be surprising and not very intuitive. It seems cleaner (albeit more difficult) to decouple the lifecycle of the language server from the status of the minor-mode in each buffer.

[astahlman]

@alanz I see that you were working on this in #82. Any comment on the relationship between the the language server process and the individual documents in a workspace?

IMHO, the relationship between:

• the language server process(es)
• the lsp--client(s)
• the workspace(s)
• each document in a workspace
• major and minor modes

...is a little unclear and could use some more thinking. Perhaps a good first step would be for someone to document the ideal state?

[phst]

I think the ideal state would be as follows: Any buffer could have any number of servers associated with it. That is, a buffer could have zero, one, or more servers, and multiple buffers could talk to the same server. The association should not be based on workspace root directories or modes, but completely arbitrary, because the association is intrinsically server-specific. For example, it's possible that a server could be used for an arbitrary number of languages and major modes, and vice versa a buffer should be able to use different servers providing different functionality.

[alanz]

Sorry for the long delay, I had some ISP issues.

For me, focusing on a single language server (haskell), the relationship is simple.

An IDE may open multiple projects.

A "project" is a thing that makes sense for the given dev context, and is normally well enough understood.

Each project has a single language server running. For haskell this is quite important, as a server can use up quite a bit of resources.

A workspace corresponds to a project.

A document belongs to a workspace/project, and all documents for a project are handled by the same server.

I do not have a strong opinion on the major/minor thing. Certain features can be exposed piecemeal, like flycheck, and the company stuff.

It does make sense for it to be fully integrated into a given mode though.

A bit of a ramble, I am afraid.

[astahlman]

@phst Do you have an idea how the life-cycle management of the language servers would work if the association between buffers and language servers were arbitrary and decoupled from the workspace?

I like the approach @alanz suggests of a 1:1 correspondence between workspace and language server where a document belongs to a single workspace because it's simple and easy to reason about. But I also foresee issues with projects that encompass multiple languages, e.g., a Haskell-based web application that includes source files in Haskell, HTML, CSS, and Javascript, bash, make, etc.

[vibhavp]

The issue with projects using multiple languages can be addressed by letting many buffers share the same workspace struct object, which can be accomplished by using a global hash table.

[vibhavp]

On second thought, I'm not sure if that is a good idea. lsp-after-change uses the workspace object to send the changes to the language server, and doing a hash lookup after every textual change to the buffer might result in slowdowns, especially in a project with a large amount of files open.

[Alexander-Miller]

Do you really need hashes? Why not store a buffer's workspaces as a buffer-local variable right in the buffer?

Also does the LSP really require to send an event on every change? I think an idle timer would be a simpler solution.

[alanz]

We used to use an idle timer. But then we discovered that we can't batch the changes. See d696926

[vibhavp]

Why not store a buffer's workspaces as a buffer-local variable right in the buffer?

That's what we currently do, see lsp--cur-workspace

[phst]

Why not store a buffer's workspaces as a buffer-local variable right in the buffer?

That's what we currently do, see lsp--cur-workspace

Could you extend that variable to a list of workspaces so that each buffer can have more than one workspace?

[colonelpanic8]

It seems that the discussion here ended up going off on a tangent about associating buffers with lsp server processes.

What is the status of the original issue being unable to get emacs to restart the server process? That seems like it should be easy enough...

I am aware of lsp-restart-workspace, but this does not seem to work (at least for lsp-haskell).

[alanz]

@IvanMalison please give details about it not working for lsp-haskell. That is what I use, and it works for me. And is needed because of the memory leak in the haskell LSP server.

[yyoncho]

@MaskRay IMO we should merge lsp--management-mode and lsp-mode which will fix that issue.

[MaskRay]

@yyoncho LG. lsp--manged-mode and lsp-mode

---

lsp--managed-mode currently means a buffer that has sends a textDocument/didOpen notification

[vibhavp]

On second-second thought, lsp-mode is a lot like ERC. Even though there is an erc-mode, turning it on or off doesn't connect/disconnect you to an IRC server. The primary entrypoint for ERC is M-x erc, not M-x erc-mode , just like lsp--start. IMO, a better way to achieving some toggling functionality would be to add lsp-toggle.

[yyoncho]

@vibhavp I second that - after #424 is implemented we might ask which server to toggle if there are multiple servers for the current file. We may consider also the name lsp-unlink.