Re: xterm_title Test Fix (delay removed)

[Tribhuvan <loka rcn com>]

esp for: Adam and Tomas,

Something ¿interesting? came up while I was working
with the code  in the 898 patch. The String-Terminator
in the xterm-title is not necesarrily being detected under
some circumstances.

You're familliar with the two routines:

/* Write the request for window title. */
{   ...   write(tty, cmd, e)  ...   }
and
/* Read the response.*/
{   ...   read(tty, &ch, 1)   ...   }

When reading the response one char at a time, we scan for
the xterm ascii escape  code: '\033' (or on some implementations
may be '\007'). Finding this is important because we expect that
the next character in the output is going to be the "ST" string
terminator, '\x9c'. If we don't find the ST, we run a risk of the
read() call not terminating and hanging. This is happening under
certain cercumstances.

The while loop containing the read() call contains the following line:

if (ch == '\x9c' && title[i-1] == '\033')
           break;

The "break" being called means we stop attempting to read
the output. 'tty' is closed, we store the result in 'old_xterm_title'
and go on our way. This line is critical as it is the line that stops
the read(). If neither the ST '\x9c' or the ESC '\033' are found,
the read() will not terminate and mc will never start. So, here
comes the first "interesting" part.

In the xterm distribution, the file ctlseqs.ms includes the following line:

ESC \           String Terminator (ST  is 0x9c)

which I believe translates to:

"in a data stream,
[ESC] followed by [BACKSLASH] means [end-of-string: ST]".

In C, we are assuming that:
ESC = '\033'  and  \ = '\x9c'  together make end-of-string.
( see "if" statement from the patch, above)

So in C, we may assume that the translation becomes:

'\033\x9c' == [ST]

I'm not sure if this is exactly right. Reasoning is as follows.

We may agree on ESC being either '\033' or '\007', but it's the
definition of BACKSLASH and ST that is causing some
confusion for me, and may explain the failure I've experienced.

To the best of my research, the simple keypress [BACKSLASH]
should be ASCII '\x5c', not '\x9c'.
So, if you take the statement from ctlsqs.ms (xterm dist)
a little more literally, it may actually read more like this:

ESC \           String Terminator (ST  is 0x9c)
or                                                       ^^^^^^^^
'\033\x5c' == (ST = '\x9c')
                          ^^^^^^^^
So does this mean that:

'\033\x5c' == '\x9c'  ....  [ESC] + [BACKSLASH] == [ST]
or
'\033\x9c' == '\x9c'   ....   [ESC] + [ST] == [ST]
or simply
'\033\x9c'  ==  [ST]

Naturally, the second line does not make logical sense.
The third variation is what the patch assumes.

Case in study:
When you do [Alt]+[BACKSLASH] on the keyboard
should get something different from [ESC]+[BACKSLASH].

In an mc session, if you keypress [Alt]+[BACKSLASH],  you
get the "unselect" dialog box to open. No stroke of genious
here, but note this:

If you stream the old_xterm_title to a running mc [see *note]
you get the old_xterm_title text apprearing on the command
line, and the "unselect" dialog box will appear as a bonus. This
means that the stream containing the xterm title string
terminates with the equivilant of [Alt]+[BACKSLASH].
Now, it's logical to say, if I can scan the [Alt] + [BACKSLASH]
out of the read() call in the patch, I terminate the read() call,
save old_xterm_title and move on.

[*note]
 To stream the xterm_title to a running mc, try this:
 set your xterm_title to "abcdef"
 replace the line (ch == '\x9c' && title[i-1] == '\033') with
 (ch == 'c') in main.c.
 (build & install)
 when you run mc, this will cause " def[ST] " to stream to the mc
 command line and the [ST] opens the dialog "unselect" box.
 this means that:
 old_xterm_title == abcdef[Alt]+[BACKSLASH]

The only problem for me is, I haven't been able to find exactly what
the [Alt] key represents in an "escape sequence".

Then I would change the "if" statement to something that's more of
a guarantee to run on a wider range of systems.

A possible application of results, assuming we can get the true/correct
value of String Terminator:

take out the:   int seen_esc = 0;   and replace with:

char esc = '\x00';   \* NULL *\

{ ... read()  ...  }
/* scan for the escape sequence */
if (esc == '\x00') {
               if ( ch == '\033'  ||   ch == '\007' )
                       esc = ch;
           }
/* scan for the String Terminator */
if (  ( ch == '\x9c' &&  title[i-1] == esc )
       || ( ch == '\x5c' &&  title[i-1] == esc ) )    
/* this isn't exactly right */

       break;

I know this email is a little long, but I hope I've been
clear and correct in my assumptions and research.

Thanks for your time, and I hope as a result, the critical
relationship between mc and xterm is all-the-stronger!

Also, the threading concept is working when integrated
with the patch898.

Last note:  Even though this pach (when complete) will
probably be disabled by default ( people really _should_
use the shell to update xterm title) it should at least
be the well written!

Tribhuvan(ji)