* 23.0.60; kbd returns wrong value
@ 2008-05-13 20:01 ` Drew Adams
2008-05-16 7:14 ` Drew Adams
2008-08-19 21:55 ` bug#237: marked as done (23.0.60; kbd returns wrong value) Emacs bug Tracking System
0 siblings, 2 replies; 11+ messages in thread
From: Drew Adams @ 2008-05-13 20:01 UTC (permalink / raw
To: emacs-pretest-bug
This is a menu item in menu-bar-help-menu:
<describe> <describe-language-environment> <European> <Brazilian Portuguese>
Evaluating this:
(kbd "<describe> <describe-language-environment> <European> <Brazilian
Portuguese>")
produces the following incorrect result:
[describe describe-language-environment European
60 66 114 97 122 105 108 105 97 110 80 111 114
116 117 103 117 101 115 101 62]
After tracing edmacro-parse-keys, the problem seems to be here:
(while (and (< pos (length string))
(string-match "[^ \t\n\f]+" string pos))
(let ((word (substring string (match-beginning 0) (match-end 0)))
The sexp (substring "<describe> <describe-language-environment> <European>
<Brazilian Portuguese>" 54 64) returns "<Brazilian", which is only half of the
entry.
IOW, the code is not expecting a space char. Which is the problem: the
edmacro-parse-keys code or the definition of the key itself,
<Brazilian Portuguese>, which includes a space char?
This problem is not new with Emacs 23, BTW.
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
of 2008-05-04 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 23.0.60; kbd returns wrong value
2008-05-13 20:01 ` 23.0.60; kbd returns wrong value Drew Adams
@ 2008-05-16 7:14 ` Drew Adams
2008-05-16 9:32 ` David Kastrup
2008-08-19 21:55 ` bug#237: marked as done (23.0.60; kbd returns wrong value) Emacs bug Tracking System
1 sibling, 1 reply; 11+ messages in thread
From: Drew Adams @ 2008-05-16 7:14 UTC (permalink / raw
To: emacs-pretest-bug
This problem is more widespread than I thought. Menu items can of course contain
spaces: <My Foobar>, and when used in submenus the same problem arises as for
<Brazilian Portuguese> in a <Describe> submenu.
An there are other keys that have spaces and so could make `edmacro-parse-keys'
choke in the same way (e.g. if in a submenu). In my `global-map', for instance,
I see these keys that contain spaces:
<RHP of Latin-1>
<RHP of Latin-2>
<RHP of Latin-3>
<RHP of Latin-4>
<RHP of TIS620>
<RHP of ISO8859/7>
<RHP of ISO8859/6>
<RHP of ISO8859/8>
<JISX0201 Katakana>
<JISX0201 Roman>
<RHP of ISO8859/5>
<RHP of Latin-5>
<RHP of Latin-9>
<RHP of Latin-8>
<Big5 (Level-1)>
<Big5 (Level-2)>
<VISCII lower>
<VISCII upper>
<Arabic digit>
<Arabic 1-col>
<rev ASCII>
<Arabic 2-col>
<IS 13194>
<Indian glyph>
<Tibetan 1-col>
<Unicode subset 2>
<Unicode subset 3>
<Unicode subset>
<Indian 2-col>
<Tibetan 2-col>
The bug is thus with `edmacro-parse-keys', not with the fact of having keys with
spaces.
> From: Drew Adams Sent: Tuesday, May 13, 2008 1:02 PM
> This is a menu item in menu-bar-help-menu:
> <describe> <describe-language-environment> <European>
> <Brazilian Portuguese>
>
> Evaluating this:
> (kbd "<describe> <describe-language-environment> <European> <Brazilian
> Portuguese>")
>
> produces the following incorrect result:
>
> [describe describe-language-environment European
> 60 66 114 97 122 105 108 105 97 110 80 111 114
> 116 117 103 117 101 115 101 62]
>
> After tracing edmacro-parse-keys, the problem seems to be here:
>
> (while (and (< pos (length string))
> (string-match "[^ \t\n\f]+" string pos))
> (let ((word (substring string (match-beginning 0)
> (match-end 0)))
>
> The sexp (substring "<describe>
> <describe-language-environment> <European>
> <Brazilian Portuguese>" 54 64) returns "<Brazilian", which is
> only half of the
> entry.
>
> IOW, the code is not expecting a space char. Which is the problem: the
> edmacro-parse-keys code or the definition of the key itself,
> <Brazilian Portuguese>, which includes a space char?
>
> This problem is not new with Emacs 23, BTW.
>
>
> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
> of 2008-05-04 on LENNART-69DE564
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --no-opt
> --cflags -Ic:/g/include
> -fno-crossjumping'
>
>
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 23.0.60; kbd returns wrong value
2008-05-16 7:14 ` Drew Adams
@ 2008-05-16 9:32 ` David Kastrup
2008-05-17 15:13 ` Drew Adams
2008-05-18 3:12 ` Stefan Monnier
0 siblings, 2 replies; 11+ messages in thread
From: David Kastrup @ 2008-05-16 9:32 UTC (permalink / raw
To: Drew Adams; +Cc: emacs-pretest-bug
"Drew Adams" <drew.adams@ORACLE.COM> writes:
> This problem is more widespread than I thought. Menu items can of course contain
> spaces: <My Foobar>, and when used in submenus the same problem arises as for
> <Brazilian Portuguese> in a <Describe> submenu.
>
> An there are other keys that have spaces and so could make `edmacro-parse-keys'
> choke in the same way (e.g. if in a submenu). In my `global-map', for instance,
> I see these keys that contain spaces:
>
> <RHP of Latin-1>
> <RHP of Latin-2>
> <RHP of Latin-3>
> <RHP of Latin-4>
> The bug is thus with `edmacro-parse-keys', not with the fact of having
> keys with spaces.
So how about using
>> After tracing edmacro-parse-keys, the problem seems to be here:
>>
>> (while (and (< pos (length string))
>> (string-match "[^ \t\n\f]+" string pos))
>> (let ((word (substring string (match-beginning 0)
>> (match-end 0)))
(string-match "[^ \t\n\f<]+\\|<[^>]+>" ...
instead?
--
David Kastrup
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 23.0.60; kbd returns wrong value
2008-05-16 9:32 ` David Kastrup
@ 2008-05-17 15:13 ` Drew Adams
2008-05-17 23:46 ` Drew Adams
2008-05-18 3:12 ` Stefan Monnier
1 sibling, 1 reply; 11+ messages in thread
From: Drew Adams @ 2008-05-17 15:13 UTC (permalink / raw
To: 'David Kastrup'; +Cc: emacs-pretest-bug
> >> After tracing edmacro-parse-keys, the problem seems to be here:
> >>
> >> (while (and (< pos (length string))
> >> (string-match "[^ \t\n\f]+" string pos))
> >> (let ((word (substring string (match-beginning 0)
> >> (match-end 0)))
>
> (string-match "[^ \t\n\f<]+\\|<[^>]+>" ...
> instead?
Yes, please install that fix; it seems to do the job. Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 23.0.60; kbd returns wrong value
2008-05-17 15:13 ` Drew Adams
@ 2008-05-17 23:46 ` Drew Adams
2008-05-18 0:00 ` Drew Adams
0 siblings, 1 reply; 11+ messages in thread
From: Drew Adams @ 2008-05-17 23:46 UTC (permalink / raw
To: 'David Kastrup'; +Cc: emacs-pretest-bug
> > >> After tracing edmacro-parse-keys, the problem seems to be here:
> > >>
> > >> (while (and (< pos (length string))
> > >> (string-match "[^ \t\n\f]+" string pos))
> > >> (let ((word (substring string (match-beginning 0)
> > >> (match-end 0)))
> >
> > (string-match "[^ \t\n\f<]+\\|<[^>]+>" ... instead?
>
> Yes, please install that fix; it seems to do the job. Thanks.
Actually, no, that breaks it for "C-x <", producing only "^X" (control-x
character).
The following regexp fixes that particular breakage: "[^
\t\n\f<]+\\|<[^>]+>\\|<+"
But that breaks other things. With input of "C-x <<>>", the output is [24 < 62].
With input of "C-x << >>", the output is [24 <\ 62]. In the vanilla code, e.g.,
the first produces [24 <>], and the second produces "^X<<>>" (control-x char),
which are presumably correct.
I have no idea what that is all about - there are no comments in the code wrt
what it is supposed to do with which inputs.
It would be good if someone who really understands `edmacro-parse-keys' would
please take a look and fix it as needed. And please add a doc string too.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 23.0.60; kbd returns wrong value
2008-05-17 23:46 ` Drew Adams
@ 2008-05-18 0:00 ` Drew Adams
0 siblings, 0 replies; 11+ messages in thread
From: Drew Adams @ 2008-05-18 0:00 UTC (permalink / raw
To: emacs-pretest-bug
> > > >> After tracing edmacro-parse-keys, the problem seems to be here:
> > > >>
> > > >> (while (and (< pos (length string))
> > > >> (string-match "[^ \t\n\f]+" string pos))
> > > >> (let ((word (substring string (match-beginning 0)
> > > >> (match-end 0)))
> > >
> > > (string-match "[^ \t\n\f<]+\\|<[^>]+>" ... instead?
> >
> > Yes, please install that fix; it seems to do the job. Thanks.
>
> Actually, no, that breaks it for "C-x <", producing only "^X"
> (control-x character).
>
> The following regexp fixes that particular breakage:
> "[^ \t\n\f<]+\\|<[^>]+>\\|<+"
>
> But that breaks other things. With input of "C-x <<>>", the
> output is [24 < 62]. With input of "C-x << >>", the output is
> [24 <\ 62]. In the vanilla code, e.g., the first produces
> [24 <>], and the second produces "^X<<>>" (control-x char),
> which are presumably correct.
>
> I have no idea what that is all about - there are no comments
> in the code wrt what it is supposed to do with which inputs.
>
> It would be good if someone who really understands
> `edmacro-parse-keys' would please take a look and fix it as
> needed. And please add a doc string too.
FYI - some more info about use of "[^ \t\n\f<]+\\|<[^>]+>\\|<+" as the regexp:
Input of "M-<" produces "M-<", but it produces [134217788] with vanilla code
(which is correct).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 23.0.60; kbd returns wrong value
2008-05-16 9:32 ` David Kastrup
2008-05-17 15:13 ` Drew Adams
@ 2008-05-18 3:12 ` Stefan Monnier
2008-05-18 5:32 ` Drew Adams
1 sibling, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2008-05-18 3:12 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-pretest-bug, Drew Adams
> (string-match "[^ \t\n\f<]+\\|<[^>]+>" ...
To avoid problems with C-x < and such, I'd recomment
> (string-match "[^ \t\n\f<]+\\|<[^ \n>]\\(?:[^>]*[^ >\n]\\)?>" ...
So there can be spaces in symbols, but not as first or last char.
The handling of "C-x <<" and such shouldn't matter because these aren't
valid anyway.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: 23.0.60; kbd returns wrong value
2008-05-18 3:12 ` Stefan Monnier
@ 2008-05-18 5:32 ` Drew Adams
2008-05-18 9:26 ` More key strangeness (was: 23.0.60; kbd returns wrong value) David Kastrup
0 siblings, 1 reply; 11+ messages in thread
From: Drew Adams @ 2008-05-18 5:32 UTC (permalink / raw
To: 'Stefan Monnier', 'David Kastrup'; +Cc: emacs-pretest-bug
> > (string-match "[^ \t\n\f<]+\\|<[^>]+>" ...
>
> To avoid problems with C-x < and such, I'd recomment
> (string-match "[^ \t\n\f<]+\\|<[^ \n>]\\(?:[^>]*[^ >\n]\\)?>" ...
> So there can be spaces in symbols, but not as first or last char.
See my previous message in reply to David, and my followup to that. Like David's
suggestion for the regexp, yours fails for "C-x <":
(edmacro-parse-keys "C-x <") gives "^X" (control-x character).
> The handling of "C-x <<" and such shouldn't matter because
> these aren't valid anyway.
Then what is that part of the code for? Addin some comments to the code would
help understanding.
^ permalink raw reply [flat|nested] 11+ messages in thread
* More key strangeness (was: 23.0.60; kbd returns wrong value)
2008-05-18 5:32 ` Drew Adams
@ 2008-05-18 9:26 ` David Kastrup
2008-05-19 8:20 ` More key strangeness Stefan Monnier
0 siblings, 1 reply; 11+ messages in thread
From: David Kastrup @ 2008-05-18 9:26 UTC (permalink / raw
To: Drew Adams; +Cc: emacs-pretest-bug, 'Stefan Monnier'
"Drew Adams" <drew.adams@oracle.com> writes:
>> > (string-match "[^ \t\n\f<]+\\|<[^>]+>" ...
>>
>> To avoid problems with C-x < and such, I'd recomment
>> (string-match "[^ \t\n\f<]+\\|<[^ \n>]\\(?:[^>]*[^ >\n]\\)?>" ...
>> So there can be spaces in symbols, but not as first or last char.
>
> See my previous message in reply to David, and my followup to that. Like David's
> suggestion for the regexp, yours fails for "C-x <":
>
> (edmacro-parse-keys "C-x <") gives "^X" (control-x character).
>
>> The handling of "C-x <<" and such shouldn't matter because
>> these aren't valid anyway.
>
> Then what is that part of the code for? Addin some comments to the code would
> help understanding.
Typing C-h k C-x <menu-bar> <options> <highlight-paren-mode>
gives the resulting error message
C-x <menu-bar> is undefined
in the *Messages* buffer, but
<highlight-paren-mode> is undefined
in the echo area.
Wow. Where does that discrepancy come from?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: More key strangeness
2008-05-18 9:26 ` More key strangeness (was: 23.0.60; kbd returns wrong value) David Kastrup
@ 2008-05-19 8:20 ` Stefan Monnier
0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2008-05-19 8:20 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-pretest-bug, Drew Adams
> Typing C-h k C-x <menu-bar> <options> <highlight-paren-mode>
> gives the resulting error message
> C-x <menu-bar> is undefined
> in the *Messages* buffer, but
> <highlight-paren-mode> is undefined
> in the echo area.
> Wow. Where does that discrepancy come from?
I believe there's no discrepancy: What happens is that after selecting
the menu, you end up with 4 events:
C-x <menu-bar> <options> <highlight-paren-mode>
and when reading them to find the corresponding key-sequence and
command, the first key-sequence is
C-x <menu-bar>
and is unbound, so it generates the message "C-x <menu-bar> is
undefined". Then the next event probably generates "<options> is undefined",
and so does <highlight-paren-mode>. So you should see 3 messages
in total.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#237: marked as done (23.0.60; kbd returns wrong value)
2008-05-13 20:01 ` 23.0.60; kbd returns wrong value Drew Adams
2008-05-16 7:14 ` Drew Adams
@ 2008-08-19 21:55 ` Emacs bug Tracking System
1 sibling, 0 replies; 11+ messages in thread
From: Emacs bug Tracking System @ 2008-08-19 21:55 UTC (permalink / raw
To: Chong Yidong
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
Your message dated Tue, 19 Aug 2008 17:47:14 -0400
with message-id <87myj88yot.fsf@cyd.mit.edu>
and subject line Re: 23.0.60; kbd returns wrong value
has caused the Emacs bug report #237,
regarding 23.0.60; kbd returns wrong value
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)
--
237: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=237
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems
[-- Attachment #2: Type: message/rfc822, Size: 6456 bytes --]
From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-pretest-bug@gnu.org>
Cc:
Subject: 23.0.60; kbd returns wrong value
Date: Tue, 13 May 2008 13:01:55 -0700
Message-ID: <003e01c8b534$31cbdd30$0200a8c0@us.oracle.com>
This is a menu item in menu-bar-help-menu:
<describe> <describe-language-environment> <European> <Brazilian Portuguese>
Evaluating this:
(kbd "<describe> <describe-language-environment> <European> <Brazilian
Portuguese>")
produces the following incorrect result:
[describe describe-language-environment European
60 66 114 97 122 105 108 105 97 110 80 111 114
116 117 103 117 101 115 101 62]
After tracing edmacro-parse-keys, the problem seems to be here:
(while (and (< pos (length string))
(string-match "[^ \t\n\f]+" string pos))
(let ((word (substring string (match-beginning 0) (match-end 0)))
The sexp (substring "<describe> <describe-language-environment> <European>
<Brazilian Portuguese>" 54 64) returns "<Brazilian", which is only half of the
entry.
IOW, the code is not expecting a space char. Which is the problem: the
edmacro-parse-keys code or the definition of the key itself,
<Brazilian Portuguese>, which includes a space char?
This problem is not new with Emacs 23, BTW.
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
of 2008-05-04 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
[-- Attachment #3: Type: message/rfc822, Size: 1253 bytes --]
From: Chong Yidong <cyd@stupidchicken.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 237-done@emacsbugs.donarmstrong.com
Subject: Re: 23.0.60; kbd returns wrong value
Date: Tue, 19 Aug 2008 17:47:14 -0400
Message-ID: <87myj88yot.fsf@cyd.mit.edu>
> This is a menu item in menu-bar-help-menu:
> <describe> <describe-language-environment> <European> <Brazilian Portuguese>
>
> Evaluating this:
> (kbd "<describe> <describe-language-environment> <European>
> <Brazilian Portuguese>")
>
> produces the following incorrect result:
I've checked in a fix. Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-08-19 21:55 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87myj88yot.fsf@cyd.mit.edu>
2008-05-13 20:01 ` 23.0.60; kbd returns wrong value Drew Adams
2008-05-16 7:14 ` Drew Adams
2008-05-16 9:32 ` David Kastrup
2008-05-17 15:13 ` Drew Adams
2008-05-17 23:46 ` Drew Adams
2008-05-18 0:00 ` Drew Adams
2008-05-18 3:12 ` Stefan Monnier
2008-05-18 5:32 ` Drew Adams
2008-05-18 9:26 ` More key strangeness (was: 23.0.60; kbd returns wrong value) David Kastrup
2008-05-19 8:20 ` More key strangeness Stefan Monnier
2008-08-19 21:55 ` bug#237: marked as done (23.0.60; kbd returns wrong value) Emacs bug Tracking System
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.