Using LanguageServer.jl with eglot in emacs

[ellocco]

I have an issue to install vterm, the problem is the same for Ubunutu 22.02 as well as for MS-Windows 10:

Error (use-package): vterm/:catch: Cannot open load file: No such file or directory, vterm-module

[ellocco]

@tom-plaa

(use-package vterm :ensure t)

For vterm I found the following snipped on erickgnavar.github.io:

(use-package vterm
  :ensure t
  :defer t
  :hook
  (vterm-mode . (lambda ()
                  (setq-local show-trailing-whitespace nil)))
  :custom
  (vterm-module-cmake-args "-DUSE_SYSTEM_LIBVTERM=yes")
  (vterm-always-compile-module t))

Does this make sense?

[tom-plaa]

Sorry, @ellocco, I had forgotten that using vterm wasn’t as plug-and-play as it seemed.
I forgot to mention that we need to compile vterm on our machine. And I believe that emacs must be compiled with the “with modules” option. I’m not sure if the version you have is compiled like that, but I thought it had become standard starting with 28 or similar.
Here’s a thread that mentions it, and where I based myself when I had exactly the same issue as yourself : Cannot open load file: No such file or directory, vterm-module · Issue #113 · akermu/emacs-libvterm · GitHub
I ended up compiling my own version of emacs, I’m on ubuntu 20.

For using vterm in general, check the readme of the repository for the installation procedure steps, minding what I said above about emacs: GitHub - akermu/emacs-libvterm: Emacs libvterm integration

If I remember correctly, we need to have all the dependencies needed for compilation, and then emacs itself will compile vterm for us on startup if we call the associated package in the config.
The configuration you posted seems to have an option for forcing recompilation everytime you startup - I personally would not include it, I don’t see the point. Once it compiled correctly for me, I never had any problems again. It also defers loading the package, I’m not sure if that is useful but it may be.

[ellocco]

My problem was the missing package libtool-bin, the compiler complains about the missing package libtool even, if it is installed, but the error message does not mention the missing libtool-bin.
The current emacs was sufficient, it was not necessary to compile it myself.
MS-Windows:
I wonder if the eshell is an alternative to vterm on MS-Window OS.

[tom-plaa]

I’m glad you managed to solve it nonetheless. I have no experience with using these in Windows so I can’t comment on that.

[johannesnauta]

I am not sure if this is correct thread to post, but here goes:

I am switching from lsp-mode to using eglot and eglot-jl because I could not correctly configure lsp-mode with my current Julia project (e.g. using Pkg.activate("path/to/project")). While the README.md on the eglot-jl clearly states:

After installation, eglot-jl-init will load support for the Julia language server into eglot and project.el. If eglot-jl-init has been run in your emacs session, running eglot in a julia-mode buffer will start a language server for the Julia project to which the buffer belongs.

I still get linting errors that indicate Missing references. Does someone maybe have an idea why this is the case? If I look into the *EGLOT message buffer it appears to have chosen the correct project, but it still cannot find the modules in my /src/ directory.

Here is the relevant elisp:

(use-package eglot
    :ensure t)

(use-package eglot-jl
    :ensure t)

(use-package julia-mode
    :ensure t
    :mode "\\.jl\\'"
    :interpreter "julia"
    :config
    (eglot-jl-init)
    ;; Specify the hook that connects =eglot=
    :hook (julia-mode . eglot-ensure))

And, perhaps useful, an overview of my tree can be checked in this question, but basically boils down to:

Project.toml
|- src/
|--- Main.jl
|- examples/
|--- example.jl

The linting errors appear in example.jl with contents

using Main
Main.someFunction()

Note that the code does work inside a Julia REPL, so I believe it is not an issue of a wrong import/using statement.

[johannesnauta]

For those in the future that have the same problem, I solved it by making another Project.toml in the examples/ directory that contains the Main package, e.g.

examples/Projects.toml:

[deps]
Main = "whatever-hash-is-generated-by-julia"

and the Missing reference errors raised by flymake (or flycheck) disappear.

[non-Jedi]

I try to go through discourse every few months and see if there’s any eglot-jl-related questions I missed. Apologies for not replying here sooner. This is a limitation of LanguageServer.jl which is discussed along with possible workarounds here:

LSP "Missing reference" woes

First, be aware it’s very hacky and messes up a bit with inline evaluation (which I don’t use much because I actually use Emacs for my day-to-day work). But let me try and give a step-by-step procedure that demonstrates this trick on a simple package like Example.jl. You should be able to reproduce this on your system. First, git clone https://github.com/JuliaLang/Example.jl, open the project in VSCode and add a script.jl file at its root. It should look like this: Example.jl ├── Project.toml …

[Tamas_Papp]

I recently started using eglot-jl again, and it works great, but there are some annotations I would like to disable. Specifically,

argument names like this:

and inferred types like this (note Int64, Set{T}; also argument names x: and B:):

I am currently digging into the manuals of eglot but I could figure this out.

[non-Jedi]

Glad it’s generally working well for you. I believe eglot-inlay-hints-mode is the invocation you’re looking for, but I’m not near a computer emacs right now, so I can’t confirm this. It’s a relatively new feature in either eglot or the language server, and I tend to agree that it’s quite annoying.

[Tamas_Papp]

@non-Jedi

eglot-inlay-hints-mode is the invocation you’re looking for

Indeed it is! Disabling it solves my problem. Thanks for the super-quick reply and your continued maintenance of eglot-jl!

[Tamas_Papp]

I just learned that the correct solution is something along the lines of

(setq eglot-ignored-server-capabilites '(:inlayHintProvider))

(explanation: eglot-ensure does not hold up the execution of your customization hook, so if you so something like (eglot-inlay-hints-mode -1) after, it may be reset when the mode actually finishes initialization).

[pfitzseb]

I assume that eglot has a way to set LS settings somewhere, in which case you should be able to disable julia.inlayHints.static.enabled (useful if you want inlay hints in other languages, for example).

[non-Jedi]

It does! I think I’ve used that functionality in the past to turn off certain lints, but I don’t see any sign of it in my config at the moment.

Is there a documented list of the available configuration options somewhere? It would be good to include a link to it in the eglot-jl README.

[Tamas_Papp]

Another question: for the code

using DocStringExtensions

"""
$(SIGNATURES)

This is a 100% bug-free function.
"""
foo() = nothing

when I put the point in a foo() (before the (), I get the documentation hint in the minibuffer, but

1. it does not resolve $(SIGNATURES) and
2. new lines appear as n, see screenshot:

I thought asking here before opening an issue, because I am not sure which part of the toolchain is responsible for this.

[pfitzseb]

1 is expected, the language server can’t currently deal with DocStringExtensions. 2 is happening somewhere inside of emacs/eglot though, I think – I’ve never seen that before in any other context.

[tom-plaa]

Has anyone successfully gotten eglot and julia-ts-mode to work together? If try to use julia-ts-mode instead of julia-mode eglot seems to go crazy and flag every single thing as a missing reference, and none of the functionalities work at all.

[non-Jedi]

@Tamas_Papp

1. new lines appear as n, see screenshot:

I thought asking here before opening an issue, because I am not sure which part of the toolchain is responsible for this.

Could you please open an issue against eglot-jl for this? I’m having an unrelated issue with eglot at the moment, so I can’t try to replicate right now. There’s a chance that this is an active choice of eglot to display docstrings with “\n”, and the backslash is just getting swallowed up accidentally as emacs likes to do, but I’ll need to dig a bit before I can say.

@tom-plaa

Has anyone successfully gotten eglot and julia-ts-mode to work together? If try to use julia-ts-mode instead of julia-mode eglot seems to go crazy and flag every single thing as a missing reference, and none of the functionalities work at all.

I just fired up eglot in a julia-ts-mode buffer, and it’s working no differently for me than in a julia-mode buffer. Could you please double-check you’re not getting the same result with plain julia-mode buffers? After that, try to create as minimal of a reproduction as possible and file an issue against eglot-jl?

Thanks!

[tom-plaa]

I reverted back to julia-mode so I definitely have different behaviour. I’ll try to get a MWE and report back on the repo like you asked.

[Tamas_Papp]

@non-Jedi

Could you please open an issue against eglot-jl for this?

I tried to replicate it to file an issue but now I don’t get docstrings shown at all. (I had updated my emacs packages a few times in between).