6

I'd like to run txr lisp as an inferior-lisp process in Emacs.

From bash in xterm I can start a repl with txr -i.

txr -i works from xterm

I know I first need to change the inferior-lisp-program variable:

(setq inferior-lisp-program "txr -i")

Now I try to run it:

M-x run-lisp

After I type the expression I want to evaluate I press the enter key and I see escape codes rather than the evaluation.

enter image description here

I also observe this behavior on a fresh instance of emacs started with emacs -Q.

From the txr man page:

The interactive listener is based on 8 bit character processing. Its editing functions do not recognize UTF-8 multi-byte characters.

I've tried changing the buffer coding system with set-buffer-process-coding-system to raw-text and us-ascii with no luck.

How might I debug/fix this?

4
  • Note that it is possible to run the REPL from M-x ansi-term.
    – wdkrnls
    Jan 20 '17 at 0:25
  • 1
    Might Emacs be invokingtxr with a pseudo-TTY as stdin? In that case, all that VT100 based editing kicks in. There isn't any command line switch to disable it. The linenoise function does an isatty check on the input descriptor, and that's that. If that's the source of trouble, can a command like cat | txr -i be used as an Emacs inferior-lisp? If stdin is piped through cat, that prevents txr from seeing a TTY; cat sees the TTY, txr sees a pipe. Another idea would be to hack up a REPL in TXR Lisp code, bypassing the Linenoise library entirely. That would also have UTF-8 input.
    – Kaz
    Jan 25 '17 at 6:30
  • 1
    Rudimentary non-interactive REPL, with parse errors sent to standard output and exception catching: txr -e '(whilet ((line (get-line))) (catch (prinl (eval (read line *stdout*))) (t (msg) (put-line `** exception: @msg`))))'.
    – Kaz
    Jan 25 '17 at 6:38
  • I couldn't get cat | txr -i to work in inferior lisp, unfortunately.
    – wdkrnls
    Jan 31 '17 at 14:43
1

Emacs invokes inferior processes with a pseudo-TTY device as standard input. TXR's listener isatty to decide whether the input is an interactive device; if so, then it goes into raw mode and provides editing, driving the terminal with ANSI/VT100 codes. It ignores the TERM environment variable's existence status or contents, or other such clues for whether to drive the terminal, or with what escape sequence language.

Starting in TXR 174, the existing -n/--noninteractive option's meaning has been extended: if the option is present, it causes the listener to treat the device as a non-TTY and operate in "plain" mode: line-buffered input with no prompts, no editing features and no generation of any ANSI/VT100 codes.

In addition, an important bugfix has been applied to make this plain mode actually work correctly. Even if there is some trick in Emacs to run the inferior Lisp using just a pipe device, that bugfix is still required.

The fixes were tested using emacs as to their efficacy in supporting the inferior Lisp operation.

The -n option can "clump" with -i, as in txr -ni or txr -in.

2
  • Excellent. I like this even better than a prompt-oriented REPL. Thanks!
    – wdkrnls
    Apr 7 '17 at 2:49
  • 1
    In 175, there will be a :prompt command to print the current prompt (without incrementing the number), and a :p to just print the number without the >: like *n but not actually an expression. You need that info for accessing recently computed values by absolute number (modulo 100) like *42.
    – Kaz
    Apr 7 '17 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.