Re: match-data confusion...

[David Kastrup <dak@gnu.org>]

David Kastrup <dak@gnu.org> writes:

> I am having a problem with getting stuff right in replace.el.
> 
> The problem is that
> 
> (match-data t) is basically dangerous since it is lacking the
> information to restore last_thing_searched.  But that means that
> (set-match-data (match-data t)) is not a noop, even if the buffer is
> not changed in between since the restored match-data stops being
> adjusted when buffer changes occur before it.

Well, ok, so this adjustment would not happen anyway as I see from the
code, since last_thing_searched is only accessed in search.c.  Let's
put it differently:

(match-data) is not equivalent to
(progn (set-match-data (match-data t)) (match-data))

This means that I can't convert something fetched with (match-data t)
into some set of markers in the simple way.  Anyway, I see several
ways round the problem I have in replace.el:

a) ignore the problem.  That means that if people edit before point
and then perform this or a previous replacement, it will happen at
the wrong point.
b) set a read-only overlay on everything that could affect
recorded buffer positions where replacements might still occur.
c) set a modification-hook overlay on everything that could affect
such buffer positions.  When it triggers, convert all possibly
affected match-data sets into markers manually.
d) use markers in the first place for everything, but make sure to
invalidate them as soon as they are not needed anymore.

I think I tend to option d).  The reason is that the only case where
we get pending markers is that where a replacement was voted "n" by
the user, in interactive use.  But in that case, I don't think we are
being overly time-critical, anyway.

But I still think that a possibility for restoring last_thing_matched
with set-match-data even in the case that the data was extracted
using (match-data t) is warranted.
 
-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum