bugGNU Screen - Bugs: bug #33122, option to overlay messages...

 
 

bug #33122: option to overlay messages normally, even if hardstatus is set in termcap

Submitter:  T W <twomen>
Submitted:  Tue 19 Apr 2011 10:27:09 AM UTC
Votes: 1
 
Category:  Feature Request Severity:  3 - Normal
Priority:  * 5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  None
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 26 Apr 2011 05:08:11 PM UTC, comment #5: 

I meant to get back to this earlier. Sorry. (sickness)

I think I understand now what you are requesting for (thanks for the detailed explanation): have a way to decouple 'the message line' from 'the hardstatus line'. I think this is a legitimate request. I probably won't work on this anytime soon myself, but if there were a patch, I would certainly look at it.

Sadrul Habib Chowdhury <sadrul>
Group administrator
Sun 24 Apr 2011 07:16:53 PM UTC, comment #4: 

With all due respect, would somebody mind either a) addressing my comments, or b) changing the status from "invalid" so that the bug has a chance of being seen by somebody who cares? Thanks.

T W <twomen>
Tue 19 Apr 2011 07:53:20 PM UTC, comment #3: 

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 \027]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=\007:ds=\E]0;\007

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.

T W <twomen>
Tue 19 Apr 2011 04:52:01 PM UTC, comment #2: 

No. "Hardstatus off" turns off the hardstatus feature entirely, so the "hs:...etc" termcap rules are effectively ignored and xterm titles have nowhere to go - in fact, they end up being printed in reverse-video at the bottom left corner along with the Screen-generated messages.

What I'm asking for is a way to divorce Screen's internal message mechanism from the hardstatus line in the event that hardstatus is ON ... see the documentation excerpt I quoted before. The distinction confused me at first, too, but I did do some research before posting this. :)

T W <twomen>
Tue 19 Apr 2011 04:13:32 PM UTC, comment #1: 

I think 'hardstatus off' is what you want?

Sadrul Habib Chowdhury <sadrul>
Group administrator
Tue 19 Apr 2011 10:27:09 AM UTC, original submission:  

Currently, if I want to let my bash prompt set xterm titles, I have to put up with Screen messing with them and causing them to disappear at times. This is because Screen automatically sends its messages to the terminal's "hardstatus line" if any exists. I see no way to change this. From the man page:

+Verbatim+
If your terminal has a status line defined in  its  term‐
cap, screen will use this for displaying its messages, otherwise a line
of the current screen will be temporarily overwritten and  output  will
be  momentarily  interrupted.
-Verbatim-

I would like an option to control this behavior and force screen to overlay messages normally - even if hardstatus is set in termcap - and leave my xterm title alone. Thanks. :)

T W <twomen>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by twomen (Voted in favor of this item)
  • -email is unavailable- added by sadrul (Posted a comment)
  • -email is unavailable- added by twomen (Submitted the item)
  •  

    There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-04-26 sadrul StatusInvalid None
        Open/ClosedClosed Open
    2011-04-19 twomen Carbon-Copy- Added twomen
    2011-04-19 sadrul StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code