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

 
 

bug #32267: Latent bug in xterm mouse handling?

Submitter:  None
Submitted:  Thu 27 Jan 2011 09:35:02 PM UTC
   
 
Category:  Program Logic Severity:  3 - Normal
Priority:  * 5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  Cur Dev Sources
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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

    There are 0 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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code