GNU bug report logs - #44861
27.1; [PATCH] signal in `replace-regexp-in-string'

Previous Next

Full log

Message #47 received at 44861 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 44861 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>,
 Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
Subject: Re: bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string'
Date: Thu, 26 Nov 2020 15:54:56 +0100

26 nov. 2020 kl. 15.03 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

> I started looking at that, and there's a huge pile of calls like
> 
> (replace-regexp-in-string ":" ";" string)
> 
> that can be rewritten to use string-replace.  But!  Every single case
> requires careful analysis, exactly because replace-regexp-in-string sets
> the match data.

No it doesn't; the entire body is wrapped in save-match-data.
It does set the match data locally for use in the replacement function, if any, but then string-replace cannot be used anyway.

There are other things that may need investigating for a switch to string-replace: whether case-folding is relevant, and whether a nil-or-absent argument to FIXEDCASE is intended, an oversight, or irrelevant.

In my experience, most code does not take case-folding into account at all or tacitly assume it does not apply. (Having a global variable controlling it is a terrible interface, by the way.) Similarly, most calls that omit FIXEDCASE do it without any thought that the replacement would be anything but literal. Thus, the risk isn't very big for either but these are still issues requiring some consideration.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.