GNU bug report logs - #10190
eventp can give incorrect results (subr.el), Emacs 23 and 24

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 10190 in the body.
You can then email your comments to 10190 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: Christopher Genovese <genovese.cr <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: eventp can give incorrect results (subr.el), Emacs 23 and 24
Date: Fri, 2 Dec 2011 00:55:11 -0500

[Message part 1 (text/plain, inline)]

This is not a major problem, but it did come up for me in a real program.
In Emacs 23 and 24, the function eventp in subr.el can give incorrect
results
for symbolic events, depending on the timing of the call.  This seems to
occurs because event symbol elements (mask, modifiers, basic type) are
stored in a plist
associated with symbolic events, but the list is set in the function
internal-event-symbol-parse-modifiers, which is only called in the function
event-modifiers not in the inline function eventp.  Hence, code that tests
for
an event before checking the modifiers can give the wrong results, e.g.,

           (cond  ((integerp c) ...)
                       ....
                      ((eventp )  (do-something-with (event-modfiers c)))
                      (t
                          (not-what-we-want-with c)))

will fail when c is a symbolic event that has not been parsed before.

Consider the following sequence, which illustrates the error in a new Emacs
24
session with -Q (on Mac OS X 10.5.8). Although the event M-S-f5 is a rather
obscure one, it is the event used to illustrate the event- fucntions in the
Elisp Info documentation.

;; #1
(eventp 'M-S-f5)
> nil
(symbol-plist 'M-S-f5)
> nil

;; #2
(event-modifiers 'M-S-f5)
> (meta shift)

;; #3
(eventp 'M-S-f5)
> (f5 meta shift)
(symbol-plist 'M-S-f5)
> (event-symbol-element-mask (f5 167772160) event-symbol-elements (f5 meta
shift))

A similar example occurs with, say, M-s-z, even if M-s-z has been defined
in the global map.

This problem holds with event-basic-type too because it also just checks
the symbol plist.
In #1, for instance, (event-basic-type 'M-S-f5) would be nil, but not in
#3.
Another side of the problem(?) is that in #1  calling (event-modifier
'foobar) would make
subsequent (eventp 'foobar) calls true.

Neither of these seems like desirable behaviors.

Not a really big deal, but I thought I'd pass it along.

Thanks,

   Chris

P.S. I haven't had a chance to look over the C code on this too closely,
but the function
parse_modifiers, which is doing the work in
internal-event-symbol-parse-modifiers,
is called at some points when reading key sequences. Caching the events when
they are read would seem to be a good idea, although it is not happening in
the
M-s-z example.

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Christopher Genovese <genovese.cr <at> gmail.com>
Cc: 10190 <at> debbugs.gnu.org
Subject: Re: bug#10190: eventp can give incorrect results (subr.el),
	Emacs 23 and 24
Date: Fri, 02 Dec 2011 09:31:35 -0500

> This is not a major problem, but it did come up for me in a real program.
> In Emacs 23 and 24, the function eventp in subr.el can give incorrect
> results for symbolic events, depending on the timing of the call.

I think the assumption of the current code is that eventp is allowed to
return nil if that event has not yet occurred in the current session.
I'm not sure why it's done that way.

> This seems to occurs because event symbol elements (mask, modifiers,
> basic type) are stored in a plist associated with symbolic events, but
> the list is set in the function internal-event-symbol-parse-modifiers,
> which is only called in the function event-modifiers not in the inline
> function eventp.  Hence, code that tests for an event before checking
> the modifiers can give the wrong results, e.g.,

Note that (progn (event-modifiers X) (eventp X)) will return non-nil for
*any* symbol (i.e. any symbol can potentially be an event name).

> Neither of these seems like desirable behaviors.

I tend to agree.  But I'm also curious in which circumstance did you
bump into this problem.

My own impression is that the patch below would be an improvement, but
I'd rather keep it for after 24.1.


        Stefan


=== modified file 'lisp/subr.el'
--- lisp/subr.el	2011-11-23 07:03:56 +0000
+++ lisp/subr.el	2011-12-02 14:30:16 +0000
@@ -870,16 +870,10 @@
 
 (defsubst eventp (obj)
   "True if the argument is an event object."
-  (or (and (integerp obj)
-	   ;; Filter out integers too large to be events.
-	   ;; M is the biggest modifier.
-	   (zerop (logand obj (lognot (1- (lsh ?\M-\^@ 1)))))
-	   (characterp (event-basic-type obj)))
-      (and (symbolp obj)
-	   (get obj 'event-symbol-elements))
+  (or (integerp obj)
+      (symbolp obj)
       (and (consp obj)
-	   (symbolp (car obj))
-	   (get (car obj) 'event-symbol-elements))))
+	   (symbolp (car obj)))))
 
 (defun event-modifiers (event)
   "Return a list of symbols representing the modifier keys in event EVENT.

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

From: Christopher Genovese <genovese.cr <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10190 <at> debbugs.gnu.org
Subject: Re: bug#10190: eventp can give incorrect results (subr.el), Emacs 23
	and 24
Date: Fri, 2 Dec 2011 10:17:37 -0500

[Message part 1 (text/plain, inline)]

>
> > Neither of these seems like desirable behaviors.
>
> I tend to agree.  But I'm also curious in which circumstance did you
> bump into this problem.
>

I'm finishing up a package to give easy and flexible management of imports
during initialization, and in using the package, I had a function that made
some settings
based on a user-specified help character or event.  Failures showed up in
the test cases that used more obscure events like M-S-f5,
and the nil eventp caused unexpected behavior. (I've since changed
my approach.)


> My own impression is that the patch below would be an improvement, but
> I'd rather keep it for after 24.1.
>

That sounds reasonable to me.  It's not a critical issue.

Thanks for your help.

  -- Chris

[Message part 2 (text/html, inline)]

Message #16 received at 10190-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Christopher Genovese <genovese.cr <at> gmail.com>
Cc: 10190-done <at> debbugs.gnu.org
Subject: Re: bug#10190: eventp can give incorrect results (subr.el),
	Emacs 23 and 24
Date: Thu, 19 Jul 2012 02:25:19 -0400

> My own impression is that the patch below would be an improvement, but
> I'd rather keep it for after 24.1.

Installed (in a slightly different form).


        Stefan

Previous Next

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