Designing a read_line() with history - semantics?

[luser- -droog]

I'm writing a(n improved) terminal-interface for my APL interpreter
and targeting vt220 capabilities as implemented in xterm and putty.
Before adding it into the interpreter, I thought it might be useful
to spin-off something like rlswrap that could add line-editing and
history for other programs that don't do that.

But I'm not sure about the best choices for certain details.
So please jump-in with corrections/ideas if any occur.

Roughly, alphabetic/printable chars[1] get read from the terminal
and stored in the line-editor's buffer as well as echoed to the
screen. Backspace erases the last char from the buffer and prints
"\b \b" to the screen.

Left-arrow and right-arrow should move the cursor within the line,
affecting where new chars are inserted.

Up-arrow and down-arrow should navigate through the history, providing
the full text to the editor buffer. ... BUT what if you partially
edit a line from the history and then start going up and down again?
Does the partially edited line pop-up again as the element in the
history, or is it reset to the /historical/ history?

And a repeat sequence of UP RET UP RET UP RET, collapse into one
history item or add them all? Make it all configurable and force
the user to decide??

[1] actually, unsigned int ucs4 codepoints.

[Janis Papanagnou]

On 03.12.2016 03:50, luser- -droog wrote:
> [...]

>
> Left-arrow and right-arrow should move the cursor within the line,
> affecting where new chars are inserted.
>
> Up-arrow and down-arrow should navigate through the history, providing
> the full text to the editor buffer. ... BUT what if you partially
> edit a line from the history and then start going up and down again?
> Does the partially edited line pop-up again as the element in the
> history, or is it reset to the /historical/ history?

I find it more useful to have the current line be considered a part
(the "most recent" part) of the history, so changing would create a
new changed entry that's still present after scrolling. If one wants
to finally discard that line there's the option to let the user force
a 'discard line contents' control command or/and an 'escape' command
so that the specific change won't become a part of the new history.

>
> And a repeat sequence of UP RET UP RET UP RET, collapse into one
> history item or add them all? Make it all configurable and force
> the user to decide??

It depends. In most cases I am rather annoyed by the existence of
duplications, but there might be cases where it makes sense; e.g. if
you want to extract the history for reinvoking the sequence. If it's
possible in your context to configure the actual behaviour that may
be a good way to go.

Janis

[luser- -droog]

On Saturday, December 3, 2016 at 5:13:42 AM UTC-6, Janis Papanagnou wrote:
> On 03.12.2016 03:50, luser- -droog wrote:
> > [...]
> >
> > Left-arrow and right-arrow should move the cursor within the line,
> > affecting where new chars are inserted.
> >
> > Up-arrow and down-arrow should navigate through the history, providing
> > the full text to the editor buffer. ... BUT what if you partially
> > edit a line from the history and then start going up and down again?
> > Does the partially edited line pop-up again as the element in the
> > history, or is it reset to the /historical/ history?
>
> I find it more useful to have the current line be considered a part
> (the "most recent" part) of the history, so changing would create a
> new changed entry that's still present after scrolling. If one wants
> to finally discard that line there's the option to let the user force
> a 'discard line contents' control command or/and an 'escape' command
> so that the specific change won't become a part of the new history.

Yes, that makes a lot of sense. I'm trying to make the interface into
something of a hybrid between a command-shell or REPL style and a log
or notebook more like mathematica and modern APL IDEs. So I imagine
the history mechanics a little differently than bash for example.

As you type more and more commands, the lines scroll up in the terminal.
And the portion of screen taken up by the program is its "window", so
until you fill the screen, it isn't full-screen yet and you can still
see whatever was last on the screen above the window.

So up and down actually move you up and down, highlighting what appears
to be the very same command that was run. Theoretically, it could read
the characters back from the terminal screen. (I think there really is
a code for this, but don't worry-- not gonna actually do that) But I
think this behavior will be very "natural" for users, assuming it
functions correctly, FCVO 'correctly' TBD.

So I think I can incorporate what you describe by not allowing editing
/in/ the history, but have RET /select/ that history item, copying it
to the bottom line and jumping the cursor there where you can edit it
and its (new) place in the history is directly evident.

> >
> > And a repeat sequence of UP RET UP RET UP RET, collapse into one
> > history item or add them all? Make it all configurable and force
> > the user to decide??
>
> It depends. In most cases I am rather annoyed by the existence of
> duplications, but there might be cases where it makes sense; e.g. if
> you want to extract the history for reinvoking the sequence. If it's
> possible in your context to configure the actual behaviour that may
> be a good way to go.
>

Yes, with the APL interpreter setup, it can expose internals to the
user in several ways. The terminal code could query the symbol table
and APL can set and read the variable. Or the symbol table can make a
special "magic key/value" pair, which calls get/set functions instead
of storing and fetching a value. For the "rlswrap" side-project,
it should probably use cmdline options, though.

I posted prototype source code over in comp.unix.programmer. But this
seemed like a better group for the shell-ui behavior discussion.