From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christopher Genovese Newsgroups: gmane.emacs.bugs Subject: bug#10190: eventp can give incorrect results (subr.el), Emacs 23 and 24 Date: Fri, 2 Dec 2011 00:55:11 -0500 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf300fa9ebf6f12f04b3159da8 X-Trace: dough.gmane.org 1322805364 25271 80.91.229.12 (2 Dec 2011 05:56:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2011 05:56:04 +0000 (UTC) To: 10190@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 02 06:55:57 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RWM6H-0005Jl-9T for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Dec 2011 06:55:57 +0100 Original-Received: from localhost ([::1]:53484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWM6G-0000AE-2E for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Dec 2011 00:55:56 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWM6A-0000A3-Cf for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2011 00:55:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWM69-0002WG-Bq for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2011 00:55:50 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWM69-0002WA-8y for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2011 00:55:49 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RWM6L-00089o-Mv for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2011 00:56:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Christopher Genovese Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Dec 2011 05:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 10190 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.132280535231336 (code B ref -1); Fri, 02 Dec 2011 05:56:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 2 Dec 2011 05:55:52 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RWM6B-00089N-Oc for submit@debbugs.gnu.org; Fri, 02 Dec 2011 00:55:51 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RWM6A-00089H-G2 for submit@debbugs.gnu.org; Fri, 02 Dec 2011 00:55:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWM5w-0002Vg-F8 for submit@debbugs.gnu.org; Fri, 02 Dec 2011 00:55:37 -0500 Original-Received: from lists.gnu.org ([140.186.70.17]:59664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWM5w-0002Vc-CZ for submit@debbugs.gnu.org; Fri, 02 Dec 2011 00:55:36 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWM5v-00009w-6Q for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2011 00:55:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWM5t-0002VO-To for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2011 00:55:35 -0500 Original-Received: from mail-qw0-f48.google.com ([209.85.216.48]:40206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWM5t-0002VJ-PI for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2011 00:55:33 -0500 Original-Received: by qao25 with SMTP id 25so663085qao.0 for ; Thu, 01 Dec 2011 21:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=nrIT0PUywIxZQK3RP9FcnJvc/UFEtApJWd/yOB/8A6I=; b=ME19JTxj97AFK39m008qO2aS3nF2CrKXmTMRsWzPIAQn9Kt+WpjjBOe/agbTspFLKi PY8UE2vJ/GnBvnWgFNkVvWmGXLUprIjVLAdop1USqefl14FQjHWZNrcTc6xrXblXy7aY KFkSNcEW3AaRyFDXVZeHiCUJMJiuvkBV3ogwg= Original-Received: by 10.224.208.134 with SMTP id gc6mr1759249qab.64.1322805332734; Thu, 01 Dec 2011 21:55:32 -0800 (PST) Original-Received: by 10.229.242.73 with HTTP; Thu, 1 Dec 2011 21:55:11 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 02 Dec 2011 00:56:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:54585 Archived-At: --20cf300fa9ebf6f12f04b3159da8 Content-Type: text/plain; charset=ISO-8859-1 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. --20cf300fa9ebf6f12f04b3159da8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 res= ults
for symbolic events, depending on the timing of the call.=A0 This s= eems to
occurs because event symbol elements (mask, modifiers, basic type) are stor= ed in a plist
associated with symbolic events, but the list is set in th= e function
internal-event-symbol-parse-modifiers, which is only called i= n the function
event-modifiers not in the inline function eventp.=A0 Hence, code that test= s for
an event before checking the modifiers can give the wrong results,= e.g.,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (cond=A0 ((integerp c) ...)=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ...= .
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ((eventp )= =A0 (do-something-with (event-modfiers c)))
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (t
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (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 E= macs 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- f= ucntions in the
Elisp Info documentation.

;; #1
(eventp 'M-S-f5)
> nil<= br>(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-el= ement-mask (f5 167772160) event-symbol-elements (f5 meta shift))

A s= imilar example occurs with, say, M-s-z, even if M-s-z has been defined in t= he global map.

This problem holds with event-basic-type too because it also just check= s the symbol plist.=A0
In #1, for instance, (event-basic-type 'M-S-= f5) would be nil, but not in #3.=A0
Another side of the problem(?) is t= hat in #1=A0 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= 9;d pass it along.

Thanks,

=A0=A0 Chris

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

--20cf300fa9ebf6f12f04b3159da8--