GNU bug report logs -
#44861
27.1; [PATCH] signal in `replace-regexp-in-string'
Previous Next
Reported by: Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
Date: Wed, 25 Nov 2020 04:03:02 UTC
Severity: normal
Tags: confirmed, patch
Merged with 15107
Found in versions 24.3, 25.1, 27.1
Done: Mattias Engdegård <mattiase <at> acm.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 15107 <at> debbugs.gnu.org.
--
44861: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44861
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
26 nov. 2020 kl. 14.12 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> 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.
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 4 years and 171 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.