match-data confusion...

match-data confusion...

[David Kastrup]

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
adjust when buffer changes occur before it.

Two possible amendments: one thing would be to add the buffer itself
as a list element into match-data.  That might be an incompatible
change, however.

The second one would be to allow an optional argument to
set-match-data that specifies a buffer, so that
(set-match-data (match-data t) buffer) will set last_thing_searched
to the specified buffer again.

As it is, I will probably have to write a special purpose function in
replace.el for now that looks like
(defun replace-set-match-data (match-data)
   (if (integerp (car match-data))
     (let ((marker (make-marker)))
         (set-marker marker (car match-data))
         (set-match-data (cons marker (cdr match-data)))
         (set-marker marker nil))
     (set-match-data match-data)))

which is pretty ugly and relies on some internals to stay the way
they are now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: match-data confusion...

[David Kastrup]

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

Re: match-data confusion...

[Richard Stallman]

    Two possible amendments: one thing would be to add the buffer itself
    as a list element into match-data.  That might be an incompatible
    change, however.

That is the only way to really fix it, so would you like to do that?