tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Input line editing

>> * Performance.  Almost by definition, input line editing is for
>> human input.  Even the slowest NetBSD machine (hp300?) is fast
>> compared to humans.  (Still, one of the things that would need to be
>> done if this is looked at for the tree will be performance hit
>> measurements.)
> Applications that use line editing still sometimes handle bulk
> amounts of data.  [...example...interactive editing...pipe bulk data
> into it...]

Bulk data, sure.  But via ttys?  The design I have in mind makes the
line editing part of the tty driver as far as applications are
concerned, like the current "delete, ^W, ^U" line editing performed by
the kernel.  The only way applications need to care about it is for
hooks like application-specific editor commands or completion
behaviour.  And when it's not reading from a tty (eg, when reading from
a pipe), my scheme would be completely out of the loop.  Only programs
that read bulk data from ttys with ICANON set will see any overhead,
and I can't think of anything that does that.  (If you know of any, I'd
very much like to hear about it/them.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index