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

 
 

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

Submitted by:  T W <twomen>
Submitted on:  Tue 19 Apr 2011 10:27:09 AM UTC  
Votes:  1  
 
Category: Feature RequestSeverity: 3 - Normal
Priority: 5 - NormalStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenRelease: None
Fixed Release: NonePlanned Release: None
Work Required: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 1 encouragement so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 26 Apr 2011 05:08:11 PM UTCsadrulStatusInvalid=>None
      Open/ClosedClosed=>Open
    Tue 19 Apr 2011 08:16:16 PM UTCtwomenCarbon-Copy-=>Added twomen
    Tue 19 Apr 2011 04:13:32 PM UTCsadrulStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup