emacs-lsp / lsp-mode

Emacs client/library for the Language Server Protocol
https://emacs-lsp.github.io/lsp-mode
GNU General Public License v3.0
4.82k stars 895 forks source link

[Feature] better lsp-describe-session #764

Open yyoncho opened 5 years ago

yyoncho commented 5 years ago
  1. Replace tree-widget with org-mode text - it will be much easier to work with.
  2. Include the following info:
    • Presence of the packages lsp-ui/yasnippet/company-lsp/etc + their state (enabled/disabled)
    • Status of each server - which path will be used, which mode will be enabled in, path to the binary and so on.
    • workspace folders + what we currently have
    • blacklisted folders
    • server-id -> folder association
    • Anything else that could be useful for diagnostics.
vibhavp commented 5 years ago

IMO, a package like ewoc (See https://www.gnu.org/software/emacs/manual/html_node/elisp/Abstract-Display.html) might be useful here.

yyoncho commented 5 years ago

Thanks for pointing this package, I might have used it in dap-mode for the templates.

One more functionality that we might have is to have a source block which installs the server, like that:

     #+BEGIN_SRC bash
      pip install python-language-server[all]
     #+END_SRC
nverno commented 4 years ago

I was just trying to setup lsp-pyls earlier, and was hoping there would be some diagnostics on what executables where being found/missing. I did see a brief message in on of the log buffers eventually, but it was far from obvious (I'm not a user of lsp-mode in general, so I'm a foreigner here).

I think it would be useful to make it clear what executables are missing, and when found, display the full paths to them. For example, it was using a python 2 pyls server from one of my environments, when I expected another. Something like flycheck-verify-setup would be fantastic.

jefftrull commented 4 years ago

org-mode would be a much more natural choice. I just spent ten minutes experimenting to figure out that one expands a node with the left mouse button, of all things.

matsievskiysv commented 3 years ago

Another desired functionality of lsp-describe-session:

  1. Stop running servers When I work on Java/Kotlin project, running two servers at the same time takes a lot of resources. Stopping servers from *lsp session* buffer would make resource management easier it these situations
  2. Remove stopped sessions Sometimes bash-ls would create session in my /tmp directory or even in mounted volume. This would provide a way to remove these sessions from list
aspiers commented 3 years ago

Also when a server process is listed in the session buffer multiple times due to having multiple workspaces connected to it, the same group of files should not be listed under every time it appears in the *lsp session* buffer. It's really quite confusing to have files from project A shown under a hierarchy for project B.

ia0 commented 1 year ago

Another desired functionality would be to be able to filter to only show running workspaces. This is useful when only a few (say 5) workspaces are running while the session has many (say 500) folders, because those running workspaces may be scattered anywhere in the list and thus easy to miss.

yenda commented 9 months ago

It would also be an improvement if there was a straightforward way to find out what the green/yellow/red colors mean