#53 Ctrl + F1 stopped working in 3.0.1
Hello,
this is a copy of http://bugs.debian.org/597380
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.
Downgrading mlterm mlterm-common mlterm-tools to 3.0.0-1 fixes the issue. (Which shows that it is not X or my windowmanager that broke). I have verified the issue both with different windowmanagers (icewm and wmaker).
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.1revisions 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
An attached patch fixes this problem