# Networked REPL?
**URL:** https://discourse.julialang.org/t/networked-repl/2085
**Category:** Internals & Design
**Created:** [February 13, 2017, 3:26pm UTC](https://discourse.julialang.org/t/networked-repl/2085 "2017-02-13T15:26:15Z")
**Posts on this page:** 17
**Page:** 2
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [April 26, 2018, 10:59am UTC](https://discourse.julialang.org/t/networked-repl/2085/21 "2018-04-26T10:59:00Z")
Setting the module for REPLCompletions would also make [https://github.com/JuliaLang/IJulia.jl/pull/651](https://github.com/JuliaLang/IJulia.jl/pull/651) better.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [April 26, 2018, 11:13am UTC](https://discourse.julialang.org/t/networked-repl/2085/22 "2018-04-26T11:13:27Z")
> [@jamii](#):
>
> Another thing I’m stuck on is inserting text into the repl itself, rather than faking a repl prompt. That way stuff that’s evaled from Emacs would still be in the repl history, and prompt-pasting would work without me need to re-implement it.
The original motivation for [julia-repl](https://github.com/tpapp/julia-repl) was to punt to Julia’s REPL implementation for all of the extra features (documentation, Pkg, shell) by pretending to be a terminal. Unfortunately, that design has proven to be a dead end, because Emacs’s terminal support is [buggy](https://github.com/tpapp/julia-repl/issues/24).
A major reconsideration of this approach is necessary, which will probably involve implementing an interface for quite a bit of functionality. While this is a burden, at the same time it can probably be made more friendly (eg make docstrings appear in a new window, render them from Markdown or HTML, add a menu-driven interface for Pkg3 functionality, etc) — my ideal is something like [SLIME](https://common-lisp.net/project/slime/). I will probably also involve some PRs to packages and Base separating functionality and interface.
Jumping to source code locations should be trivial, just filtering for a regex. I will look into making it work with your code.
---
### Author:  [@antoine-levitt](https://discourse.julialang.org/u/antoine-levitt)
#### Post date: [April 26, 2018, 11:45am UTC](https://discourse.julialang.org/t/networked-repl/2085/23 "2018-04-26T11:45:57Z")
> A major reconsideration of this approach is necessary, which will probably involve implementing an interface for quite a bit of functionality.
That’s the approach followed by ESS, which works pretty well. If you’re considering moving away from the terminal approach (which I think is a good idea, terminal support in emacs is crap), please give it a go: it would be very nice to reduce the fragmentation of the emacs-julia ecosystem.
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [April 26, 2018, 12:24pm UTC](https://discourse.julialang.org/t/networked-repl/2085/24 "2018-04-26T12:24:09Z")
> [@Tamas\_Papp](#):
>
> Unfortunately, that design has proven to be a dead end, because Emacs’s terminal support is buggy .
We have similar issues with the new Juno REPL (not quite as bad though). We can fix ours by changing [this function](https://github.com/JuliaLang/julia/blob/67fc4fc53b745fec60e92013ea2a934cb8e02f11/stdlib/REPL/src/LineEdit.jl#L363-L436) and I’m mildly confident you might be able to fix the emacs issue as well (at least I recall seeing the behaviour from that issue when I made a mistake while trying to patch `refresh_multi_line`).
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [April 26, 2018, 12:45pm UTC](https://discourse.julialang.org/t/networked-repl/2085/25 "2018-04-26T12:45:03Z")
ESS was one of the first things I looked at to contribute to when I started using Julia in Emacs. Unfortunately, I find the code difficult to understand, I think this comes from it being mostly adapted to R/S/S-plus, which was then modified slightly for other languages.
---
### Author:  [@antoine-levitt](https://discourse.julialang.org/u/antoine-levitt)
#### Post date: [April 26, 2018, 1:04pm UTC](https://discourse.julialang.org/t/networked-repl/2085/26 "2018-04-26T13:04:57Z")
> [@Tamas\_Papp](#):
>
> ESS was one of the first things I looked at to contribute to when I started using Julia in Emacs. Unfortunately, I find the code difficult to understand, I think this comes from it being mostly adapted to R/S/S-plus, which was then modified slightly for other languages.
That’s true, but ESS is a pretty stable and established piece of software, and so you get a few goodies for free from that integration (ie the “feature to julia-specific LOC” ratio is pretty good).
---
### Author:  [@jamii](https://discourse.julialang.org/u/jamii)
#### Post date: [April 26, 2018, 5:31pm UTC](https://discourse.julialang.org/t/networked-repl/2085/27 "2018-04-26T17:31:21Z")
My goals aren’t really aligned with ESS - I want to support multiple editors (it looks like NeoVim/Emacs/Sublime are the main choices from my colleagues) and multiple languages (which are all implemented in Julia). So I’m trying to do as much of the work (parsing, display, debugger interface) as possible on the Julia side and keep the editor-specific code to a minimum.
I just saw that IJulia supports changing modules and they use the same REPLCompletions code that I do. If it’s possible to send new cells to Jupyter from the backend then I could use that as my display.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [April 27, 2018, 1:54am UTC](https://discourse.julialang.org/t/networked-repl/2085/28 "2018-04-27T01:54:37Z")
> [@antoine-levitt](#):
>
> you get a few goodies for free from that integration (ie the “feature to julia-specific LOC” ratio is pretty good)
I am not sure I agree. ESS is based on `comint`, and uses a lot of tricks to capture/redirect output. These can be very fragile and get very tedious to maintain after a while. I think that a client-server approach, as suggested eg by @jamii here, is the best way to go.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 27, 2018, 3:03am UTC](https://discourse.julialang.org/t/networked-repl/2085/29 "2018-04-27T03:03:29Z")
> [@Tamas\_Papp](#):
>
> I think that a client-server approach, as suggested eg by @jamii here, is the best way to go.
It seems like you are converging towards re-inventing Jupyter. Note there are already plugins for Atom ([hydrogen](https://atom.io/packages/hydrogen)), neovim ([nvim-ipy](https://github.com/bfredl/nvim-ipy)), [vscode](https://github.com/DonJayamanne/vscodeJupyter), and emacs ([EIN](https://github.com/tkf/emacs-ipython-notebook)) to talk to Jupyter kernels, as well as a bitrotted [plugin for sublime](https://github.com/maximsch2/SublimeIPythonNotebook). Why not work on these rather than re-inventing the wheel?
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [April 27, 2018, 6:18am UTC](https://discourse.julialang.org/t/networked-repl/2085/30 "2018-04-27T06:18:10Z")
I was not aware of EIN, thanks for the reference. Apparently the version you link was [abandonned](https://blog.jupyter.org/the-continued-existence-of-the-emacs-ipython-notebook-54bd1c371d57) then [taken up again](https://github.com/millejoh/emacs-ipython-notebook).
I prefer the buffer-REPL interaction approach to a single linear notebook, but maybe I can use parts of this.
If I am just looking for a protocol that sends stuff to a Julia process and gets output back from it, what’s the current standard I should consider, IJulia, LanguageServer.jl, or something else? My main concern is
1. dealing with queries by various interfaces (eg `Pkg3` uses `TerminalMenus`, is there a solution/workaround for that?)
2. other REPL modes: how to make documentation, shell, and pkg modes transparent to the user; as if using the terminal,
3. how to deal with the debugger (eventually).
I am comfortable with implementing frontends, but it would be nice to share work on the Julia side for the relevant hooks. I am not sure what is emerging as a standard.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 27, 2018, 1:45pm UTC](https://discourse.julialang.org/t/networked-repl/2085/31 "2018-04-27T13:45:00Z")
> [@Tamas\_Papp](#):
>
> dealing with queries by various interfaces (eg Pkg3 uses TerminalMenus, is there a solution/workaround for that?)
It could certainly be made to work in the Jupyter notebook and JupyterLab via Javascript widgets (potentially with some modifications to TerminalMenus to support other backends), but I don’t think the Jupyter protocol has defined a frontend-independent way to display a menu. However, the [Jupyter messaging protocol](http://jupyter-client.readthedocs.io/en/stable/messaging.html) includes a catch-all `metadata` field, and you could use this to define Julia/frontend-specific extensions. This allows you to re-use the “standard” Jupyter protocol for as much as possible while defining small extensions only where they are really needed.
The Jupyter folks are already [working on debugger support](https://github.com/jupyter/debugger), so again it seems better to join forces than to re-invent the wheel. In general, they are quite open to contributions.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 27, 2018, 1:51pm UTC](https://discourse.julialang.org/t/networked-repl/2085/32 "2018-04-27T13:51:40Z")
> [@Tamas\_Papp](#):
>
> I prefer the buffer-REPL interaction approach to a single linear notebook, but maybe I can use parts of this.
You mean like what JupyterLab [already allows](https://github.com/jupyterlab/jupyterlab/issues/450)? Don’t confuse the notebook front-end with the messaging protocol, which can be used for many different styles of front-end.
---
### Author:  [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)
#### Post date: [April 27, 2018, 6:14pm UTC](https://discourse.julialang.org/t/networked-repl/2085/33 "2018-04-27T18:14:32Z")
The problem with using Jupyter for this is that there’s a convention in some
Julia packages to provide functionality by tying directly into the REPL. The
most obvious example here is shell commands with `;` and help commands with `?`.
[IJulia provides both of those](https://github.com/JuliaLang/IJulia.jl/blob/e11ae261fee943eec665e90203cdab7dc4f0ee66/src/execute_request.jl#L141), but it’s currently just explicitly
looking for lines that start with those characters. Packages like
Gallium/ASTInterpreter2 won’t work at all in IJulia. Nor will things like the
C++ shell in Cxx.jl or LispREPL.jl.
I spent some time digging through IJulia and generally Julia’s REPL code to see
if there was a way to allow this stuff to work more generically, but I got more
than a bit lost and ran out of time to work on the problem.
For anyone wondering, outside of emacs I use IJulia console as my main REPL if I
don’t need something like Gallium, and it works very well. I do this since I
haven’t figured out how to get vi-style keybindings working with the default
REPL yet.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 27, 2018, 6:26pm UTC](https://discourse.julialang.org/t/networked-repl/2085/34 "2018-04-27T18:26:53Z")
> [@non-Jedi](#):
>
> The problem with using Jupyter for this is that there’s a convention in some
> Julia packages to provide functionality by tying directly into the REPL.
Yes, but that approach needs to be lifted to a more generic backend mechanism before any real client-server functionality can happen…
---
### Author:  [@cstjean](https://discourse.julialang.org/u/cstjean)
#### Post date: [April 28, 2018, 1:16am UTC](https://discourse.julialang.org/t/networked-repl/2085/35 "2018-04-28T01:16:27Z")
> [@non-Jedi](#):
>
> Packages like Gallium/ASTInterpreter2 won’t work at all in IJulia
[They can work](https://github.com/Keno/ASTInterpreter.jl/pull/65). I assume @Keno had already abandoned ASTInterpreter.jl at that point, so the PR got lost, but presumably it could be ported to ASTInterpreter2.jl
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [April 28, 2018, 4:29am UTC](https://discourse.julialang.org/t/networked-repl/2085/36 "2018-04-28T04:29:35Z")
This is why I think that for a workflow that involves
1. working in a buffer then
2. sending parts to the REPL
a terminal emulation is the cheapest option.
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [May 9, 2018, 12:23pm UTC](https://discourse.julialang.org/t/networked-repl/2085/37 "2018-05-09T12:23:28Z")
I’m very interested in these developments – they could be used to build something in the line of Erlang’s remote debugger. Which would be amazing, considering Julia’s distributed computing capabilities.
> **[Elixir Remote Debugging | Codemancers](https://www.codemancers.com/blog/2017-11-22-elixir-remote-debugging/)**
>
> Learn how to connect to a production Elixir node from the local shell and use the debugger GUI to set breakpoints and debug.
[Previous page](https://discourse.julialang.org/t/networked-repl/2085.md?page=1)