Re: replace.el changes...

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     If a replacement has already been done, the stored information in the
>     history does not contain the highlighted region.
> 
> Could you please be more explicit?  What is "the history" that you
> refer to?  Does it have a name?

`stack'.  It contains point and match-data for previous replacements
that did not yet happen (and for those that did happen, just t
instead of the match data).  You can revisit previous replacements by
using ^.

> Where is it documented?

Nowhere.  It's in the code of perform-replace, and it may be the
return value under certain conditions.  The return value is just
documented as being non-nil or nil under circumstances.  I have not
seen any use of that return value, and actually the description of
the return value is incorrect, anyway:

"This function returns nil if and only if there were no matches to
make, or the user didn't cancel the call."

Actually, the function returns nil if and only of there were no
matches to make, or the user _did_ cancel the call.

>     It is actually not documented to be useful, except as being nil or
>     non-nil.  And even then, it is only documented for perform-replace
>     itself (the internal routine doing the job).
> 
> If it is not documented, people can't complain if we change it.

Oh, of course they can't complain.  There is just a non-zero risk of
things breaking.  I could not see any direct use of the return value
of perform-replace (which is just documented as being non-nil under
certain conditions), but perform-replace is called as the last thing
in many replacement routines, so all of them return its return value,
too.

Now none of those callers actually documents _any_ return value at
all, so we get into trouble only if people actually read the code and
deduced things about it.  But I have not made a complete survey of all
uses of _callers_ of perform-replace.  I consider it highly unlikely
that there is any that would not only use the return value, but even
use details of it.  But highly unlikely is not impossible.

I judged the risk small enough that the code I posted uses a
different format of the list.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum