unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [mega@hotpop.com: Re: x-backspace-delete-keys-p]
@ 2005-02-03 19:14 Richard Stallman
  2005-02-03 20:28 ` Jan D.
  0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2005-02-03 19:14 UTC (permalink / raw)


Could people please study this, and try it, and see if it causes
any problems?

------- Start of forwarded message -------
From: Gabor Melis <mega@hotpop.com>
To: rms@gnu.org
Subject: Re: x-backspace-delete-keys-p
Date: Wed, 2 Feb 2005 11:25:06 +0100
In-Reply-To: <E1CwEwe-0004Qs-QS@fencepost.gnu.org>
X-Spam-Status: No, hits=-2.5 required=5.0
	tests=EMAIL_ATTRIBUTION,IN_REP_TO,PATCH_UNIFIED_DIFF,
	      QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_KMAIL
	version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)

- --Boundary-00=_CqKACLDpv2J5AY6
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wednesday 02 February 2005 08:29, Richard Stallman wrote:
>     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.
>
> Maybe you are right, but I don't know how to do this, or if there
> is a way to do this.  Do you want to find out?

This patch (against 21.3) does what I described. It could probably be improved 
by checking for the the geometry in case the keycode belongs to a key, but 
that key is not present on the physical keyboard. I tested it with my lisp 
machine, us and us-without-a-backspace-key layouts and it seems to work 
returning t, t an nil respectively.

- --Boundary-00=_CqKACLDpv2J5AY6
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="x-backspace-delete-keys-p.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="x-backspace-delete-keys-p.patch"

- --- xfns.c.orig	2005-02-02 11:15:23.000000000 +0100
+++ xfns.c	2005-02-02 11:07:46.000000000 +0100
@@ -11350,6 +11350,16 @@
 #include <X11/keysym.h>
 #endif
 
+#ifdef HAVE_XKBGETKEYBOARD
+static int
+is_keycode_mapped (XkbDescPtr kb, int keycode)
+{
+  /* We could also check if the key is physically present in the
+     geometry component, but that is more trouble than it is worth. */
+  return (kb->min_key_code <= keycode) && (keycode <= kb->max_key_code);
+}
+#endif
+
 DEFUN ("x-backspace-delete-keys-p", Fx_backspace_delete_keys_p,
        Sx_backspace_delete_keys_p, 0, 1, 0,
   "Check if both Backspace and Delete keys are on the keyboard of FRAME.\n\
@@ -11390,34 +11400,19 @@
   kb = XkbGetMap (dpy, XkbAllMapComponentsMask, XkbUseCoreKbd);
   if (kb)
     {
- -      int delete_keycode = 0, backspace_keycode = 0, i;
+      int delete_keycode = XKeysymToKeycode (dpy, XK_Delete);
+      int backspace_keycode = XKeysymToKeycode (dpy, XK_BackSpace);
 
       if (XkbGetNames (dpy, XkbAllNamesMask, kb) == Success)
 	{
- -	  for (i = kb->min_key_code;
- -	       (i < kb->max_key_code
- -		&& (delete_keycode == 0 || backspace_keycode == 0));
- -	       ++i)
- -	    {
- -	      /* The XKB symbolic key names can be seen most easily in
- -		 the PS file generated by `xkbprint -label name
- -		 $DISPLAY'.  */
- -	      if (bcmp ("DELE", kb->names->keys[i].name, 4) == 0)
- -		delete_keycode = i;
- -	      else if (bcmp ("BKSP", kb->names->keys[i].name, 4) == 0)
- -		backspace_keycode = i;
- -	    }
+          if (is_keycode_mapped (kb, delete_keycode) &&
+              is_keycode_mapped (kb, backspace_keycode))
+            have_keys = Qt;
 
 	  XkbFreeNames (kb, 0, True);
 	}
 
       XkbFreeClientMap (kb, 0, True);
- -
- -      if (delete_keycode
- -	  && backspace_keycode
- -	  && XKeysymToKeycode (dpy, XK_Delete) == delete_keycode
- -	  && XKeysymToKeycode (dpy, XK_BackSpace) == backspace_keycode)
- -	have_keys = Qt;
     }
   UNBLOCK_INPUT;
   return have_keys;

- --Boundary-00=_CqKACLDpv2J5AY6--
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-03 19:14 [mega@hotpop.com: Re: x-backspace-delete-keys-p] Richard Stallman
@ 2005-02-03 20:28 ` Jan D.
  2005-02-03 20:35   ` Jan D.
  2005-02-05 17:38   ` Richard Stallman
  0 siblings, 2 replies; 9+ messages in thread
From: Jan D. @ 2005-02-03 20:28 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman wrote:

>Could people please study this, and try it, and see if it causes
>any problems?
>  
>

If you have (like I usually have) Backspace and Delete on the same key 
(Shift-Backspace generates a Delete) and no other delete key, 
XKeysymToKeycode will return the same key for XK_Backspace and 
XK_Delete.  The code suggested will then incorrectly assume there are 
two keys.

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?

    Jan D.

>------- Start of forwarded message -------
>From: Gabor Melis <mega@hotpop.com>
>To: rms@gnu.org
>Subject: Re: x-backspace-delete-keys-p
>Date: Wed, 2 Feb 2005 11:25:06 +0100
>In-Reply-To: <E1CwEwe-0004Qs-QS@fencepost.gnu.org>
>X-Spam-Status: No, hits=-2.5 required=5.0
>	tests=EMAIL_ATTRIBUTION,IN_REP_TO,PATCH_UNIFIED_DIFF,
>	      QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES,
>	      REPLY_WITH_QUOTES,USER_AGENT_KMAIL
>	version=2.55
>X-Spam-Level: 
>X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
>
>- --Boundary-00=_CqKACLDpv2J5AY6
>Content-Type: text/plain;
>  charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>On Wednesday 02 February 2005 08:29, Richard Stallman wrote:
>  
>
>>    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.
>>
>>Maybe you are right, but I don't know how to do this, or if there
>>is a way to do this.  Do you want to find out?
>>    
>>
>
>This patch (against 21.3) does what I described. It could probably be improved 
>by checking for the the geometry in case the keycode belongs to a key, but 
>that key is not present on the physical keyboard. I tested it with my lisp 
>machine, us and us-without-a-backspace-key layouts and it seems to work 
>returning t, t an nil respectively.
>
>- --Boundary-00=_CqKACLDpv2J5AY6
>Content-Type: text/x-diff;
>  charset="iso-8859-1";
>  name="x-backspace-delete-keys-p.patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
>	filename="x-backspace-delete-keys-p.patch"
>
>- --- xfns.c.orig	2005-02-02 11:15:23.000000000 +0100
>+++ xfns.c	2005-02-02 11:07:46.000000000 +0100
>@@ -11350,6 +11350,16 @@
> #include <X11/keysym.h>
> #endif
> 
>+#ifdef HAVE_XKBGETKEYBOARD
>+static int
>+is_keycode_mapped (XkbDescPtr kb, int keycode)
>+{
>+  /* We could also check if the key is physically present in the
>+     geometry component, but that is more trouble than it is worth. */
>+  return (kb->min_key_code <= keycode) && (keycode <= kb->max_key_code);
>+}
>+#endif
>+
> DEFUN ("x-backspace-delete-keys-p", Fx_backspace_delete_keys_p,
>        Sx_backspace_delete_keys_p, 0, 1, 0,
>   "Check if both Backspace and Delete keys are on the keyboard of FRAME.\n\
>@@ -11390,34 +11400,19 @@
>   kb = XkbGetMap (dpy, XkbAllMapComponentsMask, XkbUseCoreKbd);
>   if (kb)
>     {
>- -      int delete_keycode = 0, backspace_keycode = 0, i;
>+      int delete_keycode = XKeysymToKeycode (dpy, XK_Delete);
>+      int backspace_keycode = XKeysymToKeycode (dpy, XK_BackSpace);
> 
>       if (XkbGetNames (dpy, XkbAllNamesMask, kb) == Success)
> 	{
>- -	  for (i = kb->min_key_code;
>- -	       (i < kb->max_key_code
>- -		&& (delete_keycode == 0 || backspace_keycode == 0));
>- -	       ++i)
>- -	    {
>- -	      /* The XKB symbolic key names can be seen most easily in
>- -		 the PS file generated by `xkbprint -label name
>- -		 $DISPLAY'.  */
>- -	      if (bcmp ("DELE", kb->names->keys[i].name, 4) == 0)
>- -		delete_keycode = i;
>- -	      else if (bcmp ("BKSP", kb->names->keys[i].name, 4) == 0)
>- -		backspace_keycode = i;
>- -	    }
>+          if (is_keycode_mapped (kb, delete_keycode) &&
>+              is_keycode_mapped (kb, backspace_keycode))
>+            have_keys = Qt;
> 
> 	  XkbFreeNames (kb, 0, True);
> 	}
> 
>       XkbFreeClientMap (kb, 0, True);
>- -
>- -      if (delete_keycode
>- -	  && backspace_keycode
>- -	  && XKeysymToKeycode (dpy, XK_Delete) == delete_keycode
>- -	  && XKeysymToKeycode (dpy, XK_BackSpace) == backspace_keycode)
>- -	have_keys = Qt;
>     }
>   UNBLOCK_INPUT;
>   return have_keys;
>
>- --Boundary-00=_CqKACLDpv2J5AY6--
>------- End of forwarded message -------
>
>
>_______________________________________________
>Emacs-devel mailing list
>Emacs-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/emacs-devel
>  
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-03 20:28 ` Jan D.
@ 2005-02-03 20:35   ` Jan D.
  2005-02-05 17:38   ` Richard Stallman
  1 sibling, 0 replies; 9+ messages in thread
From: Jan D. @ 2005-02-03 20:35 UTC (permalink / raw)
  Cc: rms, emacs-devel

Jan D. wrote:

> If you have (like I usually have) Backspace and Delete on the same key 
> (Shift-Backspace generates a Delete) and no other delete key, 
> XKeysymToKeycode will return the same key for XK_Backspace and 
> XK_Delete.  The code suggested will then incorrectly assume there are 
> two keys.
>
> 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?


That should be "different keycodes" of course.

    Jan D.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-03 20:28 ` Jan D.
  2005-02-03 20:35   ` Jan D.
@ 2005-02-05 17:38   ` Richard Stallman
  2005-02-05 18:08     ` Jan D.
  1 sibling, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2005-02-05 17:38 UTC (permalink / raw)
  Cc: emacs-devel

    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.


From: Gabor Melis <mega@hotpop.com>
To: bug-gnu-emacs@gnu.org
Date: Tue, 1 Feb 2005 11:43:43 +0100
User-Agent: KMail/1.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <05Feb1.114656cet.336082@fwall.essnet.se>
Subject: x-backspace-delete-keys-p
X-BeenThere: bug-gnu-emacs@gnu.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Bug reports for GNU Emacs,
	the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org
Errors-To: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org
X-Spam-Status: No, hits=0.5 required=5.0
	tests=RCVD_IN_ORBS,USER_AGENT_KMAIL
	version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)

I have a funky keyboard layout (mimicking a lisp machine keyboard) where=20
backspace is mapped onto the caps lock key and nothing is on the backspace=
=20
key. With this layout the x-backspace-delete-keys-p function (in xfns.c)=20
returns false which causes normal-erase-is-backspace-mode not to be turned =
on=20
by default.

Looking at the code, it seems that x-backspace-delete-keys-p checks whether=
=20
the keyboard has a delete and backspace key and XK_Delete/XK_Backspace is=20
mapped onto them. I don't know much about other keyboards but checking only=
=20
whether XK_Delete/XK_Backspace is mapped to a keycode that belongs to _any_=
=20
key in the current keyboard sounds enough. In other words, checking for=20
DELE/BKSP keys is unnecessary.

Cheers, G=E1bor Melis

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-05 17:38   ` Richard Stallman
@ 2005-02-05 18:08     ` Jan D.
  2005-02-06 12:42       ` Richard Stallman
  0 siblings, 1 reply; 9+ messages in thread
From: Jan D. @ 2005-02-05 18:08 UTC (permalink / raw)
  Cc: emacs-devel

>     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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-05 18:08     ` Jan D.
@ 2005-02-06 12:42       ` Richard Stallman
  2005-02-06 14:27         ` Jan D.
  0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2005-02-06 12:42 UTC (permalink / raw)
  Cc: emacs-devel

    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.

Would Emacs be more correct if this change is made?  (Or some other
related change?)

I don't think his peculiar case is very important, and I would not
want to make a lot of effort just to cater to it.  However, if there
is a good argument that the current code is not really correct, and we
can replace it with something that is entirely correct, that is more
of a reason to make the change.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-06 12:42       ` Richard Stallman
@ 2005-02-06 14:27         ` Jan D.
  2005-02-07  9:18           ` Richard Stallman
  0 siblings, 1 reply; 9+ messages in thread
From: Jan D. @ 2005-02-06 14:27 UTC (permalink / raw)
  Cc: emacs-devel

>     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.
>
> Would Emacs be more correct if this change is made?  (Or some other
> related change?)
>
> I don't think his peculiar case is very important, and I would not
> want to make a lot of effort just to cater to it.  However, if there
> is a good argument that the current code is not really correct, and we
> can replace it with something that is entirely correct, that is more
> of a reason to make the change.

I'm not sure I know what "correct" is.  It is a small difference 
between "the keyboard has a Backspace and a Delete key" and "the user 
can generate both a Backspace and a Delete".  As far as I know, 
x-backspace-delete-keys-p is only used to turn on 
normal-erase-is-backspace in startup.el.

For a non-expert user I think the current code is more correct.  If you 
have both keys and one doesn't do what you expect, you probably will 
try the other.  But if Backspace or Delete is mapped to a non-obvious 
key combination that you don't know about, the best thing is to not 
turn on normal-erase-is-backspace.

If you know about the non-obvious key combination, you probably know 
how to turn on normal-erase-is-backspace manually.  The code for 
turning it on in startup.el is not correct for all cases anyway (it 
assumes both keys for w32, but this may not be true).

	Jan D.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-06 14:27         ` Jan D.
@ 2005-02-07  9:18           ` Richard Stallman
  2005-02-07 12:50             ` Jan D.
  0 siblings, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2005-02-07  9:18 UTC (permalink / raw)
  Cc: emacs-devel

    For a non-expert user I think the current code is more correct.  If you 
    have both keys and one doesn't do what you expect, you probably will 
    try the other.  But if Backspace or Delete is mapped to a non-obvious 
    key combination that you don't know about, the best thing is to not 
    turn on normal-erase-is-backspace.

Ok.  Could you add a comment to that place in the code
explaining this reasoning for deciding not to change it?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [mega@hotpop.com: Re: x-backspace-delete-keys-p]
  2005-02-07  9:18           ` Richard Stallman
@ 2005-02-07 12:50             ` Jan D.
  0 siblings, 0 replies; 9+ messages in thread
From: Jan D. @ 2005-02-07 12:50 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman wrote:

>    For a non-expert user I think the current code is more correct.  If you 
>    have both keys and one doesn't do what you expect, you probably will 
>    try the other.  But if Backspace or Delete is mapped to a non-obvious 
>    key combination that you don't know about, the best thing is to not 
>    turn on normal-erase-is-backspace.
>
>Ok.  Could you add a comment to that place in the code
>explaining this reasoning for deciding not to change it?
>

Done.

    Jan D.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2005-02-07 12:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-03 19:14 [mega@hotpop.com: Re: x-backspace-delete-keys-p] Richard Stallman
2005-02-03 20:28 ` Jan D.
2005-02-03 20:35   ` Jan D.
2005-02-05 17:38   ` Richard Stallman
2005-02-05 18:08     ` Jan D.
2005-02-06 12:42       ` Richard Stallman
2005-02-06 14:27         ` Jan D.
2005-02-07  9:18           ` Richard Stallman
2005-02-07 12:50             ` Jan D.

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).