> > I have always been of the opinion that timeouts were poor solutions
> > for interactive input. But, I have seen them used to effectively
> > improve input speed a little. However, I am more than willing to
> > sacrifice that capability for more generality. Besides, I have not
> > seen a situation where that kind of input is needed for quite a
> > while (with the exception of ftp and telnet); GUI's have taken over
> > the world.
>
> With or without GUIs: No timeout needed. Ten extra lines of code,
> two extra variables, and a little extra work for the computer.
>
> You need one variable pointing to the last non-combining character,
> and another describing the glyph's rectangle on the screen. Render
> what you have, and if the next character you get turns out to be
> another combining character, go back to the last non-combining
> character, erase that rectangle, and render as far as you can again.
>
> Putting combining characters before the non-combining character would
> make such speculative rendering impossible.
>
Agreed, for GUI representation it would be ok. But not when havinga a
command/program parser. Generally, when writing parsers, you want to
avoid as much look ahead as possible. Unicode forces you to always
read at least one character ahead.
Dan
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:31 EDT