[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: match-data confusion...
From: |
David Kastrup |
Subject: |
Re: match-data confusion... |
Date: |
18 Jun 2004 13:42:54 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
David Kastrup <address@hidden> 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