Num Lock prevents accelerators from firing
Brought to you by:
tringali
Menu
▾
▴
Logged In: YES
user_id=88136
This is a known problem and corrected in the CVS version
and the soon to be released 5.2 version. Suggest this be
closed.
Logged In: YES
user_id=11321
I suggest leaving this one open for now. I've reviewed the
fix in 5.2, and it doesn't work on a variety of X servers.
NumLock is not always Mod2 on all X servers. To do this
properly, we need to call XGetModifierMapping to figure out
which modifier bit is attached to NumLock, and then account
for that bit when registering accelerators.
Logged In: YES
user_id=11321
Almost forgot, see code for "xmodmap" as an example how to
do this.
Logged In: YES
user_id=11321
Fixed. Thank you, Steve.
Logged In: YES
user_id=1176518
I would like to request that this issue be reopened. I
don't know if these old, closed bug reports are still
checked - so if there is no response in the next couple
days, I will submit this as a new issue.
Anyway, this Num-Lock behavior seems to be so much a part of
NEdit over the years that it almost rises to the level of a
feature. I have used Nedit for years and years, from IRIX
to Linux, and am currently using version 5.4 on Mandrake. I
really don't understand why this bug is considered fixed.
It's always been in NEdit as far as I know, and is still
there long past the version 5.1 that this fix seems to refer to.
Over the years, it has been my habit to leave Num Lock on by
default. The duplication of Home, End, PgUP, PgDn, Ins, and
Del has always seemed useless to me, as these keys are
already present in a convenient block of their own on most
keyboards. On the other hand, I have liked numeric keypads
since my Commodore 128.
So when I'm working in Nedit I'm having a good time until I
need to save my work. As I reflexively hit CTRL-S to save
and see a red <dc3> or something appear, I think "sigh.
that's just nedit." and click to another window, turn off
Num Lock, return focus to nedit, delete the garbage, and try
again. It works then. But always I fall for this. Then I
have to force myself not to try to type numbers with the
keypad, as I'll just yank the cursor all over the place
instead now that Num Lock has been turned off....
And it spoils the effect of an otherwise beautiful program.
A text editor is all about text entry via keyboard, so
difficulties in keyboard handling just make the whole thing
seem clunky. It's a small thing, but it has a real
look-and-feel effect. I do not like any other text editors,
and pretty much use NEdit exclusively, but I have to admit -
the built in KDE editor, although crummy, at least doesn't
have trouble with Num Lock. So it IS possible to do this right.
I understand that there must be a good reason why such a
severe bug has persisted for so many long years. Perhaps we
could have a real discussion of the root causes of this bug
and the difficulties in fixing it, and hopefully brainstorm
some sort of real solution?
Thank you for your time, and I appreciate NEdit very much.
Tonight, though, I just realized that I was going through
the same thing over and over and would like to just get it
fixed. It's a small thing, but I'm sure that most people
who see it just stop using NEdit before they've even really
started, and I'm sure it'll make everyone happier once it's
resolved. Thanks again,
Morris Slutsky
Logged In: YES
user_id=11321
As far as I know this is fixed. If you would care to send
us reporoduction information, we can double check. This is
very X server dependent, so it's critical to send the output
from Help>Version and tell us what platform you are running on.
KDE is a non-issue: KDE uses Qt, not Motif. The existence
of a KDE application without this bug has nothing to do with
nedit, unless we somehow rewrite the entire app for Qt (not
likely).
There are additional problems with NumLock that prevent it
from working in some cases. I changed the title of this to
reflect that. Most annoying is NumLock prevents
accelerators from firing. The other one is, on some
platforms, NumLock does nothing at all - you don't get
numbers like you'd expect.
If we can repro it on some new platform, we'll open a new
bug. I agree with you, this is a core usability feature
that we've been struggling to work around for years.
Logged In: YES
user_id=1176518
Hi Tringali,
I appreciate your taking the time to open this old issue.
I'll try to give as much information as I can regarding
reproducability, and would be happy to check any settings or
run any test programs that you would like as this situation
develops. For now, I can give you the basics. My OS is
Mandrake Community 10.1. I'm running the KDE Release 3.2.3
included with this distribution. My Help/Version info is as
follows:
NEdit 5.4
Nov 20, 2003
Built on: Linux, Pentium, GNU C
Built at: Aug 20 2004, 23:29:47
With Motif: 2.1.0 [@(#)GNU/LessTif Version 2.1 Release
0.93.94] (UNTESTED)
Running Motif: 2.1 [unknown]
Server: Mandrakelinux (X.Org X11 6.7.0, patch level
2mdk) 60700000
Visual: 24-bit TrueColor (ID 0x23, Default)
Locale: en_US
Linux localhost 2.6.8.1-10mdk #1 Wed Sep 8 17:00:52 CEST
2004 i686 AMD Athlon(tm) Processor unknown GNU/Linux
--------------------------------------------------------------------------------------------------------
This bug doesn't happen absolutely every time I push CTRL-S
with the Num Lock key on, which is probably going to make it
hard to find. However, it will usually happen within 5 or
10 minutes of use. When I use NEdit, I've usually got about
3-5 windows open each with 200-300 line files or so in each,
and I save fairly frequently in whatever window I'm working
in. I'm generally working with .cpp or .java files with
appropriate highlighting mode on. I have gotten it to
happen with a single small .txt file, though, just by adding
a space at the beginning, CTRL-S, deleteing the space,
CTRL-S, maybe click focus away and back, after a few reps
it'll usually do that. The one consistent thing - CTRL-S
ALWAYS produces a <dc3> for me when this bug happens. It's
never anything else. Sometimes it'll be nice and save, but
if it produces garbage it's always <dc3>.
Thanks again, I appreciate your reopening this old bug
report very much, and I will be happy to assist in any
possible way. NEdit is a great editor, and I'm grateful for
all the work that's been and being put into it by you and
everyone,
Morris Slutsky
Logged In: YES
user_id=73597
Mandrake ships NEdit linked against Lesstif. The kind of
problems that you describe is typical for Lesstif.
I suggest that you install on of the binaries that you can
find at our website or here, at SF. Those are linked against
OpenMotif, which has fewer problems with accelerators. You
can find an rpm version here:
http://www.nedit.org/ftp/v5_5/executables/
Logged In: YES
user_id=11321
Try the website binary. If it works, then we know LessTif
is broken and we'll try to come up with a workaround. We'll
open a new bug for that, since this bug is that it didn't
work anywhere. Also, please send output from the coommand
"xmodmap", which should look something like this:
xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x6d)
mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x7f), Hyper_L (0x80)
mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c)
Logged In: NO
You can't just brush this problem under the rug. <dc3> still
appears in nedit 5.5.
steve41412895 {at} hotmail