Re: misc/59051: edt-1.9's "keypad_configure" function performs global configuration of remote X session

["RVP via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR misc/59051; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: misc/59051: edt-1.9's "keypad_configure" function performs global
 configuration of remote X session
Date: Tue, 11 Feb 2025 07:48:35 +0000 (UTC)

 On Fri, 7 Feb 2025, jon.brase%gmail.com@localhost wrote:
 
 > However, even if the process is aborted before edt saves the resulting configuration to disk, the phase that opens the X11 window appears to actually somehow affect global configuration on the X Server, and to do so over forwarded X sessions! (But I suppose the last bit is the price you pay for network transparency...).
 >
 > Specifically, after running keypad_configure on a remote instance of edt, Num Lock no longer responds on my local machine, and numpad keys now generate responses for local X11 clients that are not consistent with their normal num-lock-on or num-lock-off functions.
 >
 
 This version of EDT uses xmodmap to remap keys, and running xmodmap _will_
 change the way keys are interpreted on the X server (whether local or remote).
 
 >From a quick scan of the source (I know nothing about EDT), it looks like
 there is a `rk' command which can be used to "restore" the num keypad to its
 orig. state...but, this doesn't work because:
 
 1. There's a bug in the source (patch for this below) for the command.
 
 2. Even if this bug was fixed, the `rk' command would only work _after_ this
     config was saved--ie. after you get an .xml file which can be passed via
     `EDT_KEYPAD_SETUP=...'. The first time through, you get a messed up keyboard
     state as you found out.
 
 3. and even if you did manage all that (by saving and restoring the keyboard
     config.), the `rk' command would still not restore the old keys correctly
     because it only restores the 1st set of keysyms (corresponding to the
     normal keys). Since this is the num keypad we're dealing with, one has to
     save and put back the keysyms for the other modifier keys too:
 
  	$ xmodmap -pke | fgrep KP_Home
  	keycode  79 = KP_Home KP_7 KP_Home KP_7
  	$
 
     This, EDT doesn't do, so the num keypad is still wonky after a manual `rk'
     before exiting.
 
 So, this isn't a NetBSD bug at all, and edt-1.9 will have to be fixed. Until
 then you could save and restore the keymaps explicitly:
 
 ```
 #!/bin/sh
 #
 # https://www.gnu.org/software/emacs/manual/html_mono/edt.html
 
 KEYMAP=/tmp/xmodmap.$$
 
 # Save current keymap.
 #
 xmodmap -pke > $KEYMAP
 
 # Restore orig. keymap on exit.
 #
 trap 'test -s $KEYMAP && xmodmap $KEYMAP; rm -f $KEYMAP' 0 1 2 3 15
 
 if [ -f /PATH/TO/edt_keypad.xml ]
 then	export EDT_KEYPAD_SETUP=/PATH/TO/edt_keypad.xml
 fi
 
 /PATH/TO/edt "$@"
 ```
 
 Or, try out a different version of EDT:
 
 http://www.o3one.org/edt.html
 
 This one only needed 2 minor changes for NetBSD:
 
 - adding `#include <sys/ioctl.h>' to os.c, and,
 - changing `-lreadline' to `-ledit' to make it use NetBSD's editline(3) library
    instead of readline(3).
 
 HTH,
 
 -RVP
 
 ```
 diff -urN edt_1.9.orig/edt_1.9.c edt_1.9/edt_1.9.c
 --- edt_1.9.orig/edt_1.9.c	2012-01-01 12:24:03.000000000 +0000
 +++ edt_1.9/edt_1.9.c	2025-02-08 08:24:05.561453444 +0000
 @@ -828,7 +828,7 @@
             xml_grab_attrib( tag, name, mapto, MAXSTR );
   	  if (strcmp(name,"mapto") != 0)
   	   printf("Error: Reading keypad setup, expected 'mapto' in key_set tag, but found '%s',\n",name);
 -	  sprintf(cmd,"xmodmap xmodmap -e \"keycode %d = %s\"", keyval, mapto );
 +	  sprintf(cmd,"xmodmap -e \"keycode %d = %s\"", keyval, mapto );
   	  system( cmd );
   	  setnum++;
           } /*key_set*/
 ```