* bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type
@ 2010-12-13 6:22 Don March
2010-12-13 18:01 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Don March @ 2010-12-13 6:22 UTC (permalink / raw)
To: 7631
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type
2010-12-13 6:22 bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type Don March
@ 2010-12-13 18:01 ` Stefan Monnier
2010-12-14 3:36 ` Don March
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2010-12-13 18:01 UTC (permalink / raw)
To: Don March; +Cc: 7631
> (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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type
2010-12-13 18:01 ` Stefan Monnier
@ 2010-12-14 3:36 ` Don March
2021-07-18 12:20 ` Lars Ingebrigtsen
2021-07-18 16:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 6+ messages in thread
From: Don March @ 2010-12-14 3:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7631
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type
2010-12-14 3:36 ` Don March
@ 2021-07-18 12:20 ` Lars Ingebrigtsen
2021-07-18 16:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-18 12:20 UTC (permalink / raw)
To: Don March; +Cc: 7631, Stefan Monnier
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type
2010-12-14 3:36 ` Don March
2021-07-18 12:20 ` Lars Ingebrigtsen
@ 2021-07-18 16:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-18 16:18 ` Lars Ingebrigtsen
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-07-18 16:09 UTC (permalink / raw)
To: Don March; +Cc: 7631, Lars Ingebrigtsen
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-07-18 16:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-13 6:22 bug#7631: 24.0.50; inconsistency in event-convert-list and event-basic-type Don March
2010-12-13 18:01 ` Stefan Monnier
2010-12-14 3:36 ` Don March
2021-07-18 12:20 ` Lars Ingebrigtsen
2021-07-18 16:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-18 16:18 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.