#27 Can't enter numbers on numeric keypad

[Alex Kent Hajnal]

On some platforms the numeric keypad is stuck in navigation mode (irrespective
of the NumLock state)[1]. I believe I've isolated the source of the problem
to libXt, specifically when it is compiled with Xkb support[2].

I've submitted a bug report to libXt but unfortunately there does not
appear to be a simple way to work around this in xnedit itself[3][4].

The proper fix for this issue probably lies in libXt (assuming the problem
actually lies there).

---

Links to related bug reports:

• libXt
• nedit
• nedit Debian

---

[1] Except for the 5 key which does follow NumLock. This was first observed
by myself on Ubuntu 22.04 (jammy).

[2] 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).

[3] For nedit a workaround is to call the program with the environment
variable XKB_DISABLE=1 which effectively disables Xkb. For reasons unknown
this doesn't work for xnedit and would likely have knock-on effects if it did.

[4] There are suggestions that running setxkbmap -option numpad:mac will
fix the problem however I found that this works only occasionally, temporarily,
and inconsistently.

[Pyrphoros]

I tried to reproduce this bug on a freshly installed Ubuntu 22.04, however numpad input worked without any problems in xnedit. I tried Gnome (Wayland), Gnome (X11) and JWM.

I could however reproduce the problem with nedit. The difference between xnedit and nedit is, that xnedit creates an X input context by itself and uses Xutf8LookupString instead of XmImMbLookupString. However, there is a fallback path, when the XIC cannot be created and in that case XmImMbLookupString is used.

I think in your case, xnedit couldn't create the XIC. Can you test this by adding a check after XCreateIC in the file text.c line 1345?

    text->text.xic = XCreateIC(
            text->text.xim,
            XNInputStyle,
            style,
            XNClientWindow,
            win, 
            XNFocusWindow,
            win,
            NULL);
    if(text->text.xic == NULL) fprintf(stderr, "XCreateIC failed\n");

Would be interesting to know why this fails, but to reproduce this, I need more informations about the desktop environment, input method and locale settings.

[Alex Kent Hajnal]

Turns out I was inadvertently testing against an older copy of the Git code. The issue I reported was fixed in Commit [1d305b] . To be sure, I just downloaded a fresh copy of the source and it works fine. Fortuitously the patch in that commit also works to fix the issue in nedit so that's a nice bit of serendipity.

FWIW, I added the following after the call in both the old, problematic version and the current Git version of xnedit:

if(text->text.xic == NULL) fprintf(stderr, "XCreateIC failed\n");
else fprintf(stderr, "XCreateIC OK\n");

In both cases XCreateIC OK was displayed.

I'd be very curious to know what was causing the issue that that patch fixed. The symptoms were rather bizarre (to put it lightly).

I don't see a way to close this bug so could you go ahead and do so? Thanks for your everything.

[Pyrphoros]

I totally forgot this commit and my assumption was wrong. Glad it is working now.