Dear Maintainer, When using NEdit, I am unable to use the numeric keypad to enter numbers no matter whether the numlock is on or off ( with the exception of key "5") wheezy nedit version is ok ( 1:5.6~cvs20081118-7 ) but not after (jessie, testing) If I recompil wheezy version on jessie, it's ok. Probably because 1:5.6~cvs20081118-7 depend's on lesstif2, and later depend on libxm4 ... sincerely
Control: tags -1 confirmed Control: reassign -1 motif I can confirm this behavior. I trust your analysis on this and reassign to motif. Paul
I confirm this behaviour in nedit as well. It doesn't seem to affect all Motif applications though. I tried 'periodic' from the Motif demos and 'xmgrace' from the grace package.
The problem seems to have been introduced in Motif 2.3.4. I built (Open)Motif 2.3.3 and the numeric keypad works in nedit. I also tried downloading and installing upstream's Motif 2.3.4-1 binary package [1] and only the 5 key on the numeric pad works in nedit. Unfortunately, upstream's bug tracker [2] is currently down so I cannot check if this issue has been reported already. [1] https://motif.ics.com/motif/downloads [2] http://bugs.motifzone.net/
Hi Upstream's bug tracker is back online. The problem with the numeric keypad was introduced by the fix to upstream's bug #1300 [1]. You can verify it for yourself by building motif 2.3.4, including the patch below to disable the fix:--- a/lib/Xm/Transltns.c +++ b/lib/Xm/Transltns.c @@ -56,7 +56,6 @@ #include <Xm/XmP.h> #include <Xm/TransltnsP.h> -#define FIX_1300 /* This is the new-style translation table, which is used with * versions of libXt that have the :-production translation fix Unfortunately, this disables the keypad arrow keys again. Fortunately, the fix [2] for #1300 is not too big. It might be possible to fix it for both numeric keys and arrow keys. Regards Graham [1] http://bugs.motifzone.net/long_list.cgi?buglist=1300 [2] https://sourceforge.net/p/motif/code/ci/27e707c68ef0be04754d656b9cf5eaa3c331f058/
For what it is worth, the proposed patch attached to upstream's bug, although slightly different to what was eventually applied, behaves in exactly the same way. I also noticed in other dialogs in NEdit, for example Search/Find and File/Save As... , that the numeric keypad keys behave as expected, following NumLock. I was only able to reproduce the problem in the main NEdit window. I think it would be worthwhile hearing if NEdit upstream have any comments.
Hi Always, or just with the patch? If I am not mistaken, the main window of NEdit is not a plain motif window. So then the bug would still live in NEdit. Paul
That would be with the current 2.3.4 versions in Debian. i.e. including upstream's fix to #1300
Motif upstream closed #1649 INVALID.
Hello, here a few findings from me: 1) NEdit's text window is different from Motifs text widget. IIRC it was derived from it some long time ago. This is the reason, why it behaves different. 2) I do recall in the early 2000s NEdit had some strange behaviours with CAPS-Lock and Numlock etc, so called "modifiers". Ctrl-S did not save when one of the modifiers was on but inserted an control code like <DC3>. In some later version of NEdit this was fixed. Maybe using some "tricks", which may still be in the code and interfere with a recent Motif. 3) There is a "magic" workaround: I have a "old" machine with NEdit 1:5.6~cvs20081118-8.3 + OpenMotif 2.2.3(*) (Debian 7.1) and a "new" machine with Nedit 1:5.6a-5 + Motif 2.3.4 (Debian 9.8). Recipe: Startup new machine and login via ssh to the old machine and invoke NEdit. Numeric keys work as expected just like working locally on the old machine. Now invoke NEdit on the new machine and the numeric keypad works for the rest of the day! (Until restart of X11 actually). It "works" the other way around, also: Startup old machine and login via ssh to the new machine and invoke NEdit. Numeric keypad is not working but also doesn't work with the local version of NEdit on the old machine. Until restart of X11. For me this is strange, not being familiar with X11-client-server topology. Maybe for someone else it provides a useful hint. (*) You have to self-compile NEdit with OpenMotif 2.2.3-4 to replace LessTif. Markus
A workaround for this problem is to put the following in ~/.Xresources (and load it with "xrdm -merge ~/.Xresources"):
!
! NEdit and Motif 2.3.4 (libXm.so.4) don't get this right,
! but this makes Num_Lock and numeric keypad numbers work.
!
NEdit*text.Translations: #override \
@Num_Lock <Key> KP_0 : insert_string("0") \n\
@Num_Lock <Key> KP_1 : insert_string("1") \n\
@Num_Lock <Key> KP_2 : insert_string("2") \n\
@Num_Lock <Key> KP_3 : insert_string("3") \n\
@Num_Lock <Key> KP_4 : insert_string("4") \n\
@Num_Lock <Key> KP_5 : insert_string("5") \n\
@Num_Lock <Key> KP_6 : insert_string("6") \n\
@Num_Lock <Key> KP_7 : insert_string("7") \n\
@Num_Lock <Key> KP_8 : insert_string("8") \n\
@Num_Lock <Key> KP_9 : insert_string("9") \n\
@Num_Lock <Key> KP_Decimal : insert_string(".") \n\
! Do Not delete the above blank line!
The tests I've run are interesting: When logged in to my desktop running Ubuntu 22.04.1, Xorg 1:7.7+23ubuntu2 I see the issue for: * nedit run locally * nedit run on my laptop via ssh * nedit run on my server via ssh When logged in to my laptop running Ubuntu 14.04.2, Xorg 1:7.7+1ubuntu8.1 nedit runs fine for: * nedit run locally * nedit run on my server via ssh * nedit run on my desktop via ssh It seems to me that the issue may actually lie in nedit's interaction with the running X server and not with a local library such as libXm.
--- I've investigated a bit more and it looks like the problem resides outside of nedit. I believe I've isolated the source of the problem to libXt, specifically when it is compiled with Xkb support[1]. I've submitted a bug report to libXt but in the meantime an easy way to get the keypad working again is to run nedit with the XKB_DISABLE environment variable set: XKB_DISABLE=1 nedit Note that this effectively disables Xkb support so may have knock-on effects.--- Links to related bug reports: * libXt: https://gitlab.freedesktop.org/xorg/lib/libxt/-/issues/16 * nedit: https://sourceforge.net/p/nedit/bugs/692/ * xnedit: https://sourceforge.net/p/xnedit/bugs/27/--- [1] The problem seems to lie in libXt's XtTranslateKey(...) function (in src/TMkey.c). When compiled with Xkb support this simply makes a call to XkbLookupKeySym(...) and does no further processing. I believe that what it should be doing is then processing the returned “list of modifiers that should still be applied” (per the XkbLookupKeySym(3) manpage).