Re: a solution for high and dry xterm_title (long)

[Tomas Styblo <tripie cpan org>]

* Tribhuvan <loka rcn com> [Sun, 05 Jan 2003]:
> >From the point of view of the user the easiest way to restore
> >the title is to simply generate it in the PS1 variable as a
> >part of the command prompt.
> >
> I understand what you're thinking, but I think for average users
> without a firm grasp on even shell programming the overhead may
> just be a bit much (save for the learning experience). I like
> the xterm_title feature and have written an enhancement for it
> (for next posting), but maybe the restore feature can just be
> automatically turned off if we know a cheap/buggy terminal is
> running mc.

Well, this is going to be quite off topic ... I have an idea that
I have been playing with for a few last months. There are lot of
excellent terminal applications out there, and many people prefer
them to the GUI apps. In ten years these very same terminal
applications will still be excellent, modern tools, because there
is not much space left for real improvement in the areas of
presentation of information and computer-human interfaces.

For people, who like these terminal applications, GUIs are nothing
more than cumbersome eye-candy environment which cannot be
efficiently controlled using the keyboard.

But it's very convenient to run lot of these terminal applications
simultaneously in the X environment managed by some good window
manager. So it would be nice to have a consistent,
semi-standardized (at least in that "community" sense) way to set
the window title, which would work in all these terminal
applications. For me the title is very important. I have my
personal set of ugly hacks for lynx, links, pinfo, mutt, slrn
etc., which add the window title.

There are many problems, though. For the application it's hard to
detect whether the terminal actually supports the titles. For
example if you run an application inside a "screen" session in
xterm, then the TERM variable should be set to "screen", because
screen has its own terminfo entry. But unfortunately then mouse
and titles no longer work - mouse in vim stops working, the titles
stop working etc. That's because there is no way to tell whether
the screen application itself is running in the xterm or in the
linux console. The usual test "if $TEMP == rxvt || $TEMP == xterm"
is not sufficient. I use screen very often so I have to "fake" my
TERM variable - I set it to "xterm", instead of "screen".  This is
an ugly hack which works only by coincidence because the terminfo
entry for screen is not that much different.

The idea is to let the user define *whether* and *how* the title
should be displayed. For example some people prefer title format
"mydoc.txt - VIM", some other prefer "VIM: (mydoc.txt)". A new
environment variable could be defined. This variable
would serve dual purpose.

First, its mere presence would mean that the application should
activate the titles. Next, the content of the variable would
consist of printf-like codes defining the format of the title. 
For example:

    %a => name of the application (mc,vim...)
    %d => active document or resource (text file, URL, directory...)
    ...

Then the user could set XTERM_TITLE="%a: %d" in his
shell startup file and all the terminal applications he uses would
respect that setting and behave accordingly.

The hardest part would of course be to convince all the maintainers 
to actually accept the patches ... well, that's just such an idea ..

> Probably the safest thing to do is keep the switch handy to turn
> the feature on/off via one of the dialog windows.
> 
> I use a TERMINALS environment variable for a number of settings.
> export TERMINALS='xterm rxvt dtterm'
> if ["` echo $TERMINALS | grep $TERM`"]
> then ....
> An array in the source code could contain a names of safe terminals,
> then a "getenv($TERM)"  could determine if $TERM is a safe one to
> do the title refresh on exit -unless someone's spoofing...
> What else can you do in a polski fiiat? Let them pass you...

I am afraid that it will not work with dtterm no matter what you
do. Try this command in the shell:
    
    echo -e "\e[21t"

It should print the title. It will probably appear twice unless
you switch off terminal echo. If it does not appear at all then
you are out of luck with this terminal emulator.

A lot of terminal emulators which support changing titles do 
not support this function.

> In the meantime, I'm still working on the last patch - Solaris
> x86 uses SA_RESTART in <sys/signal.h> rather than SA_INTERRUPT.
> There's an #ifdef SA_RESTART earlier in the code I'm inserting
> into the refresh function to get around SA_INTERRUPT but it just
> hangs indefinitely without so far....

The patch should fix only the remote host issue. It does nothing
to solve the issues with dtterm.

SA_RESTART is the exact opposite of SA_INTERRUPT. If the shell
does not return anything in response to the title request then
the SIGALRM should interrupt the read() system call after five
seconds. The call then returns -1 and errno is set to EINTR.
That's how it works on my Linux machine.

If your system does not define the SA_INTERRUPT flag, then you can
try the following:

    - Simply do not specify the SA_INTERRUPT flag in the
      sigaction.sa_flags field. By default non-terminating signal
      handlers should not restart system calls if you install them
      via sigaction.
     
    - Try to call the BSD function:

        siginterrupt(SIGALRM, 1);

      before the call to sigaction.

...

-- 
Tomas Styblo <tripie cpan org>
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC97EA4B6