(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 <[email protected]> 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 <[email protected]> wrote: > >> On Wed, Dec 17, 2014 at 12:35 PM, Tony Garnock-Jones <[email protected]> >> 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! >> > > -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAAVaeECoi_cVgL9PpURoctetMo87ziYfc4Pt_0h62kmJ9R6iGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
