On 2010-09-19 Andreas Metzler <[email protected]> wrote:
[...]
> On 2010-09-19 Andreas Metzler <[email protected]> wrote:
[...]

>> After upgrading mlterm from 2.9.4-5 to 3.0.1-1 Ctrl+F1 (Open new
>> window/screen) has stopped working. On pressing this key-combination I
>> get the symbols "1;5~" instead of a new window.
> [...]
> I tried all post-lenny versions of mlterm available on
> snapshot.debian.org, the bug is not present up to and including
> 3.0.0-1.

Good evening,
To help things further I have made tests with each of the 11 patchsets
included in this new upstream version. Going from 3.0.0 to 3.0.1
revisions up to and including 1542 are fine, 1543 does not build and
1544 has the breakage.

For avoidance of doubt these two changesets cause the bug:

# HG changeset patch
# User arakiken
# Date 1275581332 -32400
# Node ID 4226a88a7d2f3156d3f9baddaadfdac98581cbd7
# Parent  e69795690ed6f04c23de0030c36a06d64b1775c8
* x_font.c: Returned value of get_cs_info() is checked.
* x_screen.c:
  Modifier keys with Del/Home/End are distinguished.
  The keypad middle key (XK_Begin, XK_KP_Begin) is mapped to ^[[E, ^[[1;5E etc.
  (SF Bug #2818015, Thanks to Thomas Wolff)
* x_screen.c: If Num_Lock is pressed, application keypad is ignored.
* x_window.c: XK_Num_Lock is not ignored in XModifierKeymap by default.

# HG changeset patch
# User arakiken
# Date 1275788803 -32400
# Node ID 0d2230d2d6a2410fc4e5d1e0bd2014bd5ff08a00
# Parent  4226a88a7d2f3156d3f9baddaadfdac98581cbd7
* x_win32.h: XK_Begin, XK_KP_Begin and IsKeypadKey macros are added
  for win32.
* etc/termcap: kh and @7 definitions are added to "xterm" and "*".
* x_screen.c: Fixed a bug which disabled keyboard input in application
  keypad mode.

cu andreas



-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to