Consider defining a subtype of Base.REPL.AbstractREPL and running that inside of comint instead of (ab)using ansi-term
I have no idea about the difficultly level here and am definitely not volunteering to do it myself necessarily, but the less hacky way of solving the problems with ESS would be to do this instead of abandoning comint entirely.
Since julia itself already includes two REPLs, it shouldn't be impossible to include only the features that are compatible with comint from LineEditREPL without losing access to the niceties needed for things like using Gallium. Once the <:AbstractREPL was written, all that would need to be done would be to swap out the existing REPL for our shiny new one using this function here during startup, and we'd be golden. All the niceties of julia-repl without any of the funkiness.
Posting this here as an issue as a sort of long-term wishlist or to get any criticism that exists on the idea. This might even make more sense within ESS than as an alteration of julia-repl.
I think this is an interesting approach. I agree that ansi-term is a pain.
The roadmap for exploring this would be roughly the following:
- see what control characters are supported by
comint, - see what Julia needs, eg for the ASTInterpreter2, TerminalMenus (now in Pkg3), and
Base, - write this
<: AbstractRepltype in a package, - experiment with comint by calling from Emacs, with the startup function you describe,
- when it works, change
julia-replto use this.
1-4 don't involve any Elisp, can be done mostly in Julia. I will explore this in the medium run, but help is always appreciated.
(agree about Github vs Markdown, but formatted the Markdown, hope it is OK).
I looked into this a bit, with the following conclusion:
-
there is no need to write a new terminal type, you can just fool Julia into using a TTY with
TERM="tmux"; julia, even insidecomint, -
a process filter can capture ANSI escape sequences and simulate what happens a. ansi-color.el is an example in Emacs, b. example: making a progress bar work, c. example for Grails, d. simply filtering,
-
capturing input is trickier. I would start with checking if the process has returned the
julia>prompt yet, and if not, just generate and send control sequences or arrows etc.
Generic implementation notes:
So in contrast to what I thought above, there is very little need for Julia coding ATM, just getting one's hands dirty with comint and process filters. I will look into this, but this is a medium-run project. Will probably start a separate repository.
Hm. You're right; that's not at all as bad as I thought. Couple of stray thoughts:
- If this simplifies things enough, we should consider pushing it back upstream into julia-mode itself.
- It's really easy to trick julia into starting up using LineEditREPL even if
TERM=dumb. Just pass arguments like so:
julia -i --color=yes -e "ENV[\"TERM\"]=\"emacs\"". - The way I understand it, comint just sends whole lines at a time to the
process, so some ugly hacks might be required to get e.g.
;and?working.
Please let me know me know if you start working on this somewhere else. I'll make sure to comment on this issue if I get to it before you as well.
For what it's worth, regarding support for ;, ?, and ] in a comint-based buffer, it's possible to sort of cheat to make this work by writing a comint input sender function that replaces ?X with @doc X, ]X with pkg"X", and so on (ESS does this for ?: https://github.com/emacs-ess/ESS/blob/master/lisp/ess-julia.el#L101). I've written a little comint-based inferior julia mode for myself this way (I don't have it up on Github or anything yet though) and it seems to work well. I also managed to get the different prompts (shell> , help?> , (env)pkg> ) to appear correctly in the comint buffer by binding those keys to commands that insert their respective characters, and then check to see if they're right after the julia> prompt, and if so, set & unset the 'display text property to make julia> ? display as help?> and likewise for the other prompts.
If you'd like, I'd be very happy to spend some time in the next couple of weeks putting together a pull request that updates julia-repl to support a comint repl in addition to the term one. :)
A PR would be very helpful, or at least a link to your solution.
Okay, great! I'll get started and will submit a work-in-progress merge request when I have it working with julia-repl.