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

[GNU bug Tracking System]

Your message dated Thu, 26 Nov 2020 14:39:01 +0100
with message-id <C136B0DC-1CC5-499E-8BBD-14EAF9E2A4EB@acm.org>
and subject line Re: bug#44861: 27.1; [PATCH] signal in 
`replace-regexp-in-string'
has caused the debbugs.gnu.org bug report #44861,
regarding 27.1; [PATCH] signal in `replace-regexp-in-string'
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
44861: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44861
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: 27.1; [PATCH] signal in `replace-regexp-in-string' Date: Wed, 25 Nov 2020 13:02:11 +0900

`replace-regexp-in-string' sometimes signals an error when REGEXP
contains some bondary sequence.  Difference of searches between
against an original passed string and against an extracted substring
causes the incident.


(replace-regexp-in-string-simple "a\\B" "A" "a aaaa")
        error --> cons: Args out of range: 2, 3
    expected
        ==> "a AAAa"

(replace-regexp-in-string "\\Ba" "A" "a aaaa")
        error --> cons: Args out of range: 3, 4
    expected
        ==> "a aAAA"

--
Shigeru

subr.diff
Description: Binary data

--- 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 ---