Re: [racket-dev] Line editing in the default REPL

[Leif Andersen]

(I'm resurrecting this old thread, just as a reminder, I am trying to enable line editing for the default repl.)

I've updated my editline branch (in the readline repo) and submitted it as a pull request. It adds an `editline` package which has an API that is identical to the readline collection, except it uses libedit rather then libreadline.

https://github.com/racket/readline/pull/3

My current thoughts are this:

1. We make an xrepl/editline collection that binds to editline rather then readline. (While a bit ugly, it should allow us to release xrepl under the LGPL.)

2. Because we now have an xrepl that is LGPL, have the default racket repl be xrepl.

2a. In situations where someone would want a lightweight simple repl, we could still provide the original, non-xrepl repl.

2b. If the user requires the original (libreadline powered) xrepl, we could use that repl instead.

3. As xrepl seems to work without libreadline (or libedit) installed, and libedit is already readily available on most unix systems (as discussed above), we don't need to include it with the racket installation.

Does anyone have any feedback on the PR or defaulting to a libedit powered xrepl?

~Leif Andersen

On Mon, Dec 29, 2014 at 1:20 AM, Leif Andersen <le...@leifandersen.net> wrote:

> 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 <e...@barzilay.org> wrote:

On Wed, Dec 17, 2014 at 12:35 PM, Tony Garnock-Jones <to...@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!

[Asumu Takikawa]

On 2015-03-24 18:30:50 -0400, Leif Andersen wrote:
> I've updated my editline branch (in the readline repo) and submitted it as a
> pull request. It adds an `editline` package which has an API that is identical
> to the readline collection, except it uses libedit rather then libreadline.

And as an additional benefit, we can later put bindings in for the "real"
libedit (rather than its readline compatibility layer) in this package.

It turns out that the compatibility layer is deficient in several ways if you
want to write interesting line editing code (e.g., binding a new key shortcut).

> 3. As xrepl seems to work without libreadline (or libedit) installed, and
> libedit is already readily available on most unix systems (as discussed above),
> we don't need to include it with the racket installation.

In particular, downstream packagers can make the Racket package depend on
libedit (e.g., for Debian/Ubuntu). Mac has libedit by default AFAIK. I suspect
it won't work on Windows, but that's no worse than the status quo.

Cheers,
Asumu