Good day.
I use Atom. I like it. But unfortunately, it isn’t allowed to use two monitors for one project.
Would somebody suggest how to work on two monitors?
Thank you in advance.
Not an IDE really, but I have long done this all the time with vim. Admittedly I run multiple separate instances of vim, but it never bothers me much.
Emacs with julia-mode julia-repl and lsp-julia is pretty good.
3 Likes
Re: Juno (ATOM) with two monitors
If you select File>New Window and then in the new window File>Add Project Folder and add the same project folder as occupies the original window, you should be able to move one window to a second monitor and have any edits made in one window appear in the other.
1 Like
Thank you, I know it.
New window is the new Julia environment. But I need the it will be the same julia session. For instance there will be plots, workspace
Just a random idea but in theory it should be possible to make Atom or VS-code to start the Julia process in a terminal rather that in the background, that way you could have the REPL on one screen and the editor on another (I find having a large REPL to be quite useful).
I’ve been having a good time so far using julia-repl, but decided to give lsp-mode + LanguageServer.jl a try earlier today, and had a significantly less-good time. Took a bit of fighting to get things working on the Julia side (I had to downgrade JSON.jl, and manually ensure that LanguageServer.jl and SymbolServer.jl were at the newest versions), and ultimately I got things “working”, but my takeaway was that many features are still fundamentally broken. E.g. using company-lsp, doing a completion-at-point would crash the language server, as did a few other selections from the lsp drop-down menu while I was trying to explore the features.
Reading through the open issues made me think that the v0.12 release of LanguageServer.jl would be a significant step forward.
While I was perusing git issues and forum posts related to lsp+julia+emacs, I did notice your screen name pop up a few times. I’m wondering if the lsp-mode + Julia combo is indeed just rough around the edges still, or if you have a secret to making it work well.
1 Like
Yeah, this is a good solution, and Juno allows you to do this:
Instead of starting a normal internal Julia process, you can use the Julia Client: Connect Terminal command to automatically start a Julia process in an external terminal and connect that to Juno. You will still have access to all Juno features (except for keybindings that switch between the repl and the editor, obviously).
6 Likes
lsp-juliahad some changing maintainers, therefore the currently working version is in a forked repo (GitHub - gdkrmr/lsp-julia) and is not registered in melpa.- I am using the
spacemacsjulialayer, which takes care of the emacs side of things and everything works pretty well. - There is more than one lsp frontend for emacs (another one is eglot: GitHub - joaotavora/eglot: A client for Language Server Protocol servers), I only tried l
lsp-modebut since they implemented asynchronous startup I am pretty happy with it. - The julia server crashes from time to time and has to be restarted, my best guess is that this is an issue with
LanguageServer.jlbut I cannot say this for certain.
- There is the issue that often the latest release versions of all the
LanguageServer.jldon’t work with each other, which is something the maintainers ofLanguageServer.jlwould have to fix. - If you want versions that are guaranteed to work with each other, I recommend installing the same versions that are used with the VSCode extension, you can find the version here.
- As said above, for me it works pretty well in spacemacs, and it comes with many other perks, such as projectile and git integration. It is true that
lsp-juliahas received significantly less (probably the minimum amount of work necessary to get it to run for the few people that actually use it) work than the julia integrations for vscode or atom and therefore require more fiddling from the user’s side.
There is also the possibility to make julia work with jupyter notebooks in emacs, but I have never tried it (see: Emacs-based workflow)
1 Like
Thanks for the tips! In particular, this seems like it’s worth trying:
I’m hoping that this will solve the crashing on completion-at-point (since I’m assuming that tab-completion works in VS-code?). I’m thinking this may be a good opportunity to also give spacemacs a try finally, just to see what an “out of the box” lsp-mode + LanguageServer.jl setup is supposed to look like. Ironically, I have been using evil-mode ever since my days slumming it as an undergraduate (probably one of the first emacs packages I turned on), and have recently started using spaceline and spacemacs-theme, so I guess I’m not too far off from a piecemeal spacemacs setup anyways!
Overall though, this
makes me thinking that our experiences might not be too dissimilar, since after I got the setup “working”, I basically gave up on it after noticing LanguageServer.jl would crash upon certain common commands.
Curious: Does completion-at-point actually work for you in your setup? Or does that crash the language server for you as well?
I tried this out for maybe a week (just the jupyter term), but ultimately went back to julia-repl. My biggest gripes were that Debugger.jl is aware that you’re not using a “proper” terminal (and hence doesn’t work), the non-trivial latency when sending lines/buffers/files to the kernel, and that isearch didn’t seem to work well (I probably should have been a better FLOS citizen and filed an issue, but I gave up before spending much time debugging the problem; might be an evil-mode side problem).
Honestly, if not for the fact that term doesn’t play nicely with evil-mode, I’d be convinced at this point that julia-repl is basically the perfect emacs + Julia “mode” (lightweight, barebones, snappy, and native).
Yes, for me it opens a helm buffer with all the possible completions. I never had to use it, lsp-mode integrates nicely with company through company-lsp.
The way to make setup easier would be to do the same as vscode does and distribute LanguageServer.jl and friends in the correct version with lsp-julia and run the server as julia --project=/path/to/packages. This way it also won’t interfere with existing JSON.jl installs.
I have to use a Windows laptop that I have to use for work. Despite it having 4x the ram, twice the cores, and over twice the turbo boost clock speed as my old Linux laptop, it performs extremely poorly (while the Linux laptop has no issues). There is about a second of lag per keystroke with julia-mode. Hit a dozen keys (eg, hit C-n 12 times) , and it will freeze up for maybe 10 seconds.
Maybe I should file an issue, but I don’t know how if julia-mode + emacs being incredibly slow on Windows is a diagnose-able problem.
1 Like
FYI: there is a PR to lsp-julia that includes all the julia packages for LanguageServer.jl and should make the whole setup much easier. It would be cool if you could test it. When installing it, you have to make sure that the subfolder is installed, too. I haven’t tested this part yet.
1 Like
Sure, I’ll give this a shot (apologies to the OP if they are still around; I think I kinda hijacked this thread with my lsp-mode rantings).
gdkrmr: I’m going to PM you some first impressions, since they’re getting a little verbose (and off-topic). They’re taken directly from an org notebook, so disclaimer: they read like a thought dump.
In case anybody else is having the same issue I was (that completion-at-point in emacs would crash the julia language server), this fork of lsp-julia indeed fixes it!
1 Like
What exactly do you mean by two monitors? It Atom you can open a New Window and drag it across to another monitor.
Yes you can, but New Window isn’t the same project. You can’t open the plots and repl on the second monitors in Atom.
You can just turn off the Plots Pane and open an external terminal, which gets you pretty close.