From: Eli Zaretskii <eliz@gnu.org>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: ture@turepalsson.se, 41445@debbugs.gnu.org
Subject: bug#41445: 26.3; Query-replace triggers "match data clobbered by..."
Date: Fri, 22 May 2020 15:35:38 +0300 [thread overview]
Message-ID: <83pnaw2llx.fsf@gnu.org> (raw)
In-Reply-To: <1FF1F90B-CA25-487B-BF5A-EE16E43CF50B@acm.org> (message from Mattias Engdegård on Fri, 22 May 2020 14:21:04 +0200)
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Fri, 22 May 2020 14:21:04 +0200
> Cc: Ture Pålsson <ture@turepalsson.se>, 41445@debbugs.gnu.org
>
> 22 maj 2020 kl. 14.07 skrev Eli Zaretskii <eliz@gnu.org>:
>
> > I think in ucs-normalize-hfs-nfd-post-read-conversion and
> > ucs-normalize-hfs-nfd-pre-write-conversion. IOW, so that this only
> > affects encoding and decoding macOS file names. WDYT?
>
> Both of these call ucs-normalize-region, which makes it natural to save match data in that function. Conversely, anything that calls ucs-normalize-region would have to be wrapped, not just the two functions you mentioned. In other words, there seems to be no advantage in saving the match data in those functions, only disadvantages.
My line of reasoning was that only the callers of ENCODE_FILE and
DECODE_FILE will not expect the match-data to be clobbered. Code that
calls ucs-normalize-region directly may or may not be bothered by the
clobbering, so we should leave that to the caller.
The advantage of not doing this unconditionally is that we don't
unnecessarily punishing callers that don't need match-data to be
saved.
next prev parent reply other threads:[~2020-05-22 12:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 5:07 bug#41445: 26.3; Query-replace triggers "match data clobbered by..." Ture Pålsson
2020-05-22 10:46 ` Mattias Engdegård
2020-05-22 11:11 ` Eli Zaretskii
2020-05-22 11:16 ` Mattias Engdegård
2020-05-22 12:07 ` Eli Zaretskii
2020-05-22 12:21 ` Mattias Engdegård
2020-05-22 12:35 ` Eli Zaretskii [this message]
2020-05-23 11:36 ` Mattias Engdegård
2020-05-23 12:28 ` Eli Zaretskii
2020-05-23 12:37 ` Philipp Stephani
2020-05-23 13:07 ` Eli Zaretskii
2020-05-23 13:08 ` Mattias Engdegård
2020-05-23 13:36 ` Stefan Monnier
2020-05-23 15:43 ` Drew Adams
2020-05-27 14:31 ` Mattias Engdegård
2020-05-27 15:54 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83pnaw2llx.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=41445@debbugs.gnu.org \
--cc=mattiase@acm.org \
--cc=ture@turepalsson.se \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).