bugGNU Screen - Bugs: bug #32267, Latent bug in xterm mouse handling?

 
 

bug #32267: Latent bug in xterm mouse handling?

Submitted by:  None
Submitted on:  Thu 27 Jan 2011 09:35:02 PM UTC  
 
Category: Program LogicSeverity: 3 - Normal
Priority: 5 - NormalStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenRelease: Cur Dev Sources
Fixed Release: NonePlanned 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 27 Nov 2017 10:47:08 PM UTC, comment #2:

> octal 233 = hex 9B occurs in many UTF-8 characters


For this reason, xterm refuses to recognize incoming C1 control codes in UTF-8 mode; see also http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Control-Bytes_-Characters_-and-Sequences.

Some other terminal emulators, e.g. gnome-terminal and konsole recognize C1 codes in their UTF-8 representation, that is, C1 CSI is not the single byte 0x9B but rather U+009B encoded in UTF-8: 0xC2 0x9B.

I'm not sure what xterm does when it's not about recognizing incoming sequences, but about generating them (keypresses and mouse events). We should check what it does when it's asked to generate C1 control codes. I'd guess it also refuses that in UTF-8.

gnome-terminal doesn't have such an option of generating C1 sequences (neither 0x9B nor U+009B), and probably most other terminal emulators don't have it either.

Egmont Koblinger <egmont>
Thu 16 Jun 2011 01:00:25 AM UTC, comment #1:

No bug, screen correctly handles both
the seven-bit CSI = "\033\133" = ESC [
and eight-bit CSI = "\233"
as documented at http://vt100.net/docs/vt220-rm/table4-2.html
and at http://en.wikipedia.org/wiki/Control_Sequence_Introducer#Sequence_elements

True, octal 233 = hex 9B occurs in many UTF-8 characters, e.g.,
U+00DB LATIN CAPITAL LETTER U WITH CIRCUMFLEX = C3 9B,
U+011B LATIN SMALL LETTER E WITH CARON = C4 9B,
U+015B Latin Small Letter s with Acute = C5 9B, etc.,
but screen should continue to allow the eight-bit CSI
and other eight-bit DEC codes.
Hard to imagine any need to disable this obscure feature.

Peace
--Devon

Devon Sean McCullough <devon>
Thu 27 Jan 2011 09:35:02 PM UTC, original submission:

Hi all,

While studying the code with the idea of adding support for xterm's new "extended mouse mode" I noticed the following near display.c:3575

if (i > 5 && bp[0] == 033 && bp[1] == '[' && bp[2] == 'M')
{
bp++;
i--;
}
else if (i < 5 || bp[0] != 0233 || bp[1] != 'M')
continue;

The second conditional looks like a bug to me, based on what I know of vt200 mouse codes (bp[0] should never contain '0233' and 'M' should live in bp[2], not bp[1]).

Can somebody confirm whether this is a latent bug? Also, is there a reason why this wouldn't work:

if ( i < 5 || bp[0] != 033 || bp[1] != '[' || bp[2] != 'M')
continue;
bp++;
i--;

Regards,
Ryan

Anonymous

 

(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 egmont (Posted a comment)
  • -unavailable- added by devon (Posted a comment)
  •  

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

    Only logged-in users can vote.

     

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

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1