[racket-dev] Line editing in the default REPL

> I looked at the code a little, but I couldn't find the place that does
the fallback part.  (You're defining a `libreadline-path' which AFAICS
isn't used.)  But it looks like you're using the same interface for both
editline and readline -- right?  If so, then I think that it's better to
just keep the current setup, and do this:

>    (define libreadline (ffi-lib "libreadline" '("5" "6" "4" "")
>                                 #:fail (lambda () (ffi-lib "libedit"
...))))

Woops, thanks for pointing this out. I meant to put this here:

  (define libreadline (ffi-lib libreadline-path '("5" "6" "4" "")
                               #:fail (lambda () #f)))

This doesn't fallback to libedit if it can't find readline. It falls back
to a non line editing terminal if it can't find the requested lib.

The user needs to explicitly request readline or libedit. Although we could
have a third module that tries both before it falls back to a non line
editing terminal (or one that uses a line editor in racket.)

> And since that addresses an API that is shared for the two, then it's
not code that should be linked only with readline, which means that it's
fine to it by default...?

This does seem to be a common opinion among people here (at least Sam
seemed to share this same opinion anyway). And while it seems reasonable to
me, I've never heard this anywhere else.

Also, it would completely negate the FSFs reason for releasing libreadline
under the gpl. (Since libedit and libreadline share the same bindings, you
can almost always use them interchangeably.)

I'm thinking we should ask this on the debian-legal mailing list (as they
would probably have more experience). But if we can (legally) do it, I'm
all for it. :)


~Leif Andersen

On Tue, Dec 23, 2014 at 11:57 AM, Eli Barzilay <eli at barzilay.org> wrote:

> On Wed, Dec 17, 2014 at 12:35 PM, Tony Garnock-Jones <tonyg at ccs.neu.edu>
> wrote:
> >
> > 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
>
> I didn't run it, but guessing common keys isn't too difficult, of
> course.  I'm attaching a piece of code that I have that does that.  It
> looks to me like my code is much more ambitious -- I wanted to be able
> to have almost all possible keys with modifiers, including function keys
> and plain characters, and that makes it messier.  (I posted variations
> of this thing a few times in the past.)
>
>
> >> 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.
>
> Sure, but those are usually not specific too.  (You're probably talking
> about the DEC thing, right?  There's also the rxvt/aterm thing which is
> different and more weird.)
>
> In any case, terminfo for reading keys is obviously not too difficult to
> manage.  If that was all that you need, then it's very easy to write
> code that translates the terminfo database into some readable format
> that you can read in Racket.  (My code is basically doing that parsing,
> so it's 90% of what you need for that.)  But the thing is that terminfo
> is much more needed for the related things -- querying the terminal,
> using escape sequences to do the interactions (and doing that without
> restricting yourself to some small subset), and also sending sequences
> that setup the terminal (like rmkx/smkx which is what tripped me
> earlier, and IIRC, it's needed with at least st, possibly others too).
>
>
> >> 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.
>
> It looks like *you're* very aware of the issues, so why not take it?
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20141228/1e726ec7/attachment.html>