using sesman in lsp-mode

[yyoncho]

I am working on lsp-mode refactoring which plans to support more complex session<->project session<->buffer .

I am looking for advice on whether sesman would be a good fit for our scenarios.

1, One project (or project root) could have multiple sessions
2. One session could have multiple projects(e. g. java multi module project).
3. One buffer could have multiple sessions(e. g. HTML file with JS in it).

Thanks

EDIT: I saw sesman-single-link-context-types but I am not sure how this is going to work for buffer->multi session associations since the flag is global.

[vspinu]

If I understand the meaning of "could have" the same as you do then all of the 3 points above are supported by sesman. The way sesman interprets those "could have" is as follows. Each context (project, directory, buffer etc) can be associated (linked) with a session. Thus 1 means "project is linked to a session". 2 would mean "multiple projects can be linked to one session" and 3 "a buffer can be linked to multiple sessions".

The reason I think about associations as context -> session (even though "link" is bidirectional) is because the user level commands for linking (sesman-link-with-*) associate current context with some session which is selected interactively. This is an important nuance because linking is intended as an user level concept. This is why sesman-single-link-context-types is a global user level customization. If user want to have one session per project he or she is free to enforce that.

This design is not set in stone and I am curious to hear more about slp-mode needs. So far the only use case I had in mind is the REPL/process interaction. In a sentence, tooling needs to know current session and sesman provides all the pieces to make that current session available, but which project/dir/buffer is linked to what session is up to the user.

From what you describe it looks like lsp-mode decides what should be buffer level and project level associations and not the user, is this the case?

Regarding "java multi module". Do you mean you have one module and others are dependencies? If so there is a notion of "friendly" sessions which is intended for dependencies. That is, you can get a current-session from dependencies without having an explicit link through an indirection to a session which has such a link.

Regarding your multipe sessions per buffer, HTML with JS in it, do you mean that you can have say 2 HTML sessions and 1 JS session. Then in buffer A is associated with 1st HTML and the JS session and buffer B is associated with 2nd HTML and and same JS session? By session do you mean processes?

I don't know the details of lsp but it looks to me that for each HTML+JS project you would need one HTML lsp and one JS lsp process. Then those two processes constitute a session. This would be very similar to the CIDER's use case - each session consists of one or more REPL processes.

[yyoncho]

Thanks for the detailed reply:

From what you describe it looks like lsp-mode decides what should be buffer level and project level associations and not the user, is this the case?

Yes, lsp-mode will decide what is the session for the buffer/directory/project by default. In some advanced scenarios, users could use the sesman api to link another lsp server to the current buffer(e. g. if you are testing 2 lsp server you may switch from one to another).

Regarding "java multi module". Do you mean you have one module and others are dependencies?

This is just an example of one session -> multiple projects

Regarding your multipe sessions per buffer, HTML with JS in it, do you mean that you can have say 2 HTML sessions and 1 JS session. Then in buffer A is associated with 1st HTML and the JS session and buffer B is associated with 2nd HTML and and same JS session? By session do you mean processes?

By session I mean process. When you register a server in lsp-mode you should be able to specify whether the server will be started for a specific mode(e. g. SQL language server do need only the SQL file) or for project(e. g. when project contains pom.xml in the root).

I don't know the details of lsp but it looks to me that for each HTML+JS project you would need one HTML lsp and one JS lsp process. Then those two processes constitute a session. This would be very similar to the CIDER's use case - each session consists of one or more REPL processes.

Although I am not familiar with sesman it like the 2 servers should be 2 different sessions the servers could be combined in a different way. E. g. in .html file both JS and HTML server will be activated but in .js file only the JS server will be active. I havent tried it yet but the case should be similar to cljc file in which when you do eval the code is evaluated in both clj and cljs repl.

[vspinu]

Yes, lsp-mode will decide what is the session for the buffer/directory/project by default.

I see. Then you can rebind sesman-single-link-context-types locally around sesman-current-session. Setting it as buffer local value might interfere with other sesman systems present in the same buffer. Or you can create a new context lsp-buffer which will be just like buffer but without the limitation of single-link.

Actually, linking to buffers might not be the ideal solution. I think if some lsp server works for a file path/A then it will likely be working for another file in the same directory path/B. You might be better off by linking to directories if there is no project.

Although I am not familiar with sesman it like the 2 servers should be 2 different sessions the servers could be combined in a different way.

If you believe those servers should be working as a unit in terms of the life cycle (start, restart, kill) then you will better off by bundling them into one sesman session list. This is what CIDER does. In web-mode context you can get a plethora of languages active in the same buffer in the future, so managing them as a bunch might be easier, but who knows.

On the other hand by having a separate system per language (lsp-js lsp-html ...) you could more directly leverage sesman api when working with individual sessions.

E. g. in .html file both JS and HTML server will be activated but in .js file only the JS server will be active. I havent tried it yet but the case should be similar to cljc file in which when you do eval the code is evaluated in both clj and cljs repl.

Right. CIDER session consists of multiple connections (processes) and depending on the current buffer one or all of those processes are used.

Also currently sesman is not optimized. The simplisity of the implementation had priority given that user-level sessions are not many. If you start linking with thousands of buffers it might create overhead.

[yyoncho]

Thanks. I will do a prototype so we could evaluate whether sesman would be a good fit for us. If I had understood the code correctly the main benefit is that the user could interactively link session to buffer/project/directory which was not very convenient in cider's previous versions. In LSP the case is a bit different, I would like to use sesman like a session registry and benefit from the sesman facilities.