Ability to configure the context for racket-racket to operate?

[bhrgunatha]

With my configuration shell is somewhat poor - in particular with wide unicode characters that I have configured for my external terminal. Setting the encoding doesn't seem to help.

How feasible is it for racket-mode users to be able to configure the context for racket-racket to execute?

Although there may be many, many options perhaps we could limit it to a few. In order of my preference:

1. vterm
2. term
3. eshell
4. shell

A picture is worth a 1000 words (top: shell, eshell, bottom: term, vterm)

And how it looks in my actual terminal

I understand each has its own pros and cons but racket-racket should only be responsible for launching (if no existing buffer is present) and sending the required racket command.

This is a nice-to-have request for a niche use-case that I can almost certainly work around in my own configuration, so lets treat this as a discussion.

[greghendershott]

Both racket-racket and racket-raco-test use a private helper function, racket--shell.

This uses three hard coded values:

1. a buffer name (e.g. "*shell*")
2. a function to get or make such a buffer, which accepts the buffer name (e.g. #'shell)
3. a function to send a command plus newline (e.g. #'comint-simple-send)

Instead of hard coding them, I imagine instead it could get these from some new configuration variable, the value of which is a list of these three values:

(list buffer-name-string
      buffer-getter/maker-function
      send-string-plus-return-function)

From some quick/shallow research, what these values could be for various things:

:heavy_check_mark: shell

(list "*shell*"
      #shell 
      #'comint-simple-send)

:heavy_check_mark: term

(list "*term*"
      #'term
      #'term-simple-send)

:heavy_check_mark: ansi-term

(list "*ansi-term*"
      #'ansi-term
      #'term-simple-send)

:heavy_check_mark: vterm

(list "*vterm*"
      #'vterm
      (lambda (str)
        (vterm-send-string str)
        (vterm-send-return)))

Although there is no "vterm-simple-send", it seems equivalent to just vterm-send-string and vterm-send-return.

:question: eshell

(list "*eshell*"
      ???
      ???)

• Alas eshell has a different signature; can't make buffers of arbitrary names.
• Alas there's no "eshell-simple-send" or even "eshell-send-string" -- no obvious (to me) way to send strings programmatically.

---

TL;DR shell, term, and ansi-term follow a sort of "protocol". vterm nearly does; easy to shim it in. eshell seems awkward, but at least we provide a way for a user to configure this, provided they're willing/able to figure out the eshell end. Ditto for any other shells or terminals.

[greghendershott]

To follow up, although I don't know if this is still of interest to you, my suggestion would be something along the lines of commit 1b24709.

[bhrgunatha]

I apologise for not responding to my own question. I've had a lot on my 'personal' plate recently.

It is absolutely of interest to me and I'll check it out that commit soon.

I'll reply here again once I've had time to look at that commit and then close this, as it seems you've put in all the legwork I should have done (and did intend to do) after your previous comment.

I appreciate racket-mode so much because frankly it runs rings around DrRacket. I also heard a lovely rumour that the hash-lang branch may support more than just racket and racket/base and I'm excited to see the fruition of that research too if it pans out.

Thanks for everything Greg, all your hard work is much appreciated. I'm sorry I'm not able to support you financially though :(.

[greghendershott]

Oh, no worries at all. You clearly opened this as "start of a discussion", for a nice-to-have. No pressure on me, and shouldn't be on you, either.

[bhrgunatha]

This is working great! I tried all variations (term, ansi-term, vterm and shell) and they all worked just as expected for both racket-racket and racket-raco-test.

Exactly what I requested, thanks.

[greghendershott]

Thanks for helping by trying out the variations!

I'll go ahead and merge this.

p.s. Note that I didn't provide a default implementation for eshell. I'm leaving that for someone else to implement, someday/maybe, if they want to. But I'm pretty sure the basic "API" can support that or whatever else, too.

[greghendershott]

I updated the commit with some things for documentation and customization default choices. Now merged. Thanks again for the new feature suggestion.