lsp-mode feature wishlist

[yyoncho]

[innerout]

I believe that lsp-mode needs to enhance it's lsp-rename function because that will get Emacs closer to being a full featured IDE. For example we could get some ideas from what intellij provides.Also i think the flymake integration will be a huge + but i think that is closer to be complete as @yyoncho has started working on it.

[yyoncho]

@innerout can you elaborate on rename improvements?

[innerout]

An example from intellij


images taken from here https://www.jetbrains.com/help/idea/refactoring-source-code.html .
Also another interesting feature would be this https://www.jetbrains.com/help/idea/find-and-replace-code-duplicates.html .

[yyoncho]

@innerout we are limited by the lsp protocol and the language servers so features that are not supported by the server(s) are out of scope.

[kaiwk]

Hey, thank you for the great work!

I think it's good to have a set of customization option and a better default, because some users may not need so much powerful functionality. For instance, most of them just want a fast way to completion, find references and maybe check doc. It's sure that we may turn on some options as default for user to test and whom really want to use.

It may too early to say that easy to configure is also an important feature, but it should be taken into consideration : )

[tam5]

Would have to be thought about a bit, but in light of the new session system, would be nice to be able to persist a session across emacs reboots.

I work on fairly large, enterprisey projects that take forever to get fully processed by my language server (php). Sometimes I end up restarting emacs for whatever reason, and then have to start the process all over again.

[tam5]

Getting started / specific language server installation instructions could be made more obvious, instead of making user go to specific language server docs, understand them properly, and then translate back to getting it to work with emacs.

For me, I generally like to just copy and paste instructions..

[tam5]

Not sure if this falls within lsp, or lsp-ui, or company, but:

Would be great to see parameter hints (and/or ability to auto-fill them) when completing with lsp.

For example, VsCode would do the following:

[yyoncho]

@kaiwk thanks for the suggestion. For now I will add quick start section similar to the one in https://github.com/emacs-lsp/lsp-java which you could just copy/paste and then start coding. We may investigate creating a meta package which joins all the packages that are needed for normal development similar to spacemacs layers. Also, if you have concrete proposals, please go ahead and file an issue or provide a PR.

[yyoncho]

@tam5

Would have to be thought about a bit, but in light of the new session system, would be nice to be able to persist a session across emacs reboots.

I work on fairly large, enterprisey projects that take forever to get fully processed by my language server (php). Sometimes I end up restarting emacs for whatever reason, and then have to start the process all over again.

can you elaborate a bit more? Unless there is a but the session should be persisted in lsp-session-file and then you won't be asked for root selection any more in any of the already imported projects, or you mean something else?

[yyoncho]

@tam5

Getting started / specific language server installation instructions could be made more obvious, instead of making user go to specific language server docs, understand them properly, and then translate back to getting it to work with emacs.

For me, I generally like to just copy and paste instruct

I believe we can do better: #506 . I will try to let lsp-mode directly consume the VSCode packages so you can just open the file and it will automatically download server, autoconfigure itself and so on.

About the signature feature: we have some code in, but I have never had a time to test it whether it works fine but in general this feature should work out of the box(currently it doesn't). Here it is a bug tracking the issue: #214

[tam5]

@yyoncho Awesome, thanks for your responses, and thanks for all your hard work!

I'll respond to the features that already seem to have issues in their rightful place, sorry for not searching first.

Regarding the session persistence:

The session is indeed persisted, to a degree, in the lsp-session-file which gives two very nice features regarding persistence:

1. No more asking for project root
2. Deleting all buffers within a project, does not shut down my language server, which is great

What I would like to potentially add:
Depending on some customization of course, when exiting emacs, do not shut down my language server. This way, I can come right back to emacs and continue my work without waiting for my language server to boot up and do all its file parsing.

This would mean preventing shut down of language server on exit, as well as reconnecting to the existing server on startup.

The only issue I see is potentially having dangling language server processes if they are not cleaned up properly.

[yyoncho]

Depending on some customization of course, when exiting emacs, do not shut down my language server. This way, I can come right back to emacs and continue my work without waiting for my language server to boot up and do all its file parsing.

I believe that this is not feasible due to multiple reasons - in general re-connection is not possible in LSP protocol, Re-connection to STDOUT is not technically possible(or at least I don't know how to do that). The only way to implement this feature is either to have some kind of server support for that or implement a proxy in front of the language server which is separate project itself.

[innerout]

You can read stdout and write to stdin of any process if you know its pid.

For stdin

cat main.c > /proc/<pid>/fd/0

For stdout

tail -f /proc/<pid>/fd/1

[tam5]

Here's another one:

Would it be possible to generate doc-blocks (i.e. be able to read a method signature and insert proper doc block including relevant things like param names/types, return type, etc. ?

There are different styles and conventions for this, so I'm not sure how the customization of that would be handled.

[factyy]

Do you think we need an umbrella project for such integration? I see that it is partly possible to have such features, but at the same time I think that we have to take a more integrated approach. For example, we have to determine the project type, guess (or get from our specific config) the tools needed and so guess the container needed.

[Vonfry]

Is it possible to create interfaces of call and type hierarchy without treemacs like references?

[yyoncho]

It is possible. lsp-treemacs is written in a way that allows using different frontends for the tree structures

[kzarist]

I'm using lsp with golang I can run tests by clicking in the run test shortcut I'm trying to bind it somewhere.
It would be helpful to have a resource on how to send commands directly to the language server.

[factyy]

@yyoncho , sadly I just didn't have any spare time until now. So I want to help with dockerized lsp use cases.
I need your (or any other core maintainers') help to decide where to place the code and if this approach is ok from architectural point of view:

1. I want to extend the existing lsp-mode implementation with persisting configurations (with something like a yml config stored in the project root)
2. I want to be able to have a persisting container and just start / stop it when needed (patch lsp-docker with different launching code: no more runs but starts)
3. I want to place a container name and path mappings in this config (for a start).

Note: currently I am talking about teaching lsp-mode how to use a development environment container built by hand

[factyy]

And yeah, some of the goals are similar (providing a containerized environment), but the general idea of being fully containerized (including emacs itself) is a bit different :)

[yyoncho]

Is it a general design decision to somehow be at least semi compatible with it?

We try to be as much compatible as possible for better interoperability.

but the general idea of being fully containerized (including emacs itself) is a bit different :)

Yeah, that is true. I hope that in the end, we will be able to share some facilities with lsp-gitpod and have a parameter where to run emacs in.

I want to extend the existing lsp-mode implementation with persisting configurations (with something like a yml config stored in the project root)

I would say that for the first version we need .dir-locals and the yaml should be an additional thing. I will think about it and come back to you.

[factyy]

Thanks! I have a hard work of learning hardcore Elisp ahead :)

[factyy]

Hi again! I have implemented a configuration layer that uses project-wise YAML configs allowing to use existing containers (or specified images). Currently everything is implemented in separate files, but I can integrate it into lsp-docker and file a PR. Is it ok with the maintaining team?

P.S: I am a bit concerned about .dir-locals. Just thinking about executing any code that is user-provided brings serious doubts whether this approach may be secure at all...

[factyy]

Sorry to bother, just a reminder @yyoncho :)

[yyoncho]

P.S: I am a bit concerned about .dir-locals. Just thinking about executing any code that is user-provided brings serious doubts whether this approach may be secure at all...

You cannot have eval any code in it.

I will review your PR.

[d3rped]

The deno client definition is missing some features (mainly those added in v1.17 and v1.17.1 (don't know if I missed anything else)).

The more (de)pressing issue is that the client is not working properly (at least compared to when I use ts-ls or tide+deno plugin.
Issues I have encountered:

• cannot jump to code definition of (cached) imports
• no docstrings in the (company) completion selection (works for other lsp clients)
• no docstrings at all for (cached) imports (only function/type signatures on cursor point)

Would be super cool (and make my life a lot easier) if someone could fix this.

[vakker]

There's a lsp-pylsp-plugins-jedi-use-pyenv-environment variable that's very convenient, could you add the same functionality for poetry and conda?

[yyoncho]

The server has to provide such setting, then we can expose it client side.

[vakker]

There is such setting, namely pylsp.plugins.jedi.environment, but setting that to whatever pyenv provides is handled by the client if I understand it correctly. Or where does lsp-pylsp-plugins-jedi-use-pyenv-environment actually come from?

[bbigras]

Refactoring stuff like "extract method".

[condy0919]

Can lsp-semantic-tokens-enable only gray the inactive code out?

I'm not sure that

(setq lsp-semantic-tokens-enable t)
(setq lsp-semantic-tokens-apply-modifiers nil)

is the solution, but it works like it does.

[ericdallo]

Not the solution, probably only works because your server colors inactive code.
There is no ideal solution on client side (lsp-mode) as this is something that only some servers do and the spec says nothing about that :/

[liferooter]

I wish lsp-mode could show diagnostics for whole project, not only for current file. It's very unconvenient to fix errors in a big project after global refactoring when you can only see errors from current buffer.

[yyoncho]

@liferooter check lsp-treemacs-diagnostics, helm-lsp-diagnostics and the lsp-consult and lsp-ivy counterparts

[liferooter]

lsp-treemacs-diagnostics is more much buggy and unconvenient than flycheck-lisp-errors. Other are used for navigation, not for monitoring.

[condy0919]

lsp-rename with preview. So that I can know how many symbols will be renamed at a glance.

[innerout]

This would be top.

[larrasket]

https://github.com/victorhge/iedit does that but within only one buffer. Maybe lsp-mode developers can make something similar out of it.

[factyy]

What do you think about enhancing persistent lsp-docker configurations with custom image building (a bit like Dev Containers in VSCode)?

Like this:

1. You have a Dockerfile in the .lsp-docker folder in the project root;
2. You have an .lsp-docker.yml config either in the project root or in the .lsp-docker folder;
3. If there are no images (which are specified in the config), the corresponding image is built using the provided Dockerfile;
4. This image (or a container created using a corresponding image) is used for starting the language server.

[yyoncho]

Sound good.

[factyy]

Great, will get my hands on it when I have a bit of free time.

And yeah, after that I want to implement the same for debugging (for dap-mode)

[ishai1]

I added a function for cleaning all tracked folders since I think the alternative is to manually remove them one at a time from the *lsp session* buffer. I used the following to do this:

(defun lsp-workspace-folders-remove-all ()
  "Delete all lsp tracked folders."
  (interactive)
  (--each (lsp-session-folders (lsp-session))
    (lsp-workspace-folders-remove it)))

It's a function I've reached for a few times so thought it could be nice to have as part of master.

Happy to open a PR if so.

[tam5]

Thanks for sharing, I would use that.

Personally I find I have to do this from time to time if I've been working on more than one project otherwise it starts to get confused, wondering if you/anyone had the same

[ericdallo]

Sounds good to me open a PR for that, feel free to do it @ishai1

[oxinosg]

Hi @yyoncho, thank you for the great work on emacs-lsp 💪

I was wondering, will it be easy to enable lsp lens debug to recognize launch.json like dap-mode does?

[oxinosg]

For more context: Through dap debug using a launch.json config, I'm able to use the dap using rust-gdb with pretty-print enabled and everything works perfect. What I noticed though, is that debugging tests through lsp lens debug don't read launch.json file. I tried to pass the same args through lsp-rust-analyzer-debug-lens-extra-dap-args, but I can't get the following part of the launch.json config to be correctly passed to the debugger which makes local variabled to no be fully readable:

"setupCommands": [
  {
    "description": "Enable pretty-printing for gdb",
    "text": "-enable-pretty-printing",
    "ignoreFailures": true
  }
]

[yyoncho]

What is your issue with lsp-rust-analyzer-debug-lens-extra-dap-args exactly? You cannot represent that as elisp or it does not look well in dir-locals?

[oxinosg]

I assume that I cannot represent that as elisp since I'm getting the following error when the debugger starts:

Warning (emacs): Initialize request failed: Unable to start debugging. Error converting value "quote" to type 'MICore.Json.LaunchOptions.SetupCommand'. Path 'setupCommands[0]',

Although it's likely that I translated the json config to elisp incorrectly. What I added is (tried a few variation though and none worked):

:setupCommands '((:description "Enable pretty-printing for gdb" :text "-enable-pretty-printing" :ignoreFailures t))

inside lsp-rust-analyzer-debug-lens-extra-dap-args

[yyoncho]

Can you show me exactly what you are doing? Also, you may print the wire message using dap-print-io and checking the Messages buffer

[oxinosg]

🤦
simply enabling dap-print-io was enough to realize that I was just writing the args incorrectly.

after updating the args passed to lsp-rust-analyzer-debug-lens-extra-dap-args as:

        lsp-rust-analyzer-debug-lens-extra-dap-args '(
          :MIMode "gdb"
          :console "external"
          :dap-compilation "cargo build"
          :dap-compilation-dir "${workspaceFolder}"
          :externalConsole
          :gdbpath "rust-gdb"
          :json-false
          :miDebuggerPath "rust-gdb"
          :request "launch"
          :setupCommands [(:description "Enable pretty-printing for gdb" :text "-enable-pretty-printing" :ignoreFailures t)]
          :type "cppdbg"
          )

I see the following message & now debugger works as intended:

Sending: 
{
  "command": "launch",
  "arguments": {
    "MIMode": "gdb",
    "miDebuggerPath": "rust-gdb",
    "gdbpath": "rust-gdb",
    "type": "cppdbg",
    "request": "launch",
    "setupCommands": [
      {
        "description": "Enable pretty-printing for gdb",
        "text": "-enable-pretty-printing",
        "ignoreFailures": true
      }
    ],
    "console": "external",
    "externalConsole": false,
    "args": [
      "scores::test::test::compute",
      "--exact",
      "--nocapture"
    ],
    "cwd": "/home/...",
    "name": "test scores::test::test::compute",
    "sourceLanguages": [
      "rust"
    ],
    "target": null,
    "program": "...-7d9194f220f6a0b5",
    "environment": []
  },
  "type": "request",
  "seq": 2
}
Received:
{
  "type": "request",
  "command": "runInTerminal",
  "arguments": {
    "kind": "integrated",
    "title": "cppdbg: -7d9194f220f6a0b5",
    "cwd": "",
    "args": [
      "/bin/sh",
      "/tmp/Microsoft-MIEngine-Cmd-mks4io5x.kt5"
    ],
    "env": {}
  },
  "seq": 2
}

Sorry to bother you about this

[Xalares]

Hi, lsp supporting awk language could be cool !

[Xalares]

Yes indeed that's what I wanted to say. So rephrased, it could be nice if lsp-mode supported awk language server, this is the language server I've in mind : https://github.com/Beaglefoot/awk-language-server.

[Hi-Angel]

Sent a PR implementing awk-language-server support. Testing is appreciated, you can check it out by downloading this file to your lsp-mode installation directory (likely ~/.emacs.d/elpa/lsp-mode-$VERSION), then editing lsp-mode.el file and applying the two changed lines you can see at the PR related to the lsp-mode.el file, then finally recompiling lsp-mode.el with M-x byte-compile-file, then restarting Emacs.

[Xalares]

Hi, I've tested it, it works, but the installation is not automatic, I don't know if it's intended or not. But once installed it works great ! Thanks !

[Hi-Angel]

From what I understand, installation automation is done by using lsp-clients.json and some scripts in the repo that generates the according code. I did add a section to lsp-clients.json after looking how it's done for other lsp-servers (it's pretty self-explanatory, the only things that seems to matter in the automation context is just adding a npm i -g … command). But if you want to test that you need more than just edit a few files, but apparently also run make in the repo and then install whatever make created to your elpa directory. You can try that if you want.

So basically, automating should work, but you need the entire PR rather than the few changes I suggested that you copy.

[Xalares]

If I've done it correctly, I've applied your PR to all the files concerned, I've not run make though.