screen-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[screen-devel] [bug #33122] option to overlay messages normally, even if


From: T W
Subject: [screen-devel] [bug #33122] option to overlay messages normally, even if hardstatus is set in termcap
Date: Tue, 19 Apr 2011 19:53:20 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.1.16) Gecko/20101206 Lightning/1.0b1 SeaMonkey/2.0.11

Follow-up Comment #3, bug #33122 (project screen):

Just a little more background to make sure we're on the same page and
hopefully clarify the problem I see - this is my understanding having read
through the man pages and google:

Most pseudo-terminals have capabilities called "hs", "ts", "ls" and "ds" which
allow for an additional "status" line. This is in emulation of old hardware
terminals which actually had a hardware status line separate from the main
console screen. A lot of xterm emulators offer their window titlebar as said
"status line" and expect them to be accessed using ANSI escape sequences,
typically  27]2; (this is how bash prompts do it).

GNU Screen has its own concept of a hard status line but, by default, does not
use those standard escape sequences for xterm windows. So it needs to be
hacked with a termcap entry such as this (in the arch linux package's version)
which tells it to relay the right escape sequences to its own parent pty:

termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=E]0;:fs= 07:ds=E]0; 07

GNU Screen also has a mechanism to overlay messages in reverse-video in the
bottom left corner, or even the top right corner if the right compile-time
option is used. This is theoretically separate from any hardstatus mechanism,
but it is presently conflated with the latter in several ways.

The "hardstatus" option controls what Screen does when no "hs" capability is
available, or when Screen chooses to pretend there isn't, using the "always"
flag. In those cases it can divert messages meant for this abstract "hs" (such
as escape sequences passed from its own child processes) to one of its other
mechanisms, such as a set-aside lastline, or using the messaging mechanism, or
ignoring them. It seems like the "hardstatus" option should really be called
"how-to-emulate-hardstatus-when-there-isnt-one-or-we-pretend-there-isn't." For
instance, "hardstatus off" is equivalent to "hardstatus alwaysmessage %h".

I see 4 different possible combinations here:

1) hardstatus off, termcap unset: no hs, so ANSI sequences meant for xterm
titles are discarded. screen uses its message/lastline/ignore mechanisms to
relay internal messages.

2) hardstatus on, termcap unset: ANSI sequences are still discarded. For
messages, screen WOULD use hs, but there still isn't one, so same as before.
This is default.

3) hardstatus off, termcap set: this is the one you're recommending. ANSI
sequences will be accepted and sent to Screen's hardstatus mechanism, but use
of the termcap hs is arbitrarily switched off (we're
"pretending-there-isn't"). So EVERYTHING gets sent to the bottom corner.

4) hardstatus on, termcap set: both ansi sequences AND internal Screen
messages get sent to the termcap hs (i.e., the xterm title). This is the
annoying situation I described in my post, where Screen's messages will
interfere with the xterm title as set by bash PS1 and sometimes make it
disappear.

What I'd like is for ANSI sequences to make it to the terminal's hs, while
screen's internal messages remain using the message/overlay mechanism.
Presently screen's internal messages will automatically use any termcap hs
available, and it does not seem possible to configure it not to do that.

Please let me know if I've misunderstood anything, and thanks for your help.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33122>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]