[racket-dev] Line editing in the default REPL

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 both OS X, and most Linux distros have good
package management.)

I also think making readline/base use libedit, and readline use libreadline
is a bit of a red haring. As, afaik, they have the same API, it doesn't
make sense for one of them to be the 'base' of the other.

Here's another idea Asumu had (which I like), rather than bundling libedit
with racket, or hoping the user has it installed we can take something like
linenoise[1], and implement it in Racket (which is doable as the whole
thing is about 1,000 lines of code anyway). I think this would avoid the
dependency issue anyway.

[1]: https://github.com/antirez/linenoise


~Leif Andersen

On Tue, Nov 25, 2014 at 1:00 PM, Eli Barzilay <eli at barzilay.org> wrote:

> On Tue, Nov 25, 2014 at 11:38 AM, Sam Tobin-Hochstadt
> <samth at cs.indiana.edu> wrote:
> > On Tue, Nov 25, 2014 at 11:00 AM, Matthew Flatt <mflatt at cs.utah.edu>
> 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 (probably removing the
> > mandatory dependency on scribble/text/wrap)
>
> If this is the only dependency that stands in the way of making it more
> minimal, then it should be easy to make it dynamically loaded (like much
> of the other functionality it uses).  Just have a wrapper that
> dynamically requires the wrap function, and if it fails, it will just
> not do the wrapping.  (IIRC, the things that xrepl uses wrapping for
> fall outside of what you can get with a naive and quick implementation,
> like wrapping error messages where the indentation matters.)
>
>
> >  2 Have `racket/init` dynamically test of the presence of
> > "xrepl/main.rkt" as a collection-file-path, and load it if available.
> >  3 Have `racket/init` (or the `racket` binary) test for something like
> > `racket/init/extended` which would be part of "xrepl" and part of
> > other extended repls.
> >  4 Like 3, but have an additional package which depends on "xrepl" and
> > just contains `racket/init/extended`
> >
> > I prefer 2, 3, or 4 of these options -- it seems fine for "Minimal
> > Racket" to not have line editing, but I'd be interested to hear what
> > others expect.
>
> (3) and (4) sound to me like an overkill -- `racket/init' is already
> supposed to be extra interactive repl stuff, and adding an extra-extra
> thing seem like overcomplicating it.  (2) sounds perfectly fine though.
> Also, as I said above, getting (1) should be easy, but is that the only
> dependency that would fall outside of a minimal distribution?
>
>
> >> A similar question applies to "libeditline". Currently, for Linux and
> >> other Unix platforms (not counting "natipkg" variants), our
> >> convention is that native libraries are either part of the
> >> `[g]racket` executable or they are installed separately by users
> >> through the OS's package manager. 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".  Should "libeditline" become not only part of the
> >> Minimal Racket distribution, but even part of the Racket executable?
> >> Or should our convention and/or distribution infrastructure change?
> >
> > I was thinking that the "readline-core" package would dynamically test
> > of "libeditline", and if it's not there fall back to "libreadline".
>
> Why is it needed to have a core subset?  => What are the readline
> features that are missing from editline?
>
>
> > My opinion, as someone who isn't a lawyer but has read a lot about
> > this, is that this would not cause Racket to be a derived work of
> > readline.
>
> If that's valid, then that would be really nice.
>
>
> > If we don't want to do that, I see a few possibilities:
> >
> >  1. We ship xrepl in whichever way we decide, and change the message
> >  it prints when it can't find "libeditline" to suggest changing things
> >  or adding (require xrepl/readline) to .racketrc.
> >  2. We ship a copy of "libeditline"with xrepl as a built binary, even on
> linux.
> >  3. We statically link "libeditline" to Racket in the standard
> distribution.
> >
> > I think 1 sounds most appealing if we're not ok with dynamically
> > falling back to "libreadline".
>
> (1) sounds good, except that it must target naive users -- so suggetsing
> package installation is not a good idea.  An alternative to a printout
> would be a question:
>
>     I can't find editline (a library for line editing), but I see that
>     you have readline installed.  Use it instead?
>
> (And if readline does have some feature that editline doesn't, then the
> question can be always be asked.)
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20141125/46a23a82/attachment-0001.html>