--- Begin Message ---
|
Subject: |
24.3; replace-regexp-in-string wrong on \` |
|
Date: |
Fri, 16 Aug 2013 08:15:53 +1000 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string' |
|
Date: |
Thu, 26 Nov 2020 14:39:01 +0100 |
26 nov. 2020 kl. 14.12 skrev Lars Ingebrigtsen <larsi@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.
--- End Message ---