From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Eli Zaretskii <eliz@gnu.org>
Cc: p.stephani2@gmail.com, 31586@debbugs.gnu.org
Subject: bug#31586: 27.0.50; `frame-title-format' doesn't save match data
Date: Sun, 27 May 2018 15:32:44 -0400 [thread overview]
Message-ID: <jwvr2lx6mce.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <838t8583yz.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 May 2018 19:20:52 +0300")
>> FWIW, I think this qualifies as a bug in query-replace: Elisp code
>> should never presume that the match-data is preserved across something
>> like sit-for, read-char, or any other function which can run process
>> filters, redisplay, timers, or contains a yield-point.
> Is this practical? We have any number of hooks, advices, and other
> means to make arbitrary Lisp run almost off any function call. Given
> that redisplay can be entered by such Lisp by calling 'redisplay' or
> 'message' or one of the other functions you mentioned, your suggestion
> would mean we need to save-match-data around any call to any
> function. That would make our code very cluttered, indeed.
That's how we've lived so far, except that the need for save-match-data
is not around "any" call, but only around "any call except for <...>"
where <...> is the set of "primitive enough" functions. The main
problem so far is that this set is not formally defined (and also that
the byte-compiler doesn't warn you if you use a function outside of this
set without wrapping with save-match-data), but other than that it works
well in practice, because in 99% there is *very* little code executed
between a regexp match and the use of the match-data.
[ Side question: while `message` does cause a form of redisplay, IIUC it
doesn't cause a *real* redisplay in the sense that it won't recompute
mode-lines, frame-titles, nor will it run jit-lock, IOW it won't run
elisp code. ]
> My POV is that using :eval is intrinsically tricky, and whoever does
> that should take the necessary precautions.
I think it would be preferable to save the match-data around the whole
redisplay than have each :eval do it.
More to the point: AFAICT in the problem at hand, between the
regexp-match and the call to buffer-substring-no-properties, process
filters can be executed, so it's not just the match data which could be
changed, but the whole buffer's contents, so save-match-data around
the :eval call will just patch over one particular instance of a more
general problem, I think.
This said, having looked at the code this time, the bug is not quite as
clear as I thought: perform-replace does already save&restore the match
data, as evidenced by:
(setq key (read-event))
;; Necessary in case something happens during
;; read-event that clobbers the match data.
(set-match-data real-match-data)
But it does it in a fairly complex way, so the exact problem is hard
to pinpoint. If someone can understand what replace-match-data really
does, maybe they can figure out the origin of the problem.
Stefan
next prev parent reply other threads:[~2018-05-27 19:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-24 21:55 bug#31586: 27.0.50; `frame-title-format' doesn't save match data Philipp
2018-05-25 6:31 ` Eli Zaretskii
2018-05-26 20:58 ` Stefan Monnier
2018-05-27 16:20 ` Eli Zaretskii
2018-05-27 19:32 ` Stefan Monnier [this message]
2018-05-28 1:40 ` Drew Adams
2018-05-28 1:46 ` Stefan Monnier
2018-07-30 4:34 ` bug#31586: Binbin YE
2018-07-30 14:19 ` bug#31586: Eli Zaretskii
2022-05-06 17:29 ` bug#33697: 26.1; file-truename messes with match data Lars Ingebrigtsen
2022-05-06 17:49 ` bug#31586: " Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvr2lx6mce.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=31586@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.