bugGNU Screen - Bugs: bug #33756, Cursor positioning fails due to...


bug #33756: Cursor positioning fails due to incorrect width assumptions

Submitted by:  Thomas Wolff <towo>
Submitted on:  Tue 12 Jul 2011 04:36:12 PM UTC  
Category:  Program Logic Severity:  3 - Normal
Priority:  5 - Normal Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  4.0.2
Fixed Release:  None Planned Release:  None
Work Required:  None

Add a New Comment(Rich Markup)

You are not logged in

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


Mon 10 Jul 2017 11:36:42 AM UTC, comment #2:

Transposing an absoulte position in a panel to the respective position in the terminal would just need to add offset values, and then again position absolutely.
No need to use relative positioning instead as I see it.

Thomas Wolff <towo>
Sun 09 Jul 2017 10:13:50 PM UTC, comment #1:

Can't fix, because transforming cursor coordinates is needed due to split support.

Amadeusz Sławiński <amade>
Project Administrator
Tue 12 Jul 2011 04:36:12 PM UTC, original submission:

Apparently screen transforms absolute cursor positioning escape sequences
from the application into relative ones towards the host terminal.

This is fatal practice whenever screen's assumption of character width
does not reflect the actual width on the terminal.

This is particularly the case if screen is invoked with a locale environment
not matching the terminal character encoding, e.g. with LC_ALL=C in a
UTF-8 terminal, see screenshot menu1.png where screen fails miserably
to position the menu borders (which are properly placed by the application).
Note that this (arguably misconfigured) environment is not unlikely to
occur in a network after remote login.

The problem occurs, however, also if locale setup is proper, due to the
many different versions of Unicode character width data. So around
double-width characters the problem may still occur and spoil the
display layout, see screenshot menu2.png.

I don't think this transformation (probably to save a few bytes occasionally)
is a proper thing to do, it is not transparent handling of the application's
escape sequences in any case. Please change it.

Thomas Wolff <towo>


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

Attach Files:

Attached Files
file #23645:  menu1.png added by towo (26KiB - image/png)
file #23646:  menu2.png added by towo (25KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by amade (Posted a comment)
  • -email is unavailable- added by towo (Submitted the item)
  • -email is unavailable- added by towo

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

    Only logged-in users can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-09 amade StatusNone => Wont Fix
        Open/ClosedOpen => Closed
    2011-07-12 towo Attached File- => Added menu1.png, #23645
        Attached File- => Added menu2.png, #23646
        Carbon-Copy- => Added towo

    Back to the top

    Powered by Savane 3.3