Re: RE: A basic question on encoding Latin characters

From: Rick McGowan (
Date: Tue Sep 28 1999 - 21:07:00 EDT

Robert Brady wrote...

> Saying "abandon terminals" is not really an adequate solution either

I said nothing of the kind. I use terminals all the time, and I love them.

I actually said:

> one obvious solution is to design with an unambiguous command/
> response termination, like line-feed.

And that's what I meant. Obviously, packet based communication is here to
stay, as are tty-type interactions where you have to print what you've got to
give feedback immediately. And sometimes a packet is delayed. Fine. You
just have to design the protocols that have "expectations" so that they don't
have the particular flaws that lead to waiting forever to see if an umlaut
is going to arrive before printing an "a" or doing whatever it is they need
to do.

> Using decomposed characters in the input stream breaks things that
> were possible before.

So what? Isn't that something that happens all the time? All right, some
things are not possible any more, so why not move on and do something else?

> Sure, our metaphor couldn't cope with distinguishing "ch" from "c", but
> one thing it could do was distinguish "a-with-ring-above" with "a".

Well, that doesn't help, and it's not very useful to observe that it did
work with one limited model of written communication and doesn't work when
presented with a different (and I might add better) model. So design
something that works with the new model instead of complaining that it
doesn't work.

I suppose you could paraphrase me by saying, "don't abandon terminals,
abandon the inadequate protocols that don't work well with post-fix combining

I think many of the problems would evaporate if the Linux people actually
sat down and tried to do new-fangled "terminal emulation" from scratch,
assuming Unicode with combining marks, and not assuming the fixed-width
char-per-glyph kind of columnar space that worked in the past for ASCII. The
problems persist as long as one is required to deal with host systems that
can't be programmed. If you're interacting with some big old iron, well,
it's not going to change -- so why bother trying to bring it very far
forward? Leave it where it is and interact with it in the languages that
work with it.

Why not sit down and re-think terminal emulation -- write your own shells
and editors if you have to, on the host end. Then come around next year and
present a nice paper at the Unicode conference on these "new age" TTYs.


This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT