* bug#3863: 23.1.50; possible save-match-data in copyright.el @ 2009-07-16 0:05 ` Kevin Ryde 2009-07-16 2:01 ` Stefan Monnier 2009-10-02 0:20 ` bug#3863: marked as done (23.1.50; possible save-match-data in copyright.el) Emacs bug Tracking System 0 siblings, 2 replies; 14+ messages in thread From: Kevin Ryde @ 2009-07-16 0:05 UTC (permalink / raw) To: emacs-pretest-bug [-- Attachment #1: Type: text/plain, Size: 1034 bytes --] In recent copyright.el I noticed copyright-update using the match data after a y-or-n-p query. Is that a good idea? When running it in emacs 22 I seemed to sometimes get the match data clobbered by y-or-n-p. I never tracked down the circumstances, but wondered if copyright.el shouldn't rely on what an input func like y-or-n-p could do, per diff below. In GNU Emacs 23.1.50.1 (i586-pc-linux-gnu, GTK+ Version 2.16.4) of 2009-07-12 on blah.blah configured using `configure 'CFLAGS=-O -g' '--prefix=/down/emacs/b/inst' '--with-x-toolkit=gtk'' 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_AU value of $XMODIFIERS: nil locale-coding-system: iso-latin-1-unix default-enable-multibyte-characters: t 2009-07-16 Kevin Ryde <user42@zip.com.au> * emacs-lisp/copyright.el (copyright-update): save-match-data across y-or-n-p, for safety. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: copyright.el.save-match-data.diff --] [-- Type: text/x-diff, Size: 917 bytes --] *** copyright.el 16 Jul 2009 09:44:20 +1000 1.81 --- copyright.el 16 Jul 2009 09:55:57 +1000 *************** *** 223,230 **** (< (string-to-number (match-string 3)) (string-to-number copyright-current-gpl-version)) (or noquery ! (y-or-n-p (format "Replace GPL version by %s? " ! copyright-current-gpl-version))) (progn (if (match-end 2) ;; Esperanto bilingual comment in two-column.el --- 223,231 ---- (< (string-to-number (match-string 3)) (string-to-number copyright-current-gpl-version)) (or noquery ! (save-match-data ! (y-or-n-p (format "Replace GPL version by %s? " ! copyright-current-gpl-version)))) (progn (if (match-end 2) ;; Esperanto bilingual comment in two-column.el ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-16 0:05 ` bug#3863: 23.1.50; possible save-match-data in copyright.el Kevin Ryde @ 2009-07-16 2:01 ` Stefan Monnier 2009-10-02 0:20 ` bug#3863: marked as done (23.1.50; possible save-match-data in copyright.el) Emacs bug Tracking System 1 sibling, 0 replies; 14+ messages in thread From: Stefan Monnier @ 2009-07-16 2:01 UTC (permalink / raw) To: Kevin Ryde; +Cc: emacs-pretest-bug, 3863 > 2009-07-16 Kevin Ryde <user42@zip.com.au> > * emacs-lisp/copyright.el (copyright-update): save-match-data across > y-or-n-p, for safety. Thanks, installed, Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: marked as done (23.1.50; possible save-match-data in copyright.el) 2009-07-16 0:05 ` bug#3863: 23.1.50; possible save-match-data in copyright.el Kevin Ryde 2009-07-16 2:01 ` Stefan Monnier @ 2009-10-02 0:20 ` Emacs bug Tracking System 1 sibling, 0 replies; 14+ messages in thread From: Emacs bug Tracking System @ 2009-10-02 0:20 UTC (permalink / raw) To: Kevin Ryde [-- Attachment #1: Type: text/plain, Size: 890 bytes --] Your message dated Fri, 02 Oct 2009 10:14:07 +1000 with message-id <87fxa27iuo.fsf@blah.blah> and subject line Re: bug#3863: 23.1.50; possible save-match-data in copyright.el has caused the Emacs bug report #3863, regarding 23.1.50; possible save-match-data in copyright.el 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 owner@emacsbugs.donarmstrong.com immediately.) -- 3863: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3863 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 4412 bytes --] [-- Attachment #2.1.1: Type: text/plain, Size: 1034 bytes --] In recent copyright.el I noticed copyright-update using the match data after a y-or-n-p query. Is that a good idea? When running it in emacs 22 I seemed to sometimes get the match data clobbered by y-or-n-p. I never tracked down the circumstances, but wondered if copyright.el shouldn't rely on what an input func like y-or-n-p could do, per diff below. In GNU Emacs 23.1.50.1 (i586-pc-linux-gnu, GTK+ Version 2.16.4) of 2009-07-12 on blah.blah configured using `configure 'CFLAGS=-O -g' '--prefix=/down/emacs/b/inst' '--with-x-toolkit=gtk'' 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_AU value of $XMODIFIERS: nil locale-coding-system: iso-latin-1-unix default-enable-multibyte-characters: t 2009-07-16 Kevin Ryde <user42@zip.com.au> * emacs-lisp/copyright.el (copyright-update): save-match-data across y-or-n-p, for safety. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2.1.2: copyright.el.save-match-data.diff --] [-- Type: text/x-diff, Size: 917 bytes --] *** copyright.el 16 Jul 2009 09:44:20 +1000 1.81 --- copyright.el 16 Jul 2009 09:55:57 +1000 *************** *** 223,230 **** (< (string-to-number (match-string 3)) (string-to-number copyright-current-gpl-version)) (or noquery ! (y-or-n-p (format "Replace GPL version by %s? " ! copyright-current-gpl-version))) (progn (if (match-end 2) ;; Esperanto bilingual comment in two-column.el --- 223,231 ---- (< (string-to-number (match-string 3)) (string-to-number copyright-current-gpl-version)) (or noquery ! (save-match-data ! (y-or-n-p (format "Replace GPL version by %s? " ! copyright-current-gpl-version)))) (progn (if (match-end 2) ;; Esperanto bilingual comment in two-column.el [-- Attachment #3: Type: message/rfc822, Size: 1938 bytes --] From: Kevin Ryde <user42@zip.com.au> To: 3863-done@emacsbugs.donarmstrong.com Subject: Re: bug#3863: 23.1.50; possible save-match-data in copyright.el Date: Fri, 02 Oct 2009 10:14:07 +1000 Message-ID: <87fxa27iuo.fsf@blah.blah> Closing for, Stefan Monnier <monnier@iro.umontreal.ca> writes: > > installed, ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
@ 2009-07-16 14:33 Chong Yidong
2009-07-16 17:24 ` Stefan Monnier
2009-08-06 0:56 ` Kevin Ryde
0 siblings, 2 replies; 14+ messages in thread
From: Chong Yidong @ 2009-07-16 14:33 UTC (permalink / raw)
To: Kevin Ryde; +Cc: 3863
> In recent copyright.el I noticed copyright-update using the match data
> after a y-or-n-p query. Is that a good idea?
>
> When running it in emacs 22 I seemed to sometimes get the match data
> clobbered by y-or-n-p.
If so, we should change y-or-n-p to save the match data. Could you
provide a reproducible test-case for the clobbering of the match data?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-16 14:33 bug#3863: 23.1.50; possible save-match-data in copyright.el Chong Yidong @ 2009-07-16 17:24 ` Stefan Monnier 2009-07-16 18:42 ` Lennart Borgman 2009-07-16 18:54 ` Chong Yidong 2009-08-06 0:56 ` Kevin Ryde 1 sibling, 2 replies; 14+ messages in thread From: Stefan Monnier @ 2009-07-16 17:24 UTC (permalink / raw) To: Chong Yidong; +Cc: 3863, Kevin Ryde > If so, we should change y-or-n-p to save the match data. Why? y-or-n-p will yield waiting for user input, so it's basically a point where any other code can run. It's one of the prime examples of a function which you can't expect to preserve the match-data. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-16 17:24 ` Stefan Monnier @ 2009-07-16 18:42 ` Lennart Borgman 2009-07-17 3:23 ` Stefan Monnier 2009-07-16 18:54 ` Chong Yidong 1 sibling, 1 reply; 14+ messages in thread From: Lennart Borgman @ 2009-07-16 18:42 UTC (permalink / raw) To: Stefan Monnier, 3863; +Cc: Chong Yidong, Kevin Ryde On Thu, Jul 16, 2009 at 7:24 PM, Stefan Monnier<monnier@iro.umontreal.ca> wrote: >> If so, we should change y-or-n-p to save the match data. > > Why? y-or-n-p will yield waiting for user input, so it's basically > a point where any other code can run. It's one of the prime examples of > a function which you can't expect to preserve the match-data. I don't think I understand, but it sounds like this is a reason why y-or-n-p should save match-data... Is there any reason not to let y-or-n-p save match data? I mean the function needing match data possibly want yield until it has used it, or? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-16 18:42 ` Lennart Borgman @ 2009-07-17 3:23 ` Stefan Monnier 2009-07-17 4:00 ` Lennart Borgman 2009-07-17 7:57 ` martin rudalics 0 siblings, 2 replies; 14+ messages in thread From: Stefan Monnier @ 2009-07-17 3:23 UTC (permalink / raw) To: Lennart Borgman; +Cc: 3863, Kevin Ryde, Chong Yidong > I don't think I understand, but it sounds like this is a reason why > y-or-n-p should save match-data... Here we go again: All functions destroy the match-data except for a few rare exceptions, which are simple functions doing little work. > Is there any reason not to let y-or-n-p save match data? If you think y-or-n-p deserves saving the match-data then pretty much all other functions deserve that change as well. And since save-match-data is somewhat costly, it would imply a singificant performance impact. Stefan PS: Worse yet: during y-or-n-p, the buffer might be completely changed by the code run asynchronously, so the "saved" match data may not even have any meaning any more. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-17 3:23 ` Stefan Monnier @ 2009-07-17 4:00 ` Lennart Borgman 2009-07-17 7:57 ` martin rudalics 1 sibling, 0 replies; 14+ messages in thread From: Lennart Borgman @ 2009-07-17 4:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: 3863, Kevin Ryde, Chong Yidong On Fri, Jul 17, 2009 at 5:23 AM, Stefan Monnier<monnier@iro.umontreal.ca> wrote: >> I don't think I understand, but it sounds like this is a reason why >> y-or-n-p should save match-data... > > Here we go again: > > All functions destroy the match-data except for a few rare exceptions, > which are simple functions doing little work. > >> Is there any reason not to let y-or-n-p save match data? > > If you think y-or-n-p deserves saving the match-data then pretty much > all other functions deserve that change as well. And since > save-match-data is somewhat costly, it would imply a singificant > performance impact. Sorry, I just meant that since the functions that prompts the user can't really impact performance if we just add save-match-data to them we could do that just to get some more protection. It does not cure the problem that some functions running in timers forgets to save match data, but perhaps it catches some actually occuring problem cases. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-17 3:23 ` Stefan Monnier 2009-07-17 4:00 ` Lennart Borgman @ 2009-07-17 7:57 ` martin rudalics 1 sibling, 0 replies; 14+ messages in thread From: martin rudalics @ 2009-07-17 7:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: 3863 > If you think y-or-n-p deserves saving the match-data then pretty much > all other functions deserve that change as well. And since > save-match-data is somewhat costly, it would imply a singificant > performance impact. You're obviously right and I meanwhile also learned to share your earlier reservations wrt `looking-at-p' and `string-match-p'. However, the underlying problem deserves a profound explanation in the Elisp manual in oder to avoid such discussions in the future. So please, pretty please, write one. martin ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-16 17:24 ` Stefan Monnier 2009-07-16 18:42 ` Lennart Borgman @ 2009-07-16 18:54 ` Chong Yidong 2009-07-17 3:24 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: Chong Yidong @ 2009-07-16 18:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: 3863, Kevin Ryde Stefan Monnier <monnier@iro.umontreal.ca> writes: > Why? y-or-n-p will yield waiting for user input, so it's basically > a point where any other code can run. It's one of the prime examples of > a function which you can't expect to preserve the match-data. I'm not sure what you're referring to. What other code runs during y-or-n-p (excluding timers, which are supposed to save the match data)? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-16 18:54 ` Chong Yidong @ 2009-07-17 3:24 ` Stefan Monnier 2009-07-17 3:54 ` Chong Yidong 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2009-07-17 3:24 UTC (permalink / raw) To: Chong Yidong; +Cc: 3863, Kevin Ryde > I'm not sure what you're referring to. What other code runs during > y-or-n-p (excluding timers, which are supposed to save the match data)? Timers, Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-17 3:24 ` Stefan Monnier @ 2009-07-17 3:54 ` Chong Yidong 2009-07-17 16:00 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Chong Yidong @ 2009-07-17 3:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: 3863, Kevin Ryde Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I'm not sure what you're referring to. What other code runs during >> y-or-n-p (excluding timers, which are supposed to save the match data)? > > Timers, As the Lisp manual states, If a timer function calls functions that can change the match data, it should save and restore the match data. If a timer fails to do this, it's a bug, and should be fixed. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-17 3:54 ` Chong Yidong @ 2009-07-17 16:00 ` Stefan Monnier 0 siblings, 0 replies; 14+ messages in thread From: Stefan Monnier @ 2009-07-17 16:00 UTC (permalink / raw) To: Chong Yidong; +Cc: 3863, Kevin Ryde >>> I'm not sure what you're referring to. What other code runs during >>> y-or-n-p (excluding timers, which are supposed to save the match data)? >> >> Timers, > As the Lisp manual states, > If a timer function calls functions that can change the match data, > it should save and restore the match data. > If a timer fails to do this, it's a bug, and should be fixed. Wonderful, so we all agree there's no need to make y-or-n-p save the match-data. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el 2009-07-16 14:33 bug#3863: 23.1.50; possible save-match-data in copyright.el Chong Yidong 2009-07-16 17:24 ` Stefan Monnier @ 2009-08-06 0:56 ` Kevin Ryde 1 sibling, 0 replies; 14+ messages in thread From: Kevin Ryde @ 2009-08-06 0:56 UTC (permalink / raw) To: Chong Yidong; +Cc: 3863 Chong Yidong <cyd@stupidchicken.com> writes: > > Could you > provide a reproducible test-case for the clobbering of the match data? When I struck it, which is a while ago now, it was intermittent. It could even have been some of my own input defadvice stuff, though I thought it wasn't. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-10-02 0:20 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87fxa27iuo.fsf@blah.blah> 2009-07-16 0:05 ` bug#3863: 23.1.50; possible save-match-data in copyright.el Kevin Ryde 2009-07-16 2:01 ` Stefan Monnier 2009-10-02 0:20 ` bug#3863: marked as done (23.1.50; possible save-match-data in copyright.el) Emacs bug Tracking System 2009-07-16 14:33 bug#3863: 23.1.50; possible save-match-data in copyright.el Chong Yidong 2009-07-16 17:24 ` Stefan Monnier 2009-07-16 18:42 ` Lennart Borgman 2009-07-17 3:23 ` Stefan Monnier 2009-07-17 4:00 ` Lennart Borgman 2009-07-17 7:57 ` martin rudalics 2009-07-16 18:54 ` Chong Yidong 2009-07-17 3:24 ` Stefan Monnier 2009-07-17 3:54 ` Chong Yidong 2009-07-17 16:00 ` Stefan Monnier 2009-08-06 0:56 ` Kevin Ryde
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.