If you are new to emacs and like vim keybindings I recommend spacemacs, it makes initial configuration so much easier and there is a julia layer which is pretty good. Base emacs is a pain to get configured from scratch.
6 Likes
I’m actually using the spacemacs layer, but I really can’t make it gives me completion apart from basic language reserved words (using, function, …) and my defined variables. It never gives me completions imported packages, nothing, nor if I try to use the defined function nor with using the dot syntax (for example, if I try to use the Flux Chain function, I cannot get autocompletion nor for simply using Chain nor for Flux.Chain). In the spacemacs Julia REPL I can get autocompletion to work as intended.
Am I missing something? I used the :variable declaration suggested in the layer page, I even tried to use the instructions in the lsp-julia github page, but nothing actually worked.
you currently need julia 1.3 for it to work. lsp-julia currently only works with julia 1.3, there is a version that works with 1.4 but linting is broken.
Is julia 1.4 support going to work, at some point?
I really can’t stand using Atom and Juno, but at the same time it would be annoying to be forced to keep using an older (and older and older…) version of Julia.
You could try using eglot instead. Look in particular for eglot-jl which makes it particularly easy to set things up.
2 Likes
Anyway, I tried to switch to Julia 1.3 and I obtain the same behavior: the REPL shows true autocompletion while the buffer with the .jl file can complete only local variables and the basic words of the language (using etc).
I could even workaround this if there is a way to send line from the REPL to the buffer, but in the julia layer keybindings I find only the opposite “direction” (from buffer to REPL). There is a way to configure a keybinding for the opposite “direction”?
For what I can see, there is no eglot layer for spacemacs. I tried to use it as a normale emacs package and to activate it with julia-mode but I got no completion at all.
Have you waited for the SymbolServer to index all your dependencies? This can take a very long time. You can see that it’s done when you see a message like the following in the *EGLOT (projectName/julia-mode) events* buffer:
[stderr] [ Info: Received new data from Julia Symbol Server.
Until then, you might not be able to get any completion related to external packages (but perhaps you can still get completions based on your own code, I’m not sure).
Do I, in contrast with lsp-mode, have to use julia1.4 exclusively? Because I get an impressive amount of warnings for deprecated methods in the buffer you mention and then the init process fails
Yes there are warnings with Julia 1.3, but things should still work. Your error likely comes from the server not responding fast enough, so that eglot thinks it’s dead.
There’s an entry about this in the FAQ of eglot-jl. I would recommend cding to the project that you want to work with, and running the following command in a terminal:
julia --project=path/to/eglot-jl/ path/to/eglot-jl/eglot-jl.jl
It will probably take a (very) long time, but eventually you should get the message:
[ Info: Received new data from Julia Symbol Server.
Unfortunately, we don’t have (yet) any user-friendly way of measuring the progress of this indexation process. A patch has been incorporated in LanguageServer to log progress information to the terminal, but I don’t think it has been released in a stable version yet…
[EDIT] not so user-friendly, but you can look for files appearing in ~/.julia/packages/SymbolServer/vTGsB/store/ to get a sense of how fast the indexation process goes.
1 Like
I managed to get it working, but there’s a way to not having to re-do the whole process everytime? It really takes something like forever to connect with LanguageServer, doing it everytime I open spacemacs it’s kinda annoying.
Anyway, thank you VERY much for your suggestions and time
1 Like
The language server doesn’t know about the repl and vice versa. Therefore if you have a variable defined in the repl, you won’t get it in the autocompletion list.
The problem with eglot and spacemacs is that eglot doesn’t support flycheck and spacemacs doesn’t support flymake. The solution is to integrate flymake into spacemacs, but someone has to write a layer.
I have a working version of lsp-julia under GitHub - gdkrmr/lsp-julia. It works fine except for linting and I cannot figure out what the problem is. There are a number of github issues and patches to the different programs that have to interface to make a language server work, feel free to investigate.
2 Likes
EDIT: now it’s all broken again. I exited spacemacs, installed some Julia packages (ex: Flux and DataFrames, …) and now nothing is working anymore: I get no completion at all (sometimes it do not complete even reserved words like using).
What is going on?
sorry, but no idea if I knew I would have fixed it. I am currently updating my repo following the vscode plugin every couple of days in the hope that the problem resolves itself at some point.
1 Like
I was referring to @ffevotte suggestion to use elgot because I said it was working.
I red your suggestion for lsp-mode, I still have to try using your version.
Tanks to you too, obviously!
I don’t know… What does the **EGLOT (.../julia-mode) events* buffer say?
After many tears, pain and despair, I managed to get it working.
The last problem I have is that I cannot open a new .jl file and get eglot to work on that as in the first I open. Is it normal or am I missing something again?
I’m sorry for this incredible waste of your time.
I’m not sure what exactly you’re referring to here. Indexing the dependencies takes forever, but should be done only once per dependency version I think (i.e. I think that two projects depending on the same package in the same version should share the same indexed files, but even if that was not the case, you’d still have to index dependencies at most once per project).
If you’re speaking of the 20s. or so that it takes for the language server to start-up and begin sending useful information to eglot, then there is a PR currently open in eglot, which should help solve this by using a custom system image : this reduces start-up times to about 1-2 seconds. We’re waiting for more real-life tests before merging this; if you still have some energy after this “battle” against eglot and LanguageServer.jl, you’re welcome to try it and tell us what you think!
Nice to hear!
What should happen is that eglot spawns one LanguageServer process for each “project”. When the files you’re editing belongs to a project in the julia sense, this is what eglot also uses: the project root is the directory in which Project.toml resides. All files under this directory (recursively) will be handled by the same LanguageServer process.
If however, you’re editing a file that does not belong to a julia project, then eglot considers the current directory as the root of the project. All files in this directory (i.e. all “siblings” of the current file) are considered by eglot to belong to the same project.
There should be one *EGLOT (xxx/julia-mode) events* buffer for each eglot project, where xxx is replaced by the project name.
How much of this happens to you? Do your files belong to the same project or not? What’s happening when you open the second file?
3 Likes
@ffevotte now everything is working like you said, I don’t know why I were unable to use the same environment (the basic Julia environment) for two different files, being them in the same folder or not.
Today I turned on my PC and it got fixed.
Thank you again, truly, and forgive me for all this mess.
No worries. I’m glad this is working fine!
2 Likes