Subject: bug#15107: closed (Re: bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string')

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 26 Nov 2020 13:40:02 +0000

Your bug report

#44861: 24.3; replace-regexp-in-string wrong on \`

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
44861: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44861
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string'
From: Mattias Engdegård <[email-masked]>
To: Lars Ingebrigtsen <[email-masked]>
Cc: Dmitry Gutov <[email-masked]>, [email-masked], Stefan Kangas <[email-masked]>, Shigeru Fukaya <[email-masked]>
Date: Thu, 26 Nov 2020 14:39:01 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

26 nov. 2020 kl. 14.12 skrev Lars Ingebrigtsen <[email-masked]>:

> I'm all for speeding up replace-regexp-in-string (which is used all over
> the place), so your change looks reasonable to me.

Thank you! Pushed to master.

> But I wonder -- would it make sense to move the entire
> replace-regexp-in-string function to C?

Probably, but that would be a pure performance improvement. Most of the time is currently consumed in primitives (string-match, replace-match, substring, concat) so don't expect huge savings unless a substantially different approach is taken.

(Dmitry Gutov asked for a C implementation in bug#20273 for improving the speed of json encoding; is that still relevant?)

A bigger saving yet would be to use the much faster string-replace wherever possible. A little sweeping refactoring project perhaps? It would also improve readability -- no regexp quoting, fewer mysterious arguments like LITERAL and FIXEDCASE to worry about, etc.

Subject: 24.3; replace-regexp-in-string wrong on \`
From: Kevin Ryde <[email-masked]>
To: [email-masked]
Date: Fri, 16 Aug 2013 08:15:53 +1000
List-Id: <debbugs-submit.debbugs.gnu.org>

replace-regexp-in-string behaves incorrectly if a regexp has \` among
its matches.

    (replace-regexp-in-string "\\`\\|X" "Z" "--XX--" t t)
    =>
    "Z--ZXZX--"

where I expected

    "Z--ZZ--"

This seems to be due to the optimization in replace-regexp-in-string
which re-matches on the matched substring.  \' can match the substring
where it did not match in the middle of the full string.  In the example
above "X" is the match in the full string, but on taking that "X" as a
substring it can match "\\`".

Probably similar mismatches on the substring occur for things like \' ^
$ \b \< etc.  Maybe the comment in the code about munging the match data
would be a better way.

In GNU Emacs 24.3.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2013-05-29 on blah.blah, modified by Debian
System Description:	Debian GNU/Linux testing/unstable

Configured using:
 `configure '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/i386-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=lucid' '--with-toolkit-scroll-bars' '--without-gconf'
 'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
 'LDFLAGS=-Wl,-z,relro -Wl,-znocombreloc'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LANG: en_AU
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t