Re: [Pan-users] How to use Numeric Pad 'Delete' key

[Duncan]

Maurice posted on Wed, 18 May 2016 12:04:48 +0000 as excerpted:

> On Tue, 17 May 2016 02:33:15 +0000, Duncan wrote:
> 
>> So first thing, try toggling numlock and see if it works then.
> 
>    (This also applies on my Mageia-5 desktop, by the way)
>    
>  No difference whether Numlock is 'on' or 'off'.
>    
>> Then take a look at the accels.txt file in $PANHOME (~/.pan2 by
>> default).
> 
> cat ~/.pan2/accels.txt | grep delete

> ; (gtk_accel_path "<Actions>/Actions/delete-groups-articles"
> "<Primary><Shift>Delete")

> ; (gtk_accel_path "<Actions>/Actions/delete-article" "Delete")

OK, both entries are commented by the initial semicolon, so remain at 
their defaults.

But you didn't report the results from xev, which will show what hitting 
the keys actually produces from an X perspective, and thus what pan 
actually sees in terms of what keys X is reporting to pan as actually 
pressed.

For me, I get this printed by xev to my terminal window when I press the 
keypad ./delete key while numlock is on (and the xev window has the 
focus):

KeyPress event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 102893822, (180,36), root:(966,3098),
    state 0x10, keycode 91 (keysym 0xffae, KP_Decimal), same_screen YES,
    XKeysymToKeycode returns keycode: 129
    XLookupString gives 1 bytes: (2e) "."
    XmbLookupString gives 1 bytes: (2e) "."
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 102893920, (180,36), root:(966,3098),
    state 0x10, keycode 91 (keysym 0xffae, KP_Decimal), same_screen YES,
    XKeysymToKeycode returns keycode: 129
    XLookupString gives 1 bytes: (2e) "."
    XFilterEvent returns: False


So we see two events, keypress and keyrelease, with KP_Decimal the 
reported keysym, and a single "." decimal point printed.  (While I'm no 
authority on locales, I believe in other locales, KP_Decimal will remain 
the same, but instead of the "." it might be "," or something else.)


With numlock off, xev reports this, instead:

KeyPress event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 103402468, (180,119), root:(966,3181),
    state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 103402569, (180,119), root:(966,3181),
    state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False


So we see its the same keycode, but with numlock off, it's a different 
keysym, KP_Delete instead of KP_Decimal.  And there's no lookup string 
now.


For comparison, here's what hitting the dedicated delete key does:

KeyPress event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 103659757, (178,95), root:(964,3157),
    state 0x0, keycode 119 (keysym 0xffff, Delete), same_screen YES,
    XLookupString gives 1 bytes: (7f) ""
    XmbLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 103659857, (178,95), root:(964,3157),
    state 0x0, keycode 119 (keysym 0xffff, Delete), same_screen YES,
    XLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False


Different keycode, different keysym (Delete instead of KP_Delete or 
KP_Decimal), and interestingly enough, a different lookup string, hex 7F 
(decimal 127), which is indeed ASCII DEL.


Based on the above, I've changed my original position some, as I 
previously assumed the two deletes would produce the same lookup string, 
even if different keysyms, so I thought if pan was responding to only one 
it must be responding to the keysyms.  Obviously I assumed wrong.

It (now) appears to me that pan (almost certainly via gtk) actually uses 
the lookup string, ASCII DEL, and in ordered to make the keypad delete 
key function similarly to the dedicated delete key, you'll need to 
configure X to produce the same ASCII DEL lookup string.

That's out of pan scope and out of my easy area of knowledge, but I 
believe I can at least point you in the right direction.

Take a look at xmodmap and xkb.  I've never used the former (command), 
but have used the latter (xorg config, you're editing config files), 
fumblingly, to some extent, to get the "extra" keys on various internet/
media/fancy keyboards working over the years.

For the xmodmap solution, after a quick read of the manpage and a google, 
you'd presumably configure your desktop (I know and can tell you how to 
do it for kde/plasma...) to run a short script on X startup (if starting 
your desktop session from a text login using startx or similar, as I do) 
or login (if using a *DM based graphical login) that would do something 
like this:

xmodmap -e "keycode 91 = Delete"

After I run that manually from a terminal window here, pressing the 
keypad delete key now gives me Delete for the keysym, and the hex 7f 
lookup string in xev:

KeyPress event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 107201547, (1,179), root:(963,1284),
    state 0x0, keycode 91 (keysym 0xffff, Delete), same_screen YES,
    XLookupString gives 1 bytes: (7f) ""
    XmbLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2000001,
    root 0x4c0, subw 0x0, time 107201647, (1,179), root:(963,1284),
    state 0x0, keycode 91 (keysym 0xffff, Delete), same_screen YES,
    XLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False


So it looks like that should work, but of course note that it will affect 
the key in a similar way when used with other apps, not just pan.  Also 
note that with the mapping above, numlock/shift no longer changes the 
mapping -- it's the Delete keysym regardless, now, so I couldn't use the 
numlock to switch it to numeric entry mode as I no longer have a decimal 
point key there!

Also, note that (based on googling) you'll likely have to rerun that 
script/command after returning from suspend or hibernate apparently 
resets it to the default.


Editing the xkb tables (as I've done, but fumblingly, before, here, so I 
won't attempt to explain how) should prevent that issue, but note that 
you'll probably have to reedit them if you update or otherwise reinstall 
the xkb package.


Another alternative is to run something like sxhkd, the "simple X hotkey 
daemon".  When this daemon is run it sets itself up to listen to the 
xinput stream (both keyboard and mouse) and will act on anything it sees 
that it has been configured for.  I use it here for a number of things, 
including hotkey chaining, and triggering various actions on the higher 
mouse button events[1].

The nice thing about something like sxhkd, other than its rather extreme 
flexibility in what you can configure it to do based on input events, is 
the fact that it only does them while it's running, and with the 
appropriate scripts, conditionally depending on what app is active.

So for sure you can configure sxhkd to intercept the KP_Delete key events 
and emit the delete key instead, and it'll only do that as long as you 
want it to -- kill sxhkd when you're done and everything will be back to 
default.

And with the appropriate scripts (I've coded my own here and can post 
them if necessary), you can further condition the commands sxhkd to for 
example only emit the delete sym and string when the keypad delete key is 
pressed, if pan is the active/focused application.

Tho configuring is a matter of editing text files, optionally with 
scripting, and while thus extremely powerful in what it allows you to do, 
will very likely scare away users who want a nice GUI to configure things 
with and are scared of the commandline and text-based config files.

---
[1] Upper mouse button events: 1-3 are standard left/middle/right, 4,5 
are now standard vertical scroll, 6,7 are very commonly but not quite as 
standardized horizontal scroll, and above that isn't well standardized, 
but I have a touchpad and run the xf86-input-mtrack driver, configured to 
emit the higher 8-20 mouse button events on various gestures such as 
pinch, rotate, and three and four finger swipes up/down/left/right.  So 
the driver emits those events, but apps don't know how to interpret them, 
and I need another layer to listen for those events and emit the 
appropriate keystrokes or run the appropriate commands, either globally 
or based on what app is active, to convert the upper mouse button events 
into actual actions.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman