[racket-dev] Line editing in the default REPL

Hi Eli,

On 12/13/2014 08:56 PM, Eli Barzilay wrote:
> there are definitely
> conflicts involving terminals that are relevant, like xrvt and
> gnome-terminal.

In my experiments (covering linux console, OS X terminal,
gnome-terminal, xterm, rxvt, aterm, screen and tmux), I haven't been
able to provoke any conflicts.

If anyone reading this has an interesting or unusual terminal they like
to use, please run

    $ raco pkg install ansi
    $ racket -l ansi/test-raw

... and press some arrow-keys, control-keys and so forth. Please let me
know if there are any conflicts, omissions, or unexpected results!

((NB. For some reason `raco pkg install ansi` isn't working for me at
the moment; an alternative approach is
    $ git clone https://github.com/tonyg/racket-ansi
    $ cd racket-ansi
    $ make link
    $ racket -l ansi/test-raw
))

> likely evolve into some form of a terminfo-like facility.  So it's
> better to just write something that can deal with terminfo directly.

Sadly, terminfo is a little anaemic with respect to the sequences it
specifies. To get input capabilities even half as rich as, say, emacs,
you have to go beyond what is given in the terminfo database in a couple
of ways. Specifically, to parse shift/control/meta combinations you need
to get into terminal-specific encodings that are not covered by terminfo.

Terminfo would be good enough for using oddball terminals with a simple
line editor, of course.

> <end>:
>   \eOq (!! (aterm mrxvt rxvt ... xterm-xi):
>            clash with <home> of (nsterm ... vt102))
>        (!! (aterm mrxvt rxvt ... xterm-xi):
>            clash with key_f0 of (xterm-r5))
>   \e[4~ (!! (... cygwin ... linux putty ... xterm-vt220):
>             clash with key_select of (... aterm gnome ... rxvt ...
> xterm-24 ...))

These conflicts don't appear to be real: that is, on all the systems I
tried, where \e0q was generated, it was generated in response to
pressing "home", and likewise for \e[4~ and "end".

> it's the
> blindness of going in that direction and thinking that you *won't* fall
> into this trap.

It remains to be seen whether there are any problems resulting from this
approach at all.

If anyone manages to provoke a conflict using `ansi/test-raw.rkt`, I'd
be very interested to know the details.

Regards,
  Tony