bugGNU Screen - Bugs: bug #15457, altscreen implementation is wrong

 
 

bug #15457: altscreen implementation is wrong

Submitter:  Howard Chu <hyc>
Submitted:  Mon 16 Jan 2006 02:14:40 PM UTC
Votes: 10
 
Category:  None Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  None
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 17 Jun 2008 11:47:46 PM UTC, comment #10: 

(Note that bug 19805, which appears to have met with Micha's approval, apparently provides this functionality as an option.)

Micah Cowan <micahcowan>
Fri 13 Jun 2008 08:40:00 AM UTC, comment #9: 

Micha has indicated he doesn't want to fix this, closing accordingly, unless there are some decision changes for this?

Micah Cowan <micahcowan>
  Spam posted by anonymous
  Spam posted by anonymous
  Spam posted by anonymous
  Spam posted by anonymous
  Spam posted by anonymous
Mon 08 Oct 2007 08:34:20 PM UTC, comment #3: 

I ask that this bug be given higher priority.

As it is, GNU screen trashes the command-line interface on mc (midnight commander).  Mc features a close integration of file manager and CLI.  However, raising and lowering the file manager screen (control-O) erases the results on the CLI screen.  For me, this makes screen largely unusable.

I see that bugs 19805 and 21125 are related to this one.

Thanks.

John L <johnl>
Tue 17 Jan 2006 02:16:25 AM UTC, comment #2: 

0) Your documentation disagrees with you, it says altscreen is "just line in xterm" screen.texinfo lines 2610-2613. And obviously somebody cared what xterm does, because they went to the trouble of copying all of the escape sequences that xterm uses for this feature when they implemented it. If this altscreen feature is really supposed to be something unique to screen, you shouldn't claim that it's like xterm, or usurp its command sequences.

1) This is really a weak argument, given that screen can handle 40-some sessions with arbitrarily large scrollback buffers for each. One more page-full of buffer space isn't going to make a dent. And freeing that buffer severely limits the usefulness of the alternate screen, you might as well delete all of the altscreen code. Done like this, the last text from a pager or editor disappears when you exit, and if you needed to refer back to it, you have to regenerate the text all over again. As performance tradeoffs go, this decision harms productivity much more than it could ever help.

2) OK. It's sloppy, but it's mostly harmless.

3) This is pretty odd, since the win struct does save the cursor position, but you explicitly override that in EnterAltScreen. If you really wanted this behavior, you could have saved memory and code by not defining the w_alt_x / w_alt_y fields and just ignoring that. Sounds like extremely fuzzy thinking here.

Howard Chu <hyc>
Tue 17 Jan 2006 01:03:10 AM UTC, comment #1: 

Well, maybe, but screen implements a "screen" terminal, not xterm, so I don't care much about what xterm does.
Let's see:

1) This is done on purpose to save memory.
2) IIRC I did that on purpose. It basically re-enters the alt-screen to re-sync with the application. The leave-alt-screen sequence works the way you want.
3) Implemention detail, I won't change this one. I don't see why it should remember the cursor position. If you look at some ti/te termcap entries, they contain extra code to save the cursor position.

Michael Schröder <mls>
Group administrator
Mon 16 Jan 2006 02:14:40 PM UTC, original submission:  

Three bugs:
  1) in a real xterm, the altscreen buffer is preserved when you swap back to the main screen. The current implementation always frees the alt buffer when you swap; the FreeAltScreen function should be removed and references to it should be deleted.
  2) in a real xterm, it remembers which screen you're in. If you're on a particular screen and reissue the command to enter that screen, nothing happens. The current implementation always toggles to the other buffer, regardless of what the actual escape code was.
  3) in a real xterm, it remembers your cursor position on each screen. The current implementation always sets the cursor to its position from the main screen, even when displaying the alternate screen. This tends to garble/overwrite whatever was on the alternate screen.

#1 is most important to me; I use shell aliases "xt1" and "xt0" to flip back and forth between buffers all the time. With the current behavior, there's nothing to flip back to after you exit the alternate screen. Most people probably don't notice the bug because the default xterm termcap defines the te sequence to clear the screen before leaving the alternate buffer. This is a bug in the xterm termcap entry, which is a separate issue.

#2 is relatively benign, but still ought to be fixed.

Howard Chu <hyc>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #2178:  dif.txt added by hyc (3KiB - text/plain - Patch for all three issues)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by micahcowan (Posted a comment)
  • -email is unavailable- added by johnl (Voted in favor of this item)
  • -email is unavailable- added by johnl (Posted a comment)
  •  

    There are 10 votes 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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-06-13 micahcowan StatusNone Wont Fix
        Open/ClosedOpen Closed
    2007-10-08 johnl Carbon-Copy- Added johnl
    2006-01-16 hyc Attached File- Added dif.txt, #3282

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code