emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]


From: Alan Mackenzie
Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]
Date: Wed, 10 Aug 2016 15:16:22 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Stefan and Eli.

On Wed, Aug 10, 2016 at 10:56:59AM -0400, Stefan Monnier wrote:
> > AFAICT, this is what happens, indeed,

> Then the old text was right: it's called before ANY modification.

> > except that the call to before-change-functions in some cases does not
> > precede the first modification of the series.  IOW, by the time the
> > hook is called, some modifications were already done.

> Sounds like a bug.

I concur.

> In any case, my point is that the doc should still say "before any
> modification" because that's really what the code *should* do.  We could
> add a blurb in the doc saying that the before and after hooks may not be
> properly paired (neither in number of calls nor in the specific value of
> BEG/END),

You mean we should add commentary saying that BEG and END _usually_
bound the region about to be deleted, but sometimes they don't.  And
another comment saying that BEG, END, and OLD-LEN are only _usually_ set
to what they're currently documented as, the rest of the time they're
random numbers vaguely related to a change region.

That doesn't sound much better to me.

If we're going to treat the code (as opposed to the documentation) as a
bug, let's fix it completely, with rigorously paired b-c-f and a-c-f,
rather than half-heartedly.

Otherwise, let's document fully the circumstances in which
before-change-functions doesn't get called (which I don't as yet
understand), so that Lisp hackers can use that information in their
programs.

> but we should still claim that they're both called for any and
> all modifications (modulo inhibit-modification-hooks, obviously).

Given that the situation has been in place for several decades, I don't
see any urgency to fix it in 25.1.  But let's fix it properly, whatever
we decide the bug is.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]