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.
1 Like
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.