That sounds like the issue I’m having right now. The language server simply isn’t sending any function signatures or docstrings at all. Haven’t had time to dig into it.
1 Like
The functionality came back somehow, and it turns out that interpolation is necessary to get the bug. So I opened the issue below:
No rush, I can live with this.
Thanks! @pfitzseb can you confirm the vs-code plugin doesn’t have any similar issue with the added detail that it’s triggered when interpolating into a docstring?
Hm, interesting. I can repro this:
1 Like
On the emacs side, looking through the source code, it appears eglot is attempting to parse any dollar signs as the start of a mathematical expression. The message being passed to the client from LanguageServer.jl with the docstring (response to a “textDocument/hover” request) is otherwise well-formed as far as I can tell. Maybe vs-code is doing the same? If so the solution is for LanguageServer.jl to start backslash-escaping any “$” in markdown strings it sends (not a violation of the gfm spec–just unnecessary to escape “$” ordinarily).
This is all rather unfortunate from a spec perspective. The language server protocol explicitly states that markdown follows the github flavored markdown spec which doesn’t include dollar-sign-delimited math expressions. But Microsoft chose to add support for math expressions to the markdown parser used on github without actually updating the gfm specification. Perhaps recently the vs-code markdown parser also added support for math expressions despite it being a violation of the lsp spec?
Should open an issue against LanguageServer.jl, but I wanted to make sure I had all the facts organized first.
3 Likes
I have had the same trouble as @tom-plaa, namely that eglot seems to work with julia-mode but not julia-ts-mode (using emacs 29.4 w/ updated packages).
I have a work-around: if I set the mode of the first-visited file in a project to julia-mode, then invoke eglot and wait for it to fully initialize, I find that the LS also works for files in that project later opened with julia-ts-mode.
FWIW, I observe that before eglot has processed all the caches, the first file (in julia-mode) temporarily shows the half-baked LS stuff that we see with invocation from julia-ts-mode. Perhaps t-s is not completing some handshake with the LS when it’s ready? Unfortunately not anything recorded in the eglot event buffer AFAICT.
Hm. Could you or @tom-plaa try to replicate this issue with emacs -Q and then manually installing eglot-jl and julia-ts-mode so we can make sure it’s not something else in your config causing the issue? I’m not having any luck at all replicating your experience, but obviously something somewhere needs fixed if multiple people are having the same problem.
1 Like
I haven’t had the chance to do it yet, but I plan on doing it when possible.
I tried a new install of the various packages with no frills and got the same result. (Anyone else trying this should currently follow the advice here to get a compatible grammar; an update is in progress.) Then I did a bit of yak shaving, yielding the following observation.
The problem appears to be that the server object set up by eglot-jl gets the languageId parameter from the major-mode name, and at least for some of us the language server does not like “julia-ts” as a languageId. (Correspondingly, initializing the server from plain julia-mode this way works, as we saw.) This seems to be fixed by changing the major-mode spec in eglot-jl-init to the form with explicit language-id settings.
2 Likes
Ralph, could you show me how to do it? I’d also like to try it on my side later when I have time. Thanks
The change is in this PR to eglot-jl.
3 Likes
By the way, perhaps I missed it, but is there already a solution or workaround for the missing reference-bug when using macros? Writing ModelingToolkit models and having all my parameters @parameters a get a red twiggle underneath them is quite jarring and distracting.
I’m using eglot (with eglo-jl ) along with julia-snail on emacs. It’s quite nice in general but there’s one very annoying aspect.
Here’s my folder:
juliajim
├── dev
│ ├── a_hworld.jl
│ ├── b_contin.jl
│ ├── b_contin.jl~
│ ├── c_nlslv.jl
│ ├── d_epmc.jl
│ └── e_mdofgen.jl
├── Manifest.toml
├── Project.toml
├── src
│ ├── CONTINUATION.jl
│ ├── HARMONIC.jl
│ ├── juliajim.jl
│ └── MDOFGEN.jl
└── test
└── a_afttests.jl
In the test file (or any file in the dev folder), I’m unable to get completions for any functions I define in the module file juliajim.jl if I use using juliajim in the beginning of the script. Including the file explicitly by an include or includet call works, however.
For instance, if the following is my juliajim.jl module file:
module juliajim
export jimgreet;
jimgreet() = "Hello World!";
end
the following doesn’t trigger any completion if I typed jimgr :
using juliajim
jimgr
but all the eglot features (completion, jump, etc.) work for the following:
includet("../src/juliajim.jl");
using .juliajim
jimgre
This is annoying since julia-snail is correctly able to include the module irrespective of which folder I’m on. I’ll appreciate any tips!
This is an unfortunate limitation of LanguageServer.jl. For the test directory specifically, see the same issue filed against the vscode extension:
See my reply above for the more general issue with julia files outside the src directory and a link to some workarounds:
Looks like you already found what I’m linking to, but in case somebody else ends up here through search: here’s the upstream issue for the language server not being aware of variables defined by macros:
1 Like