Re: address@hidden: Re: x-backspace-delete-keys-p]

[Jan D.]

>     The code could be modified to check for different keysyms for 
> delete and
>     backspace, but I'm not sure what problem it is trying to solve.  
> Doesn't
>     the current code work?
>
> He had a case where it did not work.
> Here is the report.


Note that the XKeysymToKeycode function does not take any modifiers 
(Shift, Control, Mode Switch etc) in to account, so if I have XK_Delete 
mapped to Shift-Control-Mod1-d, XKeysymToKeycode will return the key 
for d.  So the question is rather what
x-backspace-delete-keys-p is supposed to test.  Here is the doc:

 doc: /* Check if both Backspace and Delete keys are on the keyboard of 
FRAME.
FRAME nil means use the selected frame.
Value is t if we know that both keys are present, and are mapped to the
usual X keysyms.  */

Currently it checks if the keyboard physically has a backspace and 
delete key and that they generate backspace and delete respectively.
The patch suggested would instead check that both backspace and delete 
can be generated by any key combination.  This is not what the doc: 
says today.

I have no objection to such a change, it would probably not make any 
difference in the majority of cases.

        Jan D.


> I have a funky keyboard layout (mimicking a lisp machine keyboard) 
> where
> backspace is mapped onto the caps lock key and nothing is on the 
> backspace
> key. With this layout the x-backspace-delete-keys-p function (in 
> xfns.c)
> returns false which causes normal-erase-is-backspace-mode not to be 
> turned
> on by default.
>
> Looking at the code, it seems that x-backspace-delete-keys-p checks 
> whether
> the keyboard has a delete and backspace key and XK_Delete/XK_Backspace 
> is
> mapped onto them. I don't know much about other keyboards but checking 
> only
> whether XK_Delete/XK_Backspace is mapped to a keycode that belongs to 
> _any_
> key in the current keyboard sounds enough. In other words, checking for
> DELE/BKSP keys is unnecessary.