Julia Spacemacs layer

Hi everyone. Just wanted to announce to any emacs/spacemacs users that I’m
working on a spacemacs layer for
. Based on the current
number of open PRs, I doubt it will be merged any time soon, but it can still be
useful even if it’s not in the core spacemacs distribution. While the ESS layer
already supports Julia, I think it makes sense to not keep the emacs Julia
experience so tied together with R. Also, integrating julia-mode with lsp-mode
already gets you a lot of the features from ESS, so it’s not like we need it
once lsp-mode stabilizes a bit.

I’m a relative newcomer to elisp, and as you can see in the PR description,
there are a few kinks with the layer right now, so I’d really appreciate any
help Y’all could offer. Especially helpful would be anyone who knows how to iron
out the mentioned kinks with lsp-ui or who’s interested in digging through the
ESS layer and moving the Julia-specific functionality into the new Julia layer
as an alternative backend.




Do you know about

? It is completely independent of ESS.

1 Like

FWIW ESS is not that tied to R - I use it for julia and don’t use R. Not sure about Spacemacs vs emacs, but more people use emacs than spacemacs, so would it make sense to make part of your package emacs-centric (and/or merge with julia-repl) and add a thin layer for spacemacs on top?

I always used julia with the ess layer in spacemacs, are there any conflict if you install both? I also use R and need ESS.

I also added some more key bindings: https://github.com/syl20bnr/spacemacs/pull/9920

I made a (failed) attempt to fix the language server: https://github.com/gdkrmr/lsp-julia
Did you get the language server to work?

Yep! And thanks! The spacemacs layer, if you click through, is really

just a thin layer of keybindings tying together your julia-repl with


Hm. I had been planning on offering ESS and lsp as alternative backends
to the Julia layer, but I haven’t tried them both together. Although
there’s a lot of overlapping functionality, it’s possible they don’t
conflict. Maybe the better thing would be to have toggles available
enabling both ESS and lsp rather than a switch where you have to pick

And ya, I did get lsp-julia working. The trick is that you have to
increase lsp-request-timeout from its default value of 10 seconds to
give Julia time to spin up. That’s what I did in the Julia layer, but I
should probably push that upstream to lsp-julia. Maybe I’ll wait until
the maitainer responds to my current 2 PRs, though.

Quoting gdkrmr (2018-03-08 04:45:38)

1 Like

Is lsp only for microsoft platforms?

Nope. Julia’s language server runs in pure Julia and on any platform that Julia runs on, and lsp-mode ties directly into the language server. I think there’s language server implementations for neovim and atom, too, but I’m less familiar.

Please do. Having a well-documented workflow for Emacs + lsp + Julia would be great. I can occasionally get it working but the experience is never smooth, so I always give up on it and decide to check back later.


Not sure if the maintainer at https://github.com/MartinWolke/lsp-julia is active or not, but I’ll at least push a fix to my fork at https://github.com/non-Jedi/lsp-julia in the next week or so. If he doesn’t merge the PR for an extended time, we can see about getting the links at https://github.com/JuliaEditorSupport/LanguageServer.jl pointed at my fork or something.

1 Like

There are some really useful features in ESS and spacemacs, like help integration by pressing K in normal mode.
ESS acquired the ability to integrate with emacs jump handlers recently (https://github.com/syl20bnr/spacemacs/pull/10281), it works perfectly in R, not sure about julia.
and then there is convenience stuff like sourcing a function with ,, or C-c C-c which works well in R but not in julia.
And not to forget that ESS has a complete debugger for R, I have no Idea though if this could provide an infrastructure for a julia debugger.

and not to forget ess-remote if you want your process to be on a remote machine.

  • [x] help integration (provided by lsp)
  • [x] jump handlers (provided by lsp)
  • [x] sending whatever to be evaluated (provided by julia-repl but could be
    improved tbh)
  • [ ] debugger. Better store with julia-repl than ESS since Gallium is usable
    there, but still work to do on both fronts.
  • [ ] ess-remote. Not familiar with it but probably not available in this setup.

EDIT: @gdkrmr, I encourage you to try out the layer in my PR in OP. Would love
to hear what functionality is missing from your perspective (You might have to
disable the ESS layer for everything to work properly atm).

I will do that!

with ess-remote you can transform any shell-buffer into a repl, you can do that after logging into a remote machine.

1 Like

Please do not hesitate to open issues/PRs.

1 Like

See my upstream PR here
please to increase the timeout. Or just pull from master on my fork for now.
Documentation still needs work (lsp-flycheck doesn’t exist anymore, etc.), but
one thing at a time for now.

Is this different than https://github.com/mgxm/julia-layer ?

Yes, although I hadn’t seen that one before. Goal of this is to get it actually
merged into spacemacs once I get time to finish it; that way we have a single
nice layer where we can control what backing packages are used (ESS, lsp,
julia-repl, etc.). Big difference right now is that this PR has a semi-working
lsp integration.

How has this been running? I saw this julia: to lisp or not to lisp? and am now interested in Julia.
EDIT: okay I looked at the comments from your PR. I’ll try it out, thanks for making this

I think it is pretty good and the experience is better than ess. I don’t really know why the spacemacs maintainers won’t merge this into the develop branch.

Agree. I’ve been watched that PR for a long time. Don’t know why it hasn’t been merged yet