* 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.