Re: Combining Marks and Keyboard Input on GUI systems (was: Re: A

From: Otfried Cheong (
Date: Tue Oct 05 1999 - 16:19:49 EDT

> OK, but now if we are interacting with the same menu over a
> telecommunications link of some kind, the possibility for timeout
> -- and therefore a deadlock -- increases without bound, e.g. when
> the base character and the combining diaeresis go out in separate
> IP packets.

Forgive me, but this discussion seems to be endless and after all this
talk I still cannot understand what the supposed problems are.
(I understand that it is important for us to stick together and make
the world believe that we are here to solve all these `difficult'
problems, as otherwise we would all lose our jobs---but I'll make an
exception here and actually say something about this one.)

(1) "Difficulties in the design of (the equivalent of) an "expect"
    script that somehow has to recognize and handle prompts."

    It seems rather poor design to me to try to build Unicode
    character handling into "expect." Expect was never meant to
    recognize abstract characters, it is a simple mechanism to wait
    for byte sequences (without any interpretation!) on a stream, and
    to respond with certain actions (such as sending other byte

    Expect shouldn't try to interpret the sequences it receives, nor
    the ones it sends. That's not its job, and that would be
    completely useless. When writing "expect" scripts, you don't
    specify sequences of (abstract) Unicode characters, but concrete
    sequences of bytes, as they will be received or sent over the
    line. If you look at it that way, there is no problem.

    Sure, that means that an expect script will break if some crazy
    operator changes the internal presentation of a prompt from using
    combining characters to a precomposed one. So what? It will also
    fail if the operator changes the space in "Log in" to a
    non-breakable one, and anything less than full artificial
    intelligence isn't going to make this problem go away.

    Expect scripts are normally created by running a login session
    manually, while logging the system output to a file. Later, you
    use the byte sequences from the file to set up the expect
    script. What these sequences "mean" is completely irrelevant to
    expect. It would be counterproductive to try to add this kind of
    knowledge to it (or at least I cannot see any possible benefit in
    doing so).
(2) "It is not possible for an application to recognize single key
    presses representing A or A+combining ring."

    Let's ignore the fact that typical GUI applications don't get
    their keyboard input from a stream, but get it nicely prepackaged
    from a `windows' server, and let's look at a program running on a
    remote machine through a terminal connection.

    To take an example, let's look at a program called "vi" running on
    "", to which I'm logged in through `ssh' from

    Now, how does "vi" distinguish me pressing the ESC key (which is
    an important `command' in "vi") from me pressing the "Cursor Up"
    key (which happens to generate a sequence starting with 0x1b, the
    equivalent of the ESC key, and which is also a rather useful key
    to press in "vi")?

    You see, this is not a new problem. In fact, it has been solved
    for decades. In fact, it has been solved so well that you haven't
    even noticed that it has been solved before :-)

    I'll leave it as homework to figure out what the solution is (yes,
    I'm a teacher by profession :-)

Best wishes, and good night,
  Otfried Cheong

(4 am, after uncountable bottles of beer, so forgive me if I'm not
making any sense)

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