bug#34123: A patch to fix reading EOF characters in non-interactive mode

[Shawn Presser <shawnpresser@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]

I use Emacs Lisp as a runtime for Arc (https://github.com/shawwn/arcmacs) and
for Lumen (https://github.com/shawwn/y). The goal is to be able to run a
Lisp REPL from the terminal.

For example, in Arc:

  $ git clone https://github.com/laarc/laarc
  $ cd laarc
  $ make
  $ bin/arc
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc> 1
  1
  arc> (def my-repl ()
         (pr "> ")
         (whilet expr (read)
           (write (eval expr))
           (prn) (pr "> ")))
  *** redefining repl
  #<procedure: repl>
  arc> (my-repl)
  > 1 ; we can exit this inner REPL with control-D, without exiting the
program.
  1
  > (+ 1 2)
  3
  > ^D
  arc> "If this were emacs in batch mode, the program would have exited
with errors here."
  "If this were emacs in batch mode, the program would have exited with
errors here."
  arc> "Instead, control-D returned us to the toplevel REPL. Let's type
another control-D to quit."
  "Instead, control-D returned us to the toplevel REPL. Let's type another
control-D to quit."
  arc> ^D
  $

Please compare this with arcmacs, which runs in Emacs Lisp:

  $ git clone https://github.com/shawwn/arcmacs
  $ cd arcmacs
  $ ./y-arc
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc> 1
  1
  arc> (def my-repl ()
         (pr "> ")
         (whilet expr (read)
           (write (eval expr))
           (prn) (pr "> ")))
  arc> (my-repl)
  > 1  ; if we enter control-D, every REPL exits immediately and the
program quits
  1
  > 2
  2
  > ^D
  arc>
  $ echo We didn't intend to quit yet!

A single ^D exits the entire program, not just the inner REPL. This is
because after the user enters control-D, any attempt to call
`read-from-minibuffer` will always result in emacs throwing an error
with the message "Error reading from stdin".

The only way to gracefully handle this case in a script is to trap the
internal emacs error with (ignore-errors (read-from-minibuffer ""))
and to treat a nil result as if it were EOF. But that causes every
nested REPL to exit, since every attempt to (read-from-minibuffer "")
will throw "Error reading from stdin". In other words, emacs is
always failing to read from stdin after the user sends an EOF.

This patch fixes the problem by causing (read-from-minibuffer "") to
return nil if the user types control-D.


On Fri, Jan 18, 2019 at 7:25 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Shawn Presser <shawnpresser@gmail.com>
> > Date: Fri, 18 Jan 2019 04:35:34 -0600
> >
> > $ git clone https://github.com/shawwn/y
> > $ cd y
> > $ bin/y
> > > (read t)
> > Lisp expression: 42
> > 42
> > > (read t)
> > Lisp expression: ^Derror: Error reading from stdin
> > > Error reading from stdin
> > $
> >
> > Notice that it’s currently impossible for non-interactive scripts to
> recover from EOF when reading from tty.
>
> What would you want such non-interactive scripts to do after recovery?
>

[-- Attachment #2: Type: text/html, Size: 6769 bytes --]