GNU bug report logs - #7631
24.0.50; inconsistency in event-convert-list and event-basic-type

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7631 in the body.
You can then email your comments to 7631 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Don March <don <at> ohspite.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; inconsistency in event-convert-list and event-basic-type
Date: Mon, 13 Dec 2010 01:22:32 -0500

The definition for `event-convert-list' in keyboard.c has the
following code, which causes symbols consisting of a single character
to be interpreted as the character itself:

  /* Let the symbol A refer to the character A.  */
  if (SYMBOLP (base) && SCHARS (SYMBOL_NAME (base)) == 1)
    XSETINT (base, SREF (SYMBOL_NAME (base), 0));

I see how this is well-intentioned but I don't think that it's useful,
particularly because of the case where the symbol is `t'.

(event-convert-list '(t)) ; => 116

There's good reason to want this to eval to t (i.e. the symbol, not
the char).  For example, I found this interesting behavior when using
`map-keymap' to automate remapping commands from C- with M-.  It also
seems to produce inconsistent results:

(event-convert-list '(nil)) ; => nil
(event-convert-list '(t)) ; => 116
(event-convert-list '(tt)) ; => tt
(event-convert-list '(control t)) ; => 20
(event-convert-list '(control tt)) ; => C-tt

If, however, this the Right Thing for some reason I don't see, the
documentation for `event-convert-list' needs to be changed:

"The return value is an event type (a character or symbol) ***which
has the same base event type*** and all the specified modifiers"
(emphasis added).

(event-convert-list '(t)) ; => 116
(event-basic-type t) ; => t

In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.22.0)
 of 2010-12-12 on lappy
Windowing system distributor `The X.Org Foundation', version 11.0.10900000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Message #8 received at 7631 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Don March <don <at> ohspite.net>
Cc: 7631 <at> debbugs.gnu.org
Subject: Re: bug#7631: 24.0.50;
	inconsistency in event-convert-list and event-basic-type
Date: Mon, 13 Dec 2010 13:01:14 -0500

> (event-convert-list '(t)) ; => 116

> There's good reason to want this to eval to t (i.e. the symbol, not
> the char).

Could you explain what is this good reason?
In Emacs, events corresponding to keys that are associated with
a characters are represented by an Elisp char, whereas other events are
represented by symbols.

AFAIK event-convert-list is mostly used to convert XEmacs style

  (define-key map [(control x)] 'foo)
to
  (define-key map ?\C-x 'foo)

so this single-char symbol conversion to a character is useful.
Maybe you can explain to us the problem it causes you.


        Stefan

Message #11 received at 7631 <at> debbugs.gnu.org (full text, mbox):

From: Don March <don <at> ohspite.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7631 <at> debbugs.gnu.org
Subject: Re: bug#7631: 24.0.50;
	inconsistency in event-convert-list and event-basic-type
Date: Mon, 13 Dec 2010 22:36:20 -0500

On Mon, Dec 13, 2010 at 1:01 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> (event-convert-list '(t)) ; => 116
>
>> There's good reason to want this to eval to t (i.e. the symbol, not
>> the char).
>
> Could you explain what is this good reason?

I guess it boils down to the expected result of:

(setq event t)

(event-convert-list
 (append (event-modifiers event)
        (list (event-basic-type event)))) ; => 116, not t

In my mind, this should be an identity function (in the mathematical
sense) for events; if you take the event-modifiers and the
event-basic-type and then splice them together, the result should be
the original event.

A simplified version of what I was doing when I found this (which may
or may not be important) was something along the lines of:

(defun swap-C-and-M (event)
 (event-convert-list
  (append
   (mapcar (lambda (x) (case x
                         ('control 'meta)
                         ('meta    'control)
                         ('click   nil)
                         (t x)))
           (event-modifiers event))
   (list (event-basic-type event)))))

(setq new-keymap (make-sparse-keymap))

(map-keymap (lambda (key def)
             (define-key new-keymap
               (vector (swap-C-and-M key))
               def))
           isearch-mode-map)

(swap-C-and-M ?\M-x) ; => 24
(swap-C-and-M 'foo)  ; => foo
(swap-C-and-M t)     ; => 116

(lookup-key new-keymap [?t]) ; => isearch-other-control-char
(lookup-key new-keymap [t])  ; => nil

Message #14 received at 7631 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Don March <don <at> ohspite.net>
Cc: 7631 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#7631: 24.0.50; inconsistency in event-convert-list and
 event-basic-type
Date: Sun, 18 Jul 2021 14:20:30 +0200

Don March <don <at> ohspite.net> writes:

>>> (event-convert-list '(t)) ; => 116
>>
>>> There's good reason to want this to eval to t (i.e. the symbol, not
>>> the char).
>>
>> Could you explain what is this good reason?
>
> I guess it boils down to the expected result of:
>
> (setq event t)
>
> (event-convert-list
>  (append (event-modifiers event)
>         (list (event-basic-type event)))) ; => 116, not t

Or simpler:

(event-convert-list (list nil 's))
=> 115

(115 is the same as the character ?s.)

The doc string says:

---
EVENT-DESC should contain one base event type (a character or symbol)
and zero or more modifier names (control, meta, hyper, super, shift, alt,
drag, down, double or triple).  The base must be last.
The return value is an event type (a character or symbol) which
has the same base event type and all the specified modifiers.
---

(event-basic-type 's)
=> s

So if this isn't a bug (and I think it would be problematic to change
the return value at this point), the doc string is at least slightly
misleading here, and shouldn't claim that it returns exactly the same
base event type.

Any opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #19 received at 7631 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7631 <at> debbugs.gnu.org, Don March <don <at> ohspite.net>
Subject: Re: bug#7631: 24.0.50; inconsistency in event-convert-list and
 event-basic-type
Date: Sun, 18 Jul 2021 18:18:23 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> So if this isn't a bug (and I think it would be problematic to change
>> the return value at this point), the doc string is at least slightly
>> misleading here, and shouldn't claim that it returns exactly the same
>> base event type.
>
> Fair enough,

OK; done in Emacs 28, and I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #24 received at 7631 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Don March <don <at> ohspite.net>
Cc: 7631 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#7631: 24.0.50; inconsistency in event-convert-list and
 event-basic-type
Date: Sun, 18 Jul 2021 12:09:43 -0400

Don March wrote:
> (event-convert-list
>  (append (event-modifiers event)
>         (list (event-basic-type event)))) ; => 116, not t
>
> In my mind, this should be an identity function (in the mathematical
> sense) for events;

In general, it literally can't be: there are several "equivalent"
representations of a given event and `event-convert-list` should return
a "canonical" version.  E.g. it should return `C-M-return` when `event`
is `M-C-return`.

There is no "canonical event" `t`, instead Emacs uses `?t` as the
canonical event for hitting the key `t`.

Lars wrote:
> So if this isn't a bug (and I think it would be problematic to change
> the return value at this point), the doc string is at least slightly
> misleading here, and shouldn't claim that it returns exactly the same
> base event type.

Fair enough,


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.