Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider defining a subtype of Base.REPL.AbstractREPL and running that inside of comint instead of (ab)using ansi-term #26

Open
non-Jedi opened this issue Mar 21, 2018 · 7 comments

Comments

@non-Jedi
Copy link

non-Jedi commented Mar 21, 2018

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.

@tpapp
Copy link
Owner

tpapp commented Mar 22, 2018

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:

  1. see what control characters are supported by comint,
  2. see what Julia needs, eg for the ASTInterpreter2, TerminalMenus (now in Pkg3), and Base,
  3. write this <: AbstractRepl type in a package,
  4. experiment with comint by calling from Emacs, with the startup function you describe,
  5. when it works, change 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.

@tpapp
Copy link
Owner

tpapp commented Mar 22, 2018

(agree about Github vs Markdown, but formatted the Markdown, hope it is OK).

@tpapp
Copy link
Owner

tpapp commented Mar 22, 2018

I looked into this a bit, with the following conclusion:

  1. 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,

  2. 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,

  3. 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:

  1. getting started with comint,
  2. advanced comint.

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.

@non-Jedi
Copy link
Author

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.

@dellison
Copy link
Contributor

dellison commented Jan 16, 2019

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. :)

@tpapp
Copy link
Owner

tpapp commented Jan 17, 2019

A PR would be very helpful, or at least a link to your solution.

@dellison
Copy link
Contributor

Okay, great! I'll get started and will submit a work-in-progress merge request when I have it working with julia-repl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants