replace.el changes...

replace.el changes...

[David Kastrup]

Hi,

I m trying to get consistent behavior into replace.el.  One thing
that currently is inconsistent is the following:

You can use ^ to revisit previous replacements whether or not you did
actually perform the replacement.  When you do a replacement without
going on, the replaced region is highlighted.  When you go backwards
in the list, the highlighting does not move backward as well, unless
you are actually doing replacements.

If a replacement has already been done, the stored information in the
history does not contain the highlighted region.  So I am going to
have to either change the history information format, or don't enter
actually performed replacements into that list for revisiting in the
first place, or don't highlight things when going backwards in the
list.  Incidentally, the history is also the return value from all
replacement commands: anybody know whether this is actually used
anywhere?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: replace.el changes...

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> If a replacement has already been done, the stored information in the
> history does not contain the highlighted region.  So I am going to
> have to either change the history information format, or don't enter
> actually performed replacements into that list for revisiting in the
> first place, or don't highlight things when going backwards in the
> list.  Incidentally, the history is also the return value from all
> replacement commands: anybody know whether this is actually used
> anywhere?

I don't know where it is used, but I think it's better not to change
the format of the return value.  You could remove your additional fields
from the history before returning it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: replace.el changes...

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> > If a replacement has already been done, the stored information in the
> > history does not contain the highlighted region.  So I am going to
> > have to either change the history information format, or don't enter
> > actually performed replacements into that list for revisiting in the
> > first place, or don't highlight things when going backwards in the
> > list.  Incidentally, the history is also the return value from all
> > replacement commands: anybody know whether this is actually used
> > anywhere?
> 
> I don't know where it is used, but I think it's better not to change
> the format of the return value.

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).  AFAICS, the return value
from perform-replace is actually used nowhere within Emacs directly
_except_ for incidentally also being the return value of all
replacement-related functions.  Searching for uses of all of them
would be work...

> You could remove your additional fields from the history before
> returning it.

Sounds like overkill for something that is not even documented to be
useful.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: replace.el changes...

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> Juri Linkov <juri@jurta.org> writes:
>> You could remove your additional fields from the history before
>> returning it.
>
> Sounds like overkill for something that is not even documented to be
> useful.

Perhaps no need to worry if you put additional elements into the end
of every history item list.  This is quite safe for backward compatibility.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: replace.el changes...

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> > Juri Linkov <juri@jurta.org> writes:
> >> You could remove your additional fields from the history before
> >> returning it.
> >
> > Sounds like overkill for something that is not even documented to be
> > useful.
> 
> Perhaps no need to worry if you put additional elements into the end
> of every history item list.  This is quite safe for backward
> compatibility.

Unfortunately, the match-data is not the last element of the list,
but the cdr of the list.  So there are no "additional elements" you
could tack on.

Anyway, I am restructuring the data.  I still have one thing to get
a grip about, however: it is my impression that replace-match is
supposed to change the match-data according to what it replaces.  But
it does not seem like (match-end 0) is affected.  I have to dig
through the code to get a hang what happens and is supposed to
happen, and whether "fixing" it to make it do what I think it is
supposed to do could cause trouble.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: replace.el changes...

[Richard Stallman]

    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?  Where is it documented?

    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.

Re: replace.el changes...

[David Kastrup]

Richard Stallman <rms@gnu.org> 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

Re: replace.el changes...

[Richard Stallman]

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

That is internal data; you can change it however you like.