Bug 239209

$ xxd
// switch worspace and back
^[hello
// ^D
0000000: 1b68 656c 6c6f 0a                        .hello.
$

So there's a superfluous escape. It appears as soon as I press the left Alt key, ie. before the workspace switch. And it doesn't happen every time.

Anoter thing connected with this

When in xterm, holding down the <Alt> key and repeatedly pressing <Ctrl> results in producing an <Esc> -- 3x<Esc>  means enter the shell auto-completion dialog, so after several <Ctrl> pressing you got this:

jotte@kobzol:~> 
Display all 3070 possibilities? (y or n)


<Alt> or <Ctrl> alone produces nothing. Probably connected with the workspace switch because usually <Ctrl>+<Alt>+<NUM> is used for workspace switching.

(In reply to comment #2)
> <Alt> or <Ctrl> alone produces nothing. Probably connected with the workspace
> switch because usually <Ctrl>+<Alt>+<NUM> is used for workspace switching.

I use Alt+Arrow for worspace switching and I observe it, too :-/

Hmm, I can reproduce it with plain xterm or xterm in fvwm2, so it's probably not an icewm bug... But I'll have a further look...

Hmm, even with this minimal xorg.conf:

    Section "ServerFlags"
      Option       "AllowMouseOpenFail" "on"
    EndSection

    Section "Screen"
      Device       "Device[0]"
      Identifier   "Screen[0]"
    EndSection

    Section "Device"
      Identifier   "Device[0]"
      Driver       "vesa"
    EndSection

I can reproduce the bug (Alt treated as Escape) by doing

  startx /usr/bin/xterm

So it looks like xterm bug to me. Stefan, what information do you need?

Cannot reproduce this within KDE.

I could reproduce it within KDE aswell. I'll try on different computers and with different xterm versions and let you know...

I can reproduce this in gnome, it happens constantly.

It is similar to Bug #141443 (comments #36 and #49), and I think another one I lost track of.

I managed to reproduce it on some more computer, so far I didn't find a box where xterm behaves correctly to start comparing.

Well xterm itself is not parsing the states - it relies on X library
calls such as Xutf8LookupString() to do the work.  From the discussion
so far, it's not apparent whether you are talking about a problem with
the X libraries or just getting confused by key modifiers versus the
key-repeat feature.

Can you please explain the role of the key repeat feature to me (comment 11)?

If i do a workspace switch and type "hallo", where is the key-repeat involved?

Or if i hold ALT and press CTRL, CTRL, CTRL (and it produces several ESC characters, while simply holding ALT produces nothing), how can the key-repeat of pressed ALT be a valid reason for producing an ESC?

I am not sure how can key-modifiers + key-repeat produce an ESC key. Please correct me if i am missing something.

Ah, forgot, the described problem occurs to me at OpenSUSE 10.2 (bugreports is filled against 10.3)

Jan: I can reproduce it both on 10.2 and Factory (10.3), but there can't be multiple products per bug, that's why I filed it against 10.3.

Thomas: I'm not telling that the bug is in xterm code, I just observe it when using xterm. I'd like to provide some more helpful info, but so far I couldn't isolate the problem somehow :-/

JFYI.

JFYI, Matthias. This is a bugreport, which is assigned to Egbert/me or with Egbert/me in CC or reported by Egbert/me.

Pressing alt  together with another key in xterm ineed produces an escpape preciding the character generated by this key.
This also happens in other terminals. The treatment of alt-ctrl is however different. alt-down ctrl-down ctrl-up alt-up 'a'-down 'a'-up
produces:
xterm: ^[a0000000: 1b61                                     .a
konsole: a0000000: 61                                       a
On shortkut sequences like atl-ctl-<numberkey> the application listening for hotkeys will issue a passive grab for <numkeys> after it sees alt-ctrl. So numkey isn't echoed to the window (xterm in this case any more) while alt-ctrl still are.
I'm not sure why alt-ctrl generates esc on xterm.
Maybe Werner has got an idea...

*** Bug 262330 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 262330 ***