bug#33403: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation

[Jose A. Ortega Ruiz]

On Sat, Nov 17 2018, Mark H Weaver wrote:

[...]

>> Ah, system* is a scheme call! So yeah, maybe we could add that call to
>> Geiser's guile initialization... i don't really see how that would cause
>> any problem elsewhere.
>
> I think something like this should be done, not only in the Guile
> initialization, but ideally in the generic Geiser code that connects to
> inferior processes via pseudo-tty.  After the pseudo-tty is allocated
> but before launching the inferior Scheme process, something like "stty
> --file=/dev/pts/N -icanon" should be run.
>
> However, before doing this, some warnings are in order:
>
> When in noncanonical mode, the normal processing of ERASE (usually DEL
> or Ctrl-H) and KILL (usually Ctrl-U) characters are disabled, and input
> characters are delivered to the subprocess immediately as they are
> typed, rather than waiting for the newline as normally happens in
> canonical mode.
>
> At least in the case of the Guile REPL, one notable side effect of
> running in noncanonical mode is that when a list is entered at the REPL,
> the 'read' returns as soon as the final close parenthesis is entered.
> Nothing after that is read, not even the usual newline.  The final
> newline is only read if the reader is not yet sure that it has finished
> reading the token, e.g. if a number or symbol is entered.  In those
> cases, typically any delimiter may be typed to terminate the read,
> e.g. space.
>
> To see this, you can try running Guile from a traditional terminal
> program (e.g. xterm or GNOME Terminal), and type:
>
>   (system* "stty" "-icanon")
>
> and then:
>
>   (display "hello")
>
> You will see that as soon as you type that close paren, "hello" is
> immediately printed, followed by another REPL prompt, all on the same
> line.

I think this is not an actual problem in Geiser.  In comint mode, the
stdin of the Guile process doesn't receive any input bytes until higher
level elisp functions send them, and that's totally under our control.
Repeating that experiment in a Geiser REPL, nothing is printed before a
RET (and, in fact, we might not even send the RET to Guile).

>
> You might also try (use-modules (ice-9 rdelim)) and then:
>
>   (read-line)
>
> and you'll see that the newline you type at the end of that line is read
> by 'read-line', which then immediately returns the empty string.  The
> input that you wish for 'read-line' to see must be typed on the same
> line, immediately after the close parenthesis.

Again, a comint/geiser REPL doesn't have this problem.

> So, it might be that Geiser needs to be adjusted somewhat to deal with
> these differences.

Seems we're lucky enough to be already adjusted :)

> Finally, you might consider the possibility that 'stty' might not be
> available in PATH, or fails for some reason, and ideally this case
> should be handled as well.

Yes, that's a real concern.  We should at least provide some kind of
warning.

> It might be simpler to always use REPL servers over a socket, than to
> deal with these headaches, although I don't know if that will be an
> option for the other Scheme implementations.

Not for all of them.  For Guile it's doable, but definitely not
"simpler", it requires some work and solving some unrelated corner
cases; but it might be worth the effort, because it's a cleaner
interaction mode (for instance, behaves much better in the presence of
multiple threads).

Cheers,
jao
-- 
Beware of the stories you read or tell; subtly, at night, beneath the
waters of consciousness, they are altering your world.
  -Ben Okri, poet and novelist