[racket-dev] Line editing in the default REPL

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: https://github.com/LeifAndersen/readline

I'm thinking we could distribute the editline collection with Racket
(treating libedit the same way we currently treat other native packages
such as libcairo). And then we can make xrepl default.

Would this be doable?


~Leif Andersen

On Wed, Dec 3, 2014 at 5:50 PM, Eli Barzilay <eli at barzilay.org> wrote:
>
> On Wed, Dec 3, 2014 at 6:22 PM, Sam Tobin-Hochstadt
> <samth at cs.indiana.edu> wrote:
> > On Wed, Dec 3, 2014 at 6:10 PM, Eli Barzilay <eli at barzilay.org> 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 (admittedly it only works on OS X, but most
> >>> Linux terminals work exactly the same with a few different
> >>> constants). You can see what I have so far here:
> >>>
> https://github.com/LeifAndersen/racket-line-editor/blob/master/main.rkt
> >>
> >> If this works, I'd be thoroughly impressed -- so I tried it.  I ran
> >> through a bunch of configurations that I use:
> >
> > None of which was OS X, which was what Leif's email explicitly said it
> > _only works on_.
>
> My point wasn't "it doesn't work outside of OSX", I was talking about "a
> few different constants" being a bad underestimation: they're not few,
> they're not constant, and the interfaces for getting them is what you'd
> expect from something that started to grow in the 70s.
>
>
> > I think we should wait till he has a version which he says works
> > before telling people to avoid making contributions.
>
> You should re-read my email: if there's anything that I'm telling, it's
> the exact opposite.  A point that I repeated more than once.
>
> The thing is that it would be easy to not say anything, and watch this
> approach of "try a few escapes and see what works" fail.  And it will
> fail, because, again, they're not constant, and you can't just get some
> magic combination that works for 90% of the people -- even just xterm on
> just linux is something that can (and often is) configured in many
> different ways.  So what I'm doing is the opposite: I point at how such
> a thing should be written for it to survive -- but I appreciate Leif's
> time enough to warn him that this is a much bigger thing than what he
> seems to think.
>
> (And to be clear, the reason for this is that I've seen probably around
> 3 to 5 serious attempts that got dumped; and I have encountered these
> issues multiple times, so I know that it's hard enough that even getting
> simple code to work, code that I intended only for my own use, even that
> was pretty hard, enough to go chase old VT references and obscure man
> pages.)
>
> --
>           ((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/20141213/772f47de/attachment.html>