GNU bug report logs - #36372
27.0.50; replace-regexp-in-string skips START first chars in return value

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36372 in the body.
You can then email your comments to 36372 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; replace-regexp-in-string skips START first chars in return
 value
Date: Tue, 25 Jun 2019 14:01:49 +0200

From the doc string and the manual, the call

 (replace-regexp-in-string "a" "X" "abcab" t t nil 2)

would be expected to return

 "abcXb"

but the actual return value is

 "cXb"

This was probably not intended. The manual text is

 This function copies STRING and searches it for matches for REGEXP,
 and replaces them with REP.  It returns the modified copy.  If
 START is non-‘nil’, the search for matches starts at that index in
 STRING, so matches starting before that index are not changed.

The question is whether it is too late to fix the bug, or if it needs to be documented.

`string-match' + `replace-match' work as expected:

(let ((s "abcab"))
  (string-match "a" s 2)
  (replace-match "X" t t s))
=> "abcXb"

Bug#15107 is somewhat related.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50;
 replace-regexp-in-string skips START first chars in return value
Date: Tue, 25 Jun 2019 18:26:22 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 25 Jun 2019 14:01:49 +0200
> 
>  (replace-regexp-in-string "a" "X" "abcab" t t nil 2)
> 
> would be expected to return
> 
>  "abcXb"
> 
> but the actual return value is
> 
>  "cXb"
> 
> This was probably not intended. The manual text is
> 
>  This function copies STRING and searches it for matches for REGEXP,
>  and replaces them with REP.  It returns the modified copy.  If
>  START is non-‘nil’, the search for matches starts at that index in
>  STRING, so matches starting before that index are not changed.
> 
> The question is whether it is too late to fix the bug, or if it needs to be documented.

Both, I think ;-)

Thanks.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 11:31:01 +0200

[Message part 1 (text/plain, inline)]

25 juni 2019 kl. 17.26 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
>> The question is whether it is too late to fix the bug, or if it needs to be documented.
> 
> Both, I think ;-)

Documenting a bug rather than fixing it never feels very satisfactory, but it may be the lesser evil.
What about this patch?

[0001-Document-bug-in-replace-regexp-in-string.patch (application/octet-stream, attachment)]

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50;
 replace-regexp-in-string skips START first chars in return value
 [PATCH]
Date: Wed, 26 Jun 2019 11:38:53 +0200

>>>>> On Wed, 26 Jun 2019 11:31:01 +0200, Mattias Engdegård <mattiase <at> acm.org> said:

    Mattias> 25 juni 2019 kl. 17.26 skrev Eli Zaretskii <eliz <at> gnu.org>:
    >> 
    >>> The question is whether it is too late to fix the bug, or if it needs to be documented.
    >> 
    >> Both, I think ;-)

    Mattias> Documenting a bug rather than fixing it never feels very satisfactory, but it may be the lesser evil.
    Mattias> What about this patch?

I think this is one of those 'who could possibly be relying on this
behaviour' bugs that bites you hard if you change things, so
documentation is probably best. Minor nits below

    Mattias> From d5419cbf491cccb91843b8e3d6270df1c40a9004 Mon Sep 17 00:00:00 2001
    Mattias> From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase <at> acm.org>
    Mattias> Date: Wed, 26 Jun 2019 11:23:32 +0200
    Mattias> Subject: [PATCH] Document bug in `replace-regexp-in-string'

    Mattias> `replace-regexp-in-string' omits the first START characters of the
    Mattias> input string in its return value.  This is a clear bug, but fixing it
    Mattias> probably causes more trouble; document the behaviour instead (bug#36372).

    Mattias> * doc/lispref/searching.texi (Search and Replace)
    Mattias> * lisp/subr.el (replace-regexp-in-string):
    Mattias> Document current behaviour.
    Mattias> ---
    Mattias>  doc/lispref/searching.texi | 4 ++--
    Mattias>  lisp/subr.el               | 3 ++-
    Mattias>  2 files changed, 4 insertions(+), 3 deletions(-)

    Mattias> diff --git a/doc/lispref/searching.texi b/doc/lispref/searching.texi
    Mattias> index 33455114da..86a907021c 100644
    Mattias> --- a/doc/lispref/searching.texi
    Mattias> +++ b/doc/lispref/searching.texi
    Mattias> @@ -1790,8 +1790,8 @@ Search and Replace
    Mattias>  This function copies @var{string} and searches it for matches for
    Mattias>  @var{regexp}, and replaces them with @var{rep}.  It returns the
    Mattias>  modified copy.  If @var{start} is non-@code{nil}, the search for
    Mattias> -matches starts at that index in @var{string}, so matches starting
    Mattias> -before that index are not changed.
    Mattias> +matches starts at that index in @var{string}, and the returned value
    Mattias> +does not include first @var{start} characters of @var{string}.

insert 'the' before 'first'

    Mattias>  This function uses @code{replace-match} to do the replacement, and it
    Mattias>  passes the optional arguments @var{fixedcase}, @var{literal} and
    Mattias> diff --git a/lisp/subr.el b/lisp/subr.el
    Mattias> index baff1e909a..ba388b3721 100644
    Mattias> --- a/lisp/subr.el
    Mattias> +++ b/lisp/subr.el
    Mattias> @@ -4208,7 +4208,8 @@ replace-regexp-in-string
 
    Mattias>  Optional arguments FIXEDCASE, LITERAL and SUBEXP are like the
    Mattias>  arguments with the same names of function `replace-match'.  If START
    Mattias> -is non-nil, start replacements at that index in STRING.
    Mattias> +is non-nil, start replacements at that index in STRING.  The return
    Mattias> +value then omits the first START characters of STRING.
 
'at that index in STRING, and omit the first START characters from the
return value.'

    Mattias>  REP is either a string used as the NEWTEXT arg of `replace-match' or a
    Mattias>  function.  If it is a function, it is called with the actual text of each
    Mattias> -- 
    Mattias> 2.20.1 (Apple Git-117)

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 12:01:45 +0200

[Message part 1 (text/plain, inline)]

26 juni 2019 kl. 11.38 skrev Robert Pluim <rpluim <at> gmail.com>:
> 
> insert 'the' before 'first'

Oh dear, thank you for spotting that.

>    Mattias>  Optional arguments FIXEDCASE, LITERAL and SUBEXP are like the
>    Mattias>  arguments with the same names of function `replace-match'.  If START
>    Mattias> -is non-nil, start replacements at that index in STRING.
>    Mattias> +is non-nil, start replacements at that index in STRING.  The return
>    Mattias> +value then omits the first START characters of STRING.
> 
> 'at that index in STRING, and omit the first START characters from the
> return value.'

Thank you, but that would approach circular reasoning (from what return value, exactly? The one that we are in the process of defining?). I went with

[...] If START is non-nil, start replacements at that index in STRING, and omit the first START characters of STRING from the return value.

in the revised patch below.

[0001-Document-bug-in-replace-regexp-in-string.patch (application/octet-stream, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50;
 replace-regexp-in-string skips START first chars in return value
 [PATCH]
Date: Wed, 26 Jun 2019 12:22:06 +0200

Robert Pluim <rpluim <at> gmail.com> writes:

> I think this is one of those 'who could possibly be relying on this
> behaviour' bugs that bites you hard if you change things, so
> documentation is probably best.

Yup.  But this is very unusual behaviour for such a function, so even if
documented, it's going to cause confusion...

Has anybody grepped through the Emacs tree to see whether anybody uses
the parameter, and if so, whether it's expecting the wrong behaviour?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50;
 replace-regexp-in-string skips START first chars in return value
 [PATCH]
Date: Wed, 26 Jun 2019 13:11:34 +0200

>>>>> On Wed, 26 Jun 2019 12:01:45 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
    >> 'at that index in STRING, and omit the first START characters from the
    >> return value.'

    Mattias> Thank you, but that would approach circular reasoning (from what return value, exactly? The one that we are in the process of defining?). I went with

    Mattias> [...] If START is non-nil, start replacements at that index in STRING, and omit the first START characters of STRING from the return value.

Sure, that works.

Robert

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50;
 replace-regexp-in-string skips START first chars in return value
 [PATCH]
Date: Wed, 26 Jun 2019 14:32:40 +0200

>>>>> On Wed, 26 Jun 2019 12:22:06 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Larsi> Robert Pluim <rpluim <at> gmail.com> writes:
    >> I think this is one of those 'who could possibly be relying on this
    >> behaviour' bugs that bites you hard if you change things, so
    >> documentation is probably best.

    Larsi> Yup.  But this is very unusual behaviour for such a function, so even if
    Larsi> documented, it's going to cause confusion...

    Larsi> Has anybody grepped through the Emacs tree to see whether anybody uses
    Larsi> the parameter, and if so, whether it's expecting the wrong behaviour?

'grep'? Sounds complicated. I ran a combination of find-dired and
diredp-do-apply-function over the lisp sources, and none of the 656
calls to replace-regexp-in-string have 7 arguments.

Robert

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50;
 replace-regexp-in-string skips START first chars in return value
 [PATCH]
Date: Wed, 26 Jun 2019 15:51:41 +0200

Robert Pluim <rpluim <at> gmail.com> writes:

> 'grep'? Sounds complicated. I ran a combination of find-dired and
> diredp-do-apply-function over the lisp sources, and none of the 656
> calls to replace-regexp-in-string have 7 arguments.

I started thinking about adding a check in the byte compiler for this,
but now you've checked anyway.  :-)

So it isn't used in-tree at all.  Since it's an (in my opinion) pretty
useless parameter as it's currently implemented, I think we should
deprecate the parameter and remove the documentation.

Then, perhaps, in ten years time we can reintroduce the parameter with
better semantics.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Mattias Engdegård <mattiase <at> acm.org>
Cc: 36372 <at> debbugs.gnu.org
Subject: RE: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 07:01:04 -0700 (PDT)

> So it isn't used in-tree at all.  Since it's an (in my opinion) pretty
> useless parameter as it's currently implemented, I think we should
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> deprecate the parameter and remove the documentation.
> 
> Then, perhaps, in ten years time we can reintroduce the parameter with
> better semantics.  :-)

1. Whether it's used in-tree is not sufficient.

2. Whether it is useless "as it's currently
   implemented" is not sufficient.  That's what
   implementation bugs are about.

3. But I agree that it is likely very rarely used,
   if at all.  (Searched my code and found no
   matches, as one example.)

3. IF it has a use, when fixed as you see fit,
   then fix it, and call out the fixed behavior
   as an incompatible change.  In that case, do
   not deprecate it.  (I don't know that it has
   a use, if fixed, hence "IF".)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: mattiase <at> acm.org, 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50;
 replace-regexp-in-string skips START first chars in return value
 [PATCH]
Date: Wed, 26 Jun 2019 17:51:01 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 26 Jun 2019 15:51:41 +0200
> Cc: 36372 <at> debbugs.gnu.org
> 
> So it isn't used in-tree at all.  Since it's an (in my opinion) pretty
> useless parameter as it's currently implemented, I think we should
> deprecate the parameter and remove the documentation.

I disagree.  This has been in Emacs since 2000, it's too late to
remove it.  We must assume that whoever wrote the code (which operated
like that from the get-go) actually meant for it to operate like that.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 18:17:13 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 26 Jun 2019 11:31:01 +0200
> Cc: 36372 <at> debbugs.gnu.org
> 
> diff --git a/doc/lispref/searching.texi b/doc/lispref/searching.texi
> index 33455114da..86a907021c 100644
> --- a/doc/lispref/searching.texi
> +++ b/doc/lispref/searching.texi
> @@ -1790,8 +1790,8 @@ Search and Replace
>  This function copies @var{string} and searches it for matches for
>  @var{regexp}, and replaces them with @var{rep}.  It returns the
>  modified copy.  If @var{start} is non-@code{nil}, the search for
> -matches starts at that index in @var{string}, so matches starting
> -before that index are not changed.
> +matches starts at that index in @var{string}, and the returned value
> +does not include first @var{start} characters of @var{string}.

For the manual, I'd expand a bit on this, and explained how to get the
result you thought you will when using non-nil START (by concatenating
with the initial substring).

Thanks.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Clément Pit-Claudel <cpitclaudel <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 17:20:02 +0200

26 juni 2019 kl. 16.51 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> 
>> So it isn't used in-tree at all.  Since it's an (in my opinion) pretty
>> useless parameter as it's currently implemented, I think we should
>> deprecate the parameter and remove the documentation.
> 
> I disagree.  This has been in Emacs since 2000, it's too late to
> remove it.  We must assume that whoever wrote the code (which operated
> like that from the get-go) actually meant for it to operate like that.

It may be too late to change, but that doesn't mean that we have to agree with your last statement: it looks like a mistake from the very beginning to me. Given the seventh argument's infrequency of use (and the lack of tests), this is perfectly plausible.

By the way, I found no use of the START argument in GNU ELPA either so I started searching all elisp code on my disk, and found exactly one, in company-coq.

Clément, apologies for dragging you into the discussion, but when you woke up this morning, you probably didn't know that you were possibly the only man in history to use the last argument to replace-regexp-in-string.
Now I would be curious to know:

(1) Does this code, in company-coq--loc-fully-qualified-name, actually work the way you intended? (Looks like it.)
(2) Did you learn how the START parameter affects the return value by reading the doc string, the manual, the source code, or by testing?
(3) Are you aware of other code using the START parameter to replace-regexp-in-string?

Clearly this is anecdotal evidence but we have little else.

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

From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 11:59:35 -0400

On 2019-06-26 11:20, Mattias Engdegård wrote:
> Clément, apologies for dragging you into the discussion, but when you woke up this morning, you probably didn't know that you were possibly the only man in history to use the last argument to replace-regexp-in-string.

Well, my morning just got a lot more interesting :)

> Now I would be curious to know:
> 
> (1) Does this code, in company-coq--loc-fully-qualified-name, actually work the way you intended? (Looks like it.)

Yes, I think it does.  It's a bit inscrutable, so here's an annotated copy:

(defun company-coq--loc-fully-qualified-name (fqn)
  ;; assume fqn is Coq.Init.Nat.max
  (let* ((spec (company-coq-longest-matching-path-spec fqn))
         ;; … spec is ("Coq.Init" . "/build/coq/theories/Init/")
         (logical (if spec (concat (car spec) ".") ""))
         ;; … logical is "Coq.Init."
         (mod-name (replace-regexp-in-string "\\..*\\'" "" fqn nil nil nil (length logical))))
         ;; … mod-name is "Nat"
    (company-coq-library-path logical mod-name spec)))
    ;; … return /build/coq/theories/Init/Nat.v

The reason for this odd dance is that a Coq identifier is essentially a directory path (Coq.Init.) + a file name (here Nat.) + an identifier name (max).  But in some cases there can be modules in the path too, like maybe Coq.Init.Nat.XYZ.max, and in those cases the file is still only 'Nat.' 

This code would probably be clearer if I just used a substring to trim out the beginning of the string ^^

> (2) Did you learn how the START parameter affects the return value by reading the doc string, the manual, the source code, or by testing?

Almost certainly the docstring, confirmed by testing.  I haven't looked at this section of the manual.  

> (3) Are you aware of other code using the START parameter to replace-regexp-in-string?

Nothing off the top of my head, but I probably wouldn't have thought of the instance in company-coq either.  A quick grep through my local sources doesn't turn up anything else, but a quick visual check isn't a very reliable method (did you use a plain grep to find the instance in company-coq, or do you have a more sophisticated trick?).

Hope this helps,
Clément.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 19:03:19 +0200

[Message part 1 (text/plain, inline)]

26 juni 2019 kl. 17.59 skrev Clément Pit-Claudel <cpitclaudel <at> gmail.com>:
> 
>> (1) Does this code, in company-coq--loc-fully-qualified-name, actually work the way you intended? (Looks like it.)
> 
> Yes, I think it does.  It's a bit inscrutable, so here's an annotated copy:

Thanks, so at least it wasn't written blindly from the docs --- good to know.

> This code would probably be clearer if I just used a substring to trim out the beginning of the string ^^

Well I thought so, but who am I to judge? If it works...

>> (2) Did you learn how the START parameter affects the return value by reading the doc string, the manual, the source code, or by testing?
> 
> Almost certainly the docstring, confirmed by testing.  I haven't looked at this section of the manual. 
> 
>> (3) Are you aware of other code using the START parameter to replace-regexp-in-string?
> 
> Nothing off the top of my head, but I probably wouldn't have thought of the instance in company-coq either.  A quick grep through my local sources doesn't turn up anything else, but a quick visual check isn't a very reliable method (did you use a plain grep to find the instance in company-coq, or do you have a more sophisticated trick?).

Definitely not sophisticated, just re-purposed my old regexp trawler (attached in case you want to try).

Clément, thank you very much for humouring me. We are in the unenviable position to decide whether to fix an old, unsatisfactory, apparently very rarely used interface, or to document the behaviour. The stakes are low, but it looks like the semantics will be kept after all.

26 juni 2019 kl. 17.17 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> For the manual, I'd expand a bit on this, and explained how to get the
> result you thought you will when using non-nil START (by concatenating
> with the initial substring).

All right, I added a sentence to that effect.

[0001-Document-bug-in-replace-regexp-in-string.patch (application/octet-stream, attachment)]

[trawl.el (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: cpitclaudel <at> gmail.com, larsi <at> gnus.org, 36372 <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 20:09:16 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 26 Jun 2019 19:03:19 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
>         36372 <at> debbugs.gnu.org
> > For the manual, I'd expand a bit on this, and explained how to get the
> > result you thought you will when using non-nil START (by concatenating
> > with the initial substring).
> 
> All right, I added a sentence to that effect.

LGTM, thanks.

Message #55 received at 36372-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Clément Pit-Claudel <cpitclaudel <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>, 36372-done <at> debbugs.gnu.org
Subject: Re: bug#36372: 27.0.50; replace-regexp-in-string skips START first
 chars in return value [PATCH]
Date: Wed, 26 Jun 2019 19:41:14 +0200

26 juni 2019 kl. 19.09 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> LGTM, thanks.

That's it then. Thanks for the review; pushed.

Previous Next

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