Open non-Jedi opened 6 years ago
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:
comint
,Base
,<: AbstractRepl
type in a package,julia-repl
to 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 inside comint
,
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:
julia -i --color=yes -e "ENV[\"TERM\"]=\"emacs\""
.;
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.
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 ofjulia-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
.