bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type

bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type

[Don March]

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

bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type

[Stefan Monnier]

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

bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type

[Don March]

On Mon, Dec 13, 2010 at 1:01 PM, Stefan Monnier
<monnier@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

bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type

[Lars Ingebrigtsen]

Don March <don@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

bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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