I believe that in the Emacs Julia repl the ctrl-c commands and such can be executed by switching to a different mode.
Hi Thanks. How do I do that? I thought julia-mode was required?
Perhaps this may help: GitHub - PetrKryslUCSD/HowToUseJuliaWithCygwinEmacs: How to use Julia with Cygwin Emacs?
Thanks. I donât use Cygwin. Also, I didnât see anything there about the control c commands. My emacs is working OK otherwise, and I hesitate to start making major configuration changes.
I guess Iâll just use this on Linux, which is my biggest need at the moment.
My point was that there is a little bit of description of the Julia modes referenced in that write-up. I did not mean to suggest that you switch your Emacs set up. Follow the links to Tamasâs packages.
That is not my position at all. I think we should try to get every scenario to work, that is why Iâm trying to help you here to get to the bottom of what is going on with your setup.
The only thing Iâm not keen is if statements like âI donât know of anything that works on a Linux server connecting from Macâ are lingering around here on the forums. I have no doubt that your specific scenario right now is not working (and we should try to fix that!) but as far as I can tell the technical issues you are having are probably related to the specific combination of the remote access software you are using and VS Code (or maybe even electron, given that you said the same was true on Atom). But that does not even remotely cover the universe of scenarios that involve a Linux server and a Mac, and I donât want the casual user that might visit these forums to get the impression that in general the Linux/Mac combo is not worth trying.
We mostly rely on telemetry to get a sense of what is going on with the user base. I canât rule out that there is some bias introduced by the opt-in mechanism, but is seem unlikely to me that this would be a big effect.
I think for your specific situation, right now we are exploring two options, right? First, using the remote access software X-Quartz and second using the Remote SSH extension.
On the first option, the problem was that the e key was not mapped to the e letter, right? Did the information I posted here help with that issue? In particular, did you try to set the keyboard.dispatch setting to keyCode?
On the second option (using the Remote SSH extension), is there any reason why that wouldnât work for you? Apologies if I missed anything you pointed out, but quickly reading over the thread, I didnât see anything.
There might actually be a third option: you could try to use Visual Studio Codespaces with a self-hosted environment, the description for that is here. I havenât used that option very much, so not entirely sure whether that might be a good option.
That is a bug on our end 
By far the best thing you can do in these cases is to send a crash report. There should be a UI option popping up whenever the language server crashes where you can just click âYesâ or âSendâ or something like that. That will send information to the dev team of the extension that normally allows us to identify what is going on and then to fix things. We ship new versions of the extension pretty regularly (sometimes multiple times a week), and weâve been on a big project during the last months to fix every single bug report that comes in via crash reporting. Still not done, but we are getting very close.
14 Likes
Thanks. I do appreciate your help and work. I am sorry if I happened to overstate the generality of my issue. I would be interested to hear of future developments. Thanks also for trying to help with my mapping issue. I havenât managed to fix it yet, but may have another look now that you further pinpointed the configuration variables and files I need to look at.
Thanks, D
4 Likes
Dear David,
Iâm coming back to vscode on FreeBSD.
Starting vscode today I got the message update julialang? , and now I confirm It just works! 
Donât know what changed.
For info:
FreeBSD 12.1 release
Julialang.language-julia extension: 0.15.33
Vscode editor: version 1.43.1
Thanks for all the good stuff!
Rob
4 Likes
Awesome, that is great news!
Dear All,
I am going to keep this open (unless anyone objects) as I still think we have a way to go on this one. I wear two hats: researcher and educator.
I teach large lecture classes where I need something students can install and use easily and can get going with quickly, plus which is robust across platforms (Windows, Mac, various flavours of Linux). I can say that having tried everything suggested on here (thanks all!) that there doesnât seem to be anything that I could enable me to use Julia (the way I would like) for a large lecture class. The closest is perhaps Jupyter Notebooks, but this seems more useful as a tool for students to âfollowâ code written by others than to create their own.
As a researcher, I can say that of all the various suggestions here, the only reliable solution (handy and across platform) among those suggested has been the julia-mode/julia-repl add-in to Emacs, which I found very difficult to install and configure (thank you everyone who helped me!) but works great for my needs now that I have gotten it going.
[I have to add the footnote that this relies on my longstanding mostly-harmonious relationship with Emacs. I should mention that I havenât gotten plots working yet, but I am sure this is solveable]
I still remain open to suggestions!
There have been quite a few discussions around the teaching a class use case on the forum, so the search might be your friend. From memory one option that was frequently put forward was a local Jupyter server, maintained by the uni/department IT admins.
FWIW I change laptops/systems quite often due to work, and Iâve never encountered any problems with the simplemost Juno installation (download and install Julia from the Julia website, and then add the uber-juno package in Atom and let it do its thing).
4 Likes
Hi Thanks, I will have a look at those forums.
As for Juno, it worked OK for a while on my Mac, but just recently completely messed me up with something called âinkâ (which I never chose to install), and now Atom/Juno is completely broken (a known issue that is no-doubt fixable, but does not inspire confidence). As I mentioned above, remote windowing (which lots of students use) doesnât seem to work well with Atom or VSCode, especially from a Mac (this is due to the unsupported and out-of-date x-Quartz dependency which maybe someone will fix one of these days).
So for me, Emacs it is! [For now]
Thanks
I have used this for teaching (optional, users can bring their own device) and exams (mandatory, with no outside net connection), and it works great.
Chances are that the university IT department is already running Jupyter for R, so they just add Julia.
What did you use for exams, to prevent students from seeing each otherâs work?
I can confirm. For teaching I use either a REPL and the students are free to choose their editor (I really do not want to force anyone into any setup) or a local Jupyter server which I maintain (LDAP authentication). Of course I am lucky to be also a system administrator at our institute 
I usually pick Jupyter if itâs high-level analysis (where you make a plot every minute) and the other bare setup if itâs low-level stuff (algorithms, software design, HPC etc.). For latter, it really does not need much than this, in my opinion. It should give a good starter for anyone and they can tweak their setup later and try out different configurations.
2 Likes
They are logged in with their individual accounts, and thus cannot see each otherâs work because of plain vanilla Unix access control.
That said, I usually teach graduate courses to highly motivated students, so academic misconduct is not a high concern anyway.
4 Likes
Using the remote vscode extension works amazingly well for running vscode locally but working on a remote Linux server. It feels like local development and should avoid any xwindow errors because it uses your local vscode for display. Have you tried that?
Thanks JT. I had tried this and got it working and may come back to it. One concern is that I often like to disconnect and pick up where I left off, sometimes a day later. There was mention of a way around this, and I was just about to look into that when I started encountering a âJulia Language Server Crashingâ error in VSCode (an apparently known bug) on my local machine that I could not get rid of (this is unrelated to remote connection).
[This may be because I was trying out so many things (including suggestions from this thread), but for now I filed it into the âtoo hardâ basket and will have another look later on.]
Thanks, though, for your suggestion. It is encouraging that it works well for you. I guess if there were something analogous to âscreenâ (and as easy to use) this option would be especially attractive.
Fwiw, if you mean inline-plots, those arenât a supported feature of julia-repl. The jupyter emacs package does support inline plots/images, but itâs more complex to setup. Plots should still open in an external window (depending on the plotting package) in the same way as they would with the regular terminal julia REPL.
1 Like
Thanks n-J. I had forgotten to look for that window.
That works fine for the Mac now, Unfortunately it doesnât work for Ubuntu
[âGKS not in proper stateâŚâ]
even though I ran the recommended fixes by installing qt5-default and (re-)building GR.
On the other hand, the plotting in Jupyter seems to work OK, so there must be some way to plot without this GR thing? Perhaps someone knows?