<div dir="ltr"><div><div><div><div>> I looked at the code a little, but I couldn't find the place that does<br>
the fallback part. (You're defining a `libreadline-path' which AFAICS<br>
isn't used.) But it looks like you're using the same interface for both<br>
editline and readline -- right? If so, then I think that it's better to<br>
just keep the current setup, and do this:<br>
<br>
> (define libreadline (ffi-lib "libreadline" '("5" "6" "4" "")<br>> #:fail (lambda () (ffi-lib "libedit" ...))))<br><br></div>Woops, thanks for pointing this out. I meant to put this here:<br><br> (define libreadline (ffi-lib libreadline-path '("5" "6" "4" "")<br> #:fail (lambda () #f)))<br><br></div>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.<br><br></div><div>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.)<br></div><div><br>> And since that addresses an API that is shared for the two, then it's<br>
not code that should be linked only with readline, which means that it's<br>
fine to it by default...?<br><br></div>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.<br><br></div><div>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.)<br><br></div><div>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. :)<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><br></div>~Leif Andersen</div></div></div>
<br><div class="gmail_quote">On Tue, Dec 23, 2014 at 11:57 AM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Dec 17, 2014 at 12:35 PM, Tony Garnock-Jones <<a href="mailto:tonyg@ccs.neu.edu">tonyg@ccs.neu.edu</a>> wrote:<br>
><br>
> If anyone reading this has an interesting or unusual terminal they<br>
> like to use, please run<br>
><br>
> $ raco pkg install ansi<br>
> $ racket -l ansi/test-raw<br>
<br>
</span>I didn't run it, but guessing common keys isn't too difficult, of<br>
course. I'm attaching a piece of code that I have that does that. It<br>
looks to me like my code is much more ambitious -- I wanted to be able<br>
to have almost all possible keys with modifiers, including function keys<br>
and plain characters, and that makes it messier. (I posted variations<br>
of this thing a few times in the past.)<br>
<span class=""><br>
<br>
>> likely evolve into some form of a terminfo-like facility. So it's<br>
>> better to just write something that can deal with terminfo directly.<br>
><br>
> Sadly, terminfo is a little anaemic with respect to the sequences it<br>
> specifies. To get input capabilities even half as rich as, say, emacs,<br>
> you have to go beyond what is given in the terminfo database in a couple<br>
> of ways. Specifically, to parse shift/control/meta combinations you need<br>
> to get into terminal-specific encodings that are not covered by terminfo.<br>
<br>
</span>Sure, but those are usually not specific too. (You're probably talking<br>
about the DEC thing, right? There's also the rxvt/aterm thing which is<br>
different and more weird.)<br>
<br>
In any case, terminfo for reading keys is obviously not too difficult to<br>
manage. If that was all that you need, then it's very easy to write<br>
code that translates the terminfo database into some readable format<br>
that you can read in Racket. (My code is basically doing that parsing,<br>
so it's 90% of what you need for that.) But the thing is that terminfo<br>
is much more needed for the related things -- querying the terminal,<br>
using escape sequences to do the interactions (and doing that without<br>
restricting yourself to some small subset), and also sending sequences<br>
that setup the terminal (like rmkx/smkx which is what tripped me<br>
earlier, and IIRC, it's needed with at least st, possibly others too).<br>
<span class=""><br>
<br>
>> it's the blindness of going in that direction and thinking that you<br>
>> *won't* fall into this trap.<br>
><br>
> It remains to be seen whether there are any problems resulting from<br>
> this approach at all.<br>
<br>
</span>It looks like *you're* very aware of the issues, so why not take it?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:<br>
<a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a> Maze is Life!<br>
</div></div></blockquote></div><br></div>