Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#807653: nedit and numeric keypad
1,015 views
Skip to first unread message
Orvoine Bertrand
Dec 11, 2015, 5:40:02 AM12/11/15
to
Package: nedit
Version: 1:5.6~cvs20081118-9
Severity: normal
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
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nedit depends on:
ii libc6 2.19-18+deb8u1
ii libx11-6 2:1.6.2-3
ii libxm4 2.3.4-6+deb8u1
ii libxt6 1:1.1.4-1+b1
nedit recommends no packages.
Versions of packages nedit suggests:
pn csh <none>
-- no debconf information
Version: 1:5.6~cvs20081118-9
Severity: normal
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
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nedit depends on:
ii libc6 2.19-18+deb8u1
ii libx11-6 2:1.6.2-3
ii libxm4 2.3.4-6+deb8u1
ii libxt6 1:1.1.4-1+b1
nedit recommends no packages.
Versions of packages nedit suggests:
pn csh <none>
-- no debconf information
Paul Gevers
Mar 9, 2016, 4:20:03 PM3/9/16
to
Control: tags -1 confirmed
Control: reassign -1 motif
On 11-12-15 10:44, Orvoine Bertrand wrote:
> 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")
I can confirm this behavior.
> 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 ...
I trust your analysis on this and reassign to motif.
Paul
Control: reassign -1 motif
On 11-12-15 10:44, Orvoine Bertrand wrote:
> 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")
> 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 ...
Paul
Graham Inggs
Mar 9, 2016, 5:00:04 PM3/9/16
to
> On 11-12-15 10:44, Orvoine Bertrand wrote:
> > 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")
>
> I can confirm this behavior.
I confirm this behaviour in nedit as well.
> > 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")
>
> I can confirm this behavior.
It doesn't seem to affect all Motif applications though. I tried
'periodic' from the Motif demos and 'xmgrace' from the grace package.
Graham Inggs
Mar 12, 2016, 5:20:03 AM3/12/16
to
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/
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/
Graham Inggs
Mar 16, 2016, 3:20:03 PM3/16/16
to
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/
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/
Graham Inggs
Apr 4, 2016, 9:30:03 AM4/4/16
to
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.
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.
Paul Gevers
Apr 10, 2016, 4:10:03 AM4/10/16
to
Hi
On 04-04-16 15:20, Graham Inggs wrote:
> 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.
Always, or just with the patch?
> 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.
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
On 04-04-16 15:20, Graham Inggs wrote:
> 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.
window. So then the bug would still live in NEdit.
Paul
Graham Inggs
Apr 13, 2016, 2:40:03 AM4/13/16
to
On 10 April 2016 at 09:15, Paul Gevers <elb...@debian.org> wrote:
> On 04-04-16 15:20, Graham Inggs wrote:
>> 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.
>
> Always, or just with the patch?
That would be with the current 2.3.4 versions in Debian.
> On 04-04-16 15:20, Graham Inggs wrote:
>> 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.
>
> Always, or just with the patch?
i.e. including upstream's fix to #1300
Graham Inggs
Nov 1, 2017, 1:00:02 AM11/1/17
to
Control: notforwarded -1
Control: reassign -1 nedit 1:5.6~cvs20081118-8
Motif upstream closed #1649 INVALID.
Control: reassign -1 nedit 1:5.6~cvs20081118-8
Motif upstream closed #1649 INVALID.
markus
Apr 29, 2019, 6:20:03 AM4/29/19
to
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
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
Troy Loveday
Mar 11, 2022, 11:00:04 AM3/11/22
to
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!
--
Troy Loveday <tr...@ti.com>
Analog Technology Development
Texas Instruments, Inc.
Dallas, Texas
214-567-6463
!
! 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!
--
Troy Loveday <tr...@ti.com>
Analog Technology Development
Texas Instruments, Inc.
Dallas, Texas
214-567-6463
Alex Kent Hajnal
Dec 17, 2022, 10:40:03 PM12/17/22
to
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.
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.
Alex Kent Hajnal
Apr 28, 2023, 7:10:04 AM4/28/23
to
TLDR: Try running "XKB_DISABLE=1 nedit"
---
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).
---
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).
0 new messages