[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Input line editing
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
Main Index |
Thread Index |