[racket-dev] Line editing in the default REPL

 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 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

> Then you need to deal with the trickyness of a proper editor, with
features like blinking a matching paren...

While these features are cool, they are things that can be added on later
(by extending the line editor I linked to above).


~Leif Andersen

On Wed, Dec 3, 2014 at 2:55 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:

>
> Eli Barzilay wrote on 12/02/2014 09:31 PM:
>
>> On Tue, Nov 25, 2014 at 1:29 PM, Leif Andersen <leif at 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....
>>
>
> I agree fully with Eli.
>
> Also, separate from practical benefit of having basic `readline`-like line
> editing in pure Racket, you could go gratuitously coolness factor on this.
> For example, I don't think I've seen a non-full-screen character-terminal
> REPL do syntax coloring, matching paren highlighting, and full up/down
> cursor navigation within a single REPL input.  That's labor-of-love
> coolness, and all who behold it will respect your name.
>
> ("http://www.neilvandyke.org/racket-charterm/" would help with some
> primitives and device portability, but you'd still have to layer a lot of
> work atop that.  Offhand, the most nonobvious tricky part I can think of is
> not getting program confused about where text and your cursor are on the
> screen.  Different terminals will have different behavior when cursor is in
> the last column, or cursor is in the last row and column, or you're
> inserting/deleting characters or lines (which some terminals will support
> differently, and others not at all).  You also have to decide how you want
> to handle the user experience of some kind of Ctrl-L redraw, since terminal
> screens get corrupted often by text written by other processes, Ctrl-L also
> helps mitigate terminal quirks you don't yet handle, and terminal-savvy
> people will expect a Ctrl-L.  It's possible to make a self-healing
> character terminal display, on those terminals that permit reading screen
> addresses and that have sufficient idle bandwidth, but I haven't heard of
> anyone doing that yet, and everyone just has a Ctrl-L.)
>
> Neil V.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20141203/a641b1ef/attachment.html>