> 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
On Wed, Dec 17, 2014 at 12:35 PM, Tony Garnock-Jones 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
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 prov
[I'll reply to your email separately...]
Sorry for not sending the results I had earlier re parsing input keys.
Just to get this recorded here in case someone wants to do this in the
future:
I was first optimistic about the prospect of parsing keys in a way that
works for all terminals, provided
On Sat, Dec 13, 2014 at 7:00 PM, Leif Andersen wrote:
> Okay, here's another idea.
>
> I have parametrized the readline collection over the readline/edit/etc.
> library. You can do:
>
>> (require editline)
>
> For the editline equivalent.
>
> It also falls back to no line editing (rather than thro
Okay, here's another idea.
I have parametrized the readline collection over the readline/edit/etc.
library. You can do:
> (require editline)
For the editline equivalent.
It also falls back to no line editing (rather than throwing an exception),
if the library is not there.
The source is here:
On Wed, Dec 3, 2014 at 6:22 PM, Sam Tobin-Hochstadt
wrote:
> On Wed, Dec 3, 2014 at 6:10 PM, Eli Barzilay wrote:
>>
If you're talking about implementing line editing yourself, then my
personal reaction to that would be "wonderful", but doing it properly
is something that is difficu
On Wed, Dec 3, 2014 at 6:10 PM, Eli Barzilay wrote:
>
>>> If you're talking about implementing line editing yourself, then my
>>> personal reaction to that would be "wonderful", but doing it properly
>>> is something that is difficult and easy to underestimate
>>
>> I've already done this (adm
On Wed, Dec 3, 2014 at 2:45 PM, Leif Andersen wrote:
> My goal was not to replace xrepl, but to provide basic line editing
> support to the default repl without licensing violations or massively
> increasing the distribution size.
Yes, that's exactly what I was talking about. I hope that you kno
My goal was not to replace xrepl, but to provide basic line editing
support to the default repl without licensing violations or massively
increasing the distribution size.
> If you're talking about implementing line editing yourself, then my
personal reaction to that would be "wonderful", but doi
Eli Barzilay wrote on 12/02/2014 09:31 PM:
On Tue, Nov 25, 2014 at 1:29 PM, Leif Andersen wrote:
Just to clarify a bit, we were more thinking of extending the default
repl to have line editing features, rather then making xrepl the
default,
If you're talking about implementing line editing yo
On Tue, Nov 25, 2014 at 1:29 PM, Leif Andersen wrote:
> Just to clarify a bit, we were more thinking of extending the default
> repl to have line editing features, rather then making xrepl the
> default,
If you're talking about implementing line editing yourself, then my
personal reaction to that
Just to clarify a bit, we were more thinking of extending the default repl
to have line editing features, rather then making xrepl the default, or
having xrepl use libedit rather that libreadline.
It would not be too terrible if we required a user to have it installed to
use it. (It's included in
On Tue, Nov 25, 2014 at 11:38 AM, Sam Tobin-Hochstadt
wrote:
> On Tue, Nov 25, 2014 at 11:00 AM, Matthew Flatt wrote:
>> Do you have in mind making "xrepl" intended to be part of Minimal
>> Racket? If not, what's the mechanism for `racket` using "xrepl" when
>> it's available?
>
> I can think of
On Nov 25, 2014 11:01 AM, "Matthew Flatt" wrote:
> We can't link to "libreadline" by default in a Racket
> distribution, and since "libeditline" isn't typically included with
> Linux distributions (as far as I can tell), it seems like we haven't
> solved any problem unless we provide "libeditline"
On Tue, Nov 25, 2014 at 11:00 AM, Matthew Flatt wrote:
> Do you have in mind making "xrepl" intended to be part of Minimal
> Racket? If not, what's the mechanism for `racket` using "xrepl" when
> it's available?
I can think of a few ways of doing this.
1 Just make xrepl part of minimal Racket (
Do you have in mind making "xrepl" intended to be part of Minimal
Racket? If not, what's the mechanism for `racket` using "xrepl" when
it's available?
A similar question applies to "libeditline". Currently, for Linux and
other Unix platforms (not counting "natipkg" variants), our convention
is tha
My understanding of the licensing issues is that if the code works with
both "libeditline" and "libreadline" then it isn't a derived work of
readline, and therefore could be licensed under the LGPL, like the rest of
Racket. Furthermore, turning use of "libeditline" on by default wouldn't be
linking
18 matches
Mail list logo
