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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index