Re: Input line editing

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Fri, 13 Feb 2009 11:36:06 -0500 (EST)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> > Add paging (optional) to the processing.
> 
> Hmm, worth thinking about.  It would be relatively intrusive, as input
> line editing currently has nothing to do with output processing except
> for noticing when output happens (to drive auto-retype).
> 
> One thing I do not want is for output to have to bounce through the
> line editor process on the way out.  While ttys with ICANON set are not
> used for bulk data input (see upthread), they _are_ used for bulk data
> output, so the performance issue is no longer an automatic non-issue.

Hmm this somewhat reminds me that on AmigaOS line editing and history
was done by the NEWCON: device I think, which also supported a type of
xon/xoff-style paging where user could pause the output and resume
it, yet I don't remember of an automatic paging feature.  This was a
simple case as applications running under it expected NEWCON: to
provide line editing when in interactive+buffered/cooked mode;
Applications needing more fancy features would have to unbuffer console
and provide their own facility over CON:, or using existing libraries
like we see on unix also working in uncooked mode.

Then there are the examples of screen (which envelopes a tty and
provides paging/copy-paste and other nice features), or emacs, which
can envelope any CLI and provide its own editing features in the
buffer, which are userland-only solutions...  But screen won't provide
line editing, and emacs provides its own (mode specific rather than
application specific, although there could be a mode per application).

In your new system, if I understand, sh/csh/ksh could immediately begin
to benefit from a generic line editing facility provided by the tty (as
in the NEWCONS:) case without even having to be adapted to use the
libreadline wrapper?
-- 
Matt