From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>, 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 18:40:43 -0700 (PDT) [thread overview]
Message-ID: <50fbc85d-ea7e-485d-82d3-476f63bd8a32@default> (raw)
In-Reply-To: <jwvr2lx6mce.fsf-monnier+emacs@gnu.org>
> >> 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.
Would it make sense to "formalize" this a bit, by having an
explicit such list of the functions (those "primitive enough"
to never, or perhaps hardly ever, need wrapping with `s-m-d')?
Even if such a list were not consulted by any code (and it
could be, presumably, for some control somewhere), it might
at least help developers and users by letting them know what
the story is.
Just a thought.
next prev parent reply other threads:[~2018-05-28 1:40 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
2018-05-28 1:40 ` Drew Adams [this message]
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=50fbc85d-ea7e-485d-82d3-476f63bd8a32@default \
--to=drew.adams@oracle.com \
--cc=31586@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--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.