How can I try it? I suppose that if I just try to install lsp-julia from my .spacemacs file I’m not going to get your version.
If you want to try it from scratch, follow this gist:
https://gist.github.com/gdkrmr/624e423f774768563f30e1bd719579a4
The thing is, that you have to apply a small patch to LanguageServer.jl, no idea why this is not necessary from VScode. From Spacemacs you can simply add
(lsp-julia :location (recipe :fetcher github
:repo "gdkrmr/lsp-julia"
:files (:defaults "languageserver")))
to dotspacemacs-additional-packages. And point lsp-julia-package-dir to where the patched versions of the julia packages are (see the patch in the gist).
2 Likes
Back again.
As said in a previous comment, I managed to get eglot-jl working. But then I noticed something strange: some packages actually get autocompletion (eg: Flux) but many others doesn’t (VegaLite, GLM, Convex, JuMP…). What could cause this behavior? I tried to precompile them outside emacs, to precompilation inside emacs, but nothing worked
An explanation could be that the SymbolServer hasn’t indexed all dependencies of your project yet (this process can literally take hours in some cases). You know indexing is done when you see something like this in the server output ( in the *EGLOT (xxx/julia-mode) events* buffer):
[ Info: Received new data from Julia Symbol Server.
If all dependencies are not indexed, you only have to wait and everything should work ultimately. If indexing is already finished, and autocompletion still does not work for some packages, then I’m not sure what the problem could be…
1 Like
Unfortunately, it’s the second case you mention.
Now I installed new packages since the first time I did the indexing process, but even packages that were present and even precompiled the first time I installed and ran eglot never obtained completion.
But do not worry, this is not suck a big problem, most of the main packages I use daily are correctly indexed and get autocompletion. I was wondering if the problem is already known and if I should do something fancy (expecially for freshly installed packages, which I installed after the first indexing)
I don’t get any autocompletion at all when editing .jmd files in polyglot, with julia-mode and eglot and company all running in the julia sub-buffer.
I realize this is a bit of a weird scenario. But should this be supported?
Steps to reproduce:
- Put this in a file named foo.jmd and removed the \ character that’s just there to make it possible to see what’s up on this forum…
hello world,
```julia
x = collec
\```
- Now open this file in emacs, put it in poly-markdown-mode, go to the line that says
x = collecand see if you indeed wind up in a julia mode sub-buffer… You should. In that buffer, do M-x eglot to enable eglot, and M-x company-mode to enable autocompletion… observe that it doesn’t do any of the cool stuff shown on the eglot-jl page. At least not for me.
NOTE: I still get help in the minibuffer… but I don’t get autocomplete menus
I can reproduce. A (very) short investigation seems to indicate that when the julia sub-buffer is created by polymode, the company back-end is not set up in the same way as for a “normal” julia-mode buffer.
I haven’t managed to correctly configure company, though, so I’m not sure where to go from here…
Hi I moved to eglot-jl from lsp-julia. Installed using use-package eglot-jl and did eglot-init-jl as mentioned in the readme.
With the latest version, I get an issue with jump to definitions i.e I could not navigate to functions defined in other .jl files.
Please let me know if anybody have face this issue before or what I’m missing.
Could you please elaborate on the relationship between the files? Files in the same Julia project/package? Several files that are not part of any Julia project but are in the same directory (i.e. the same eglot project)?
I have a main.jl and used include directive to import other files. I can navigate to symbols and function definitions with in the file but not outside main.jl.
The exact error / warning message
Read error: Is a directory
(As a side note, I faced the the same issue in lsp-julia and reported it is still pending)
That sounds like an issue that I think has been fixed in the latest release of LanguageServer.jl. Until we get around to bumping that version, you can customize eglot-jl-language-server-project to point to a Project.toml with the latest release of LanguageServer and SymbolServer installed to see if that fixes it.
2 Likes
@non-Jedi can you help me understand about the eglot-jl-language-server-project is that a setting in eglot-jl.
@non-Jedi somehow I’ve found myself how to set path or project.toml with latest version of languageserver.jl to eglot-jl-language-server-project but still the same error.
Its really sad to see emacs not getting any required attention.
1 Like
I’m not sure what warrants this statement. From whom is “emacs not getting any required attention”? From the julia community?
Anyway, I can confirm that updating LanguageServer and SymbolServer to their latest versions does not solve the issue. It looks like the problem occurs because in the case of relative file paths, LanguageServer replies with URIs such as
file://foo.jl
instead of something like
file:///absolute/path/to/foo.jl
which is what would happen when includeing a julia source file with an absolute path. And relative file URIs are parsed by the url-parse emacs package as having an host part and no file name (whereas absolute file URIs are parsed as having a filename but no host part).
I’m not sure whether the fix should belong to eglot.el or url-parse.el, but in any case it does not seem to have much to do with anything related to either eglot-jl.el or LanguageServer (unless it is somewhat unorthodox to refer to relative file URIs in the LSP protocol, but this seems to be supported by VScode without any problem).
A fix might be provided by monkey-patching eglot.el so that file paths in URIs are correctly extracted in all cases:
(eval-after-load 'eglot
'(defun eglot--uri-to-path (uri)
"Convert URI to a file path."
(when (keywordp uri) (setq uri (substring (symbol-name uri) 1)))
(let* ((url (url-generic-parse-url (url-unhex-string uri)))
(retval (concat (url-host url)
(url-filename url))))
(if (eq system-type 'windows-nt) (substring retval 1) retval))))
Putting the above snippet in your emacs init file might fix the issue. But beware: this has not been thoroughly tested and might break other unrelated things.
As I said, I’m not sure whether the fix belongs to eglot.el or url-parse.el (does anyone here have any opinion on this?), but feel free to file an issue on either one of these packages to discuss this topic. If you do, please also feel free to propose the above code as a tentative fix.
I haven’t checked, but if lsp-julia (via lsp-mode) relies on url-parse in the same way that eglot does, that might explain why both packages face the same issue. So this might also be an opportunity to make some progress on the issue you seem to have filed with lsp-julia.
4 Likes
Thanks for the snippet, I 'm using elgot only for Julia mode. As you suggested I have installed the snippet on emacs init. It takes to references but not in some cases (I’ll try to find out those).
For reference, the issue I thought had solved this is below. The server should never be replying with relative URIs, so this is a bug in the server. I’ll reopen the issue since it doesn’t seem to have actually been fixed.
https://github.com/julia-vscode/LanguageServer.jl/issues/660
Ah, sorry, it looks like I have been too careless when doing tests: I can now confirm that the latest released LanguageServer indeed fixes that.
Should we perhaps release a new version of eglot-jl that relies on up-to-date versions of LanguageServer and SymbolServer?
@prassee Here is a minimal set of steps to test whether everything is fixed with a newer version of LanguageServer:
- Create an up-to-date environment. From a fresh Julia REPL:
julia> using Pkg
julia> pkg"activate /tmp/eglotTest"
Activating new environment at `/tmp/eglotTest/Project.toml`
julia> pkg"add LanguageServer SymbolServer"
Updating registry at `~/.julia/registries/General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
Resolving package versions...
Updating `/tmp/eglotTest/Project.toml`
[2b0e0bc5] + LanguageServer v3.2.0
[cf896787] + SymbolServer v5.1.0
Updating `/tmp/eglotTest/Manifest.toml`
[...]
-
Use this environment in
eglot-jl.el. Within emacs, evaluate this before opening your julia source file:
(setq eglot-jl-language-server-project "/tmp/eglotTest")
We definitely should. Are you not getting a crash on startup due to Handle arbitrary values in response to workspace/configuration request · Issue #806 · julia-vscode/LanguageServer.jl · GitHub ? That would be only thing I’m concerned about before releasing.
EDIT: nevermind. I think that user merely configured things wrong on the eglot side. Feel free to update the Project.toml/Manifest.toml and tag a new release. 
I made a PR; I’m just going to use it a bit more to try and see whether there are regressions. If I (and anyone willing to try this version) don’t find any quirk, I’ll merge this in the coming days…
3 Likes