On Tue, Nov 25, 2014 at 1:29 PM, Leif Andersen <l...@leifandersen.net> 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 would be "wonderful", but doing it properly is
something that is difficult and easy to underestimate....
Just reading keys from a terminal is difficult (for example, IIRC,
Neil's charterm relies on some common escapes, and fails to read things
like shifted arrow keys or function keys). You'll need to be aware of
subtle differences between different terminals, obscure VT100 escapes,
and even more obscure xterm quirks like "modifyOtherKeys".
Then you need to deal with the trickyness of a proper editor, with
features like blinking a matching paren, and dealing with multiple lines
of input (eg, readline does multi-line inputs well and, including that
blinking). For fun, this includes another batch of fun stuff in the
same style as above, only dealing with the output side.
And all of that is just to get to the usual things like some rudimentary
parsing of the input like so you can have expression-based navigation
etc. (And this part could share some of the drracket functionality.)
> or having xrepl use libedit rather that libreadline.
This is probably much saner than the above, but it's still unclear to me
whether libedit can replace libreadline.
> 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.
I think that some readline/base split is an overkill. But if their
interfaces are indeed the same, then I think that Sam said that the
racket code can be considered as something that is written against the
editline API, so readline could use editline by default and use readline
as a fallback if it's missing -- with the overall result of being able
to use it by default without violating the GPLed readline.
> 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.
Translating the C code is not really needed -- it'll probably be much
easier to implement that functionality. The tricky bits of code are the
things that I listed above wrt terminal IO, I'm guessing that a simple
library just dumps the more sophisticated things like multiple line
inputs, paren matching, etc.
--
((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
