[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unbalanced change hooks (part 2)
From: |
Alan Mackenzie |
Subject: |
Re: Unbalanced change hooks (part 2) |
Date: |
Sun, 7 Aug 2016 21:16:27 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
Hello, Eli.
On Tue, Aug 02, 2016 at 10:25:45PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 Aug 2016 19:00:24 +0000
> > Cc: address@hidden, address@hidden, address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>
> > > > I thought we'd already agreed that no rational design would omit the
> > > > before-change-hooks call from an arbitrary subset of changes.
> > > No, I don't think there was such an agreement. The set of changes for
> > > which before-change-functions are not called is not arbitrary.
> > Would you please characterize these circumstances in a way useful for
> > people considering the use of before-change-functions. If you like, I
> > can then modify Elisp's "Change Hooks" with that information.
> Let's leave this for later, and focus on solving the immediate problem
> at hand.
You say the set of changes for which b-c-f isn't called isn't arbitrary.
That means it follows some sort of scheme. Could a major mode, in an
after-change function use this scheme to determine whether
before-change-functions was called, for some particular change? (This
won't be needed if my other idea (below) is workable.)
> > > If such an original design existed in the distant past, it was long
> > > ago (as in 20 years or more) replaced with what we basically see
> > > today, where every change always triggers a call to
> > > after-change-functions, but only some (the majority, but not all)
> > > trigger the call to before-change-functions.
> > >From the point of view of design, what is the benefit in not calling
> > b-c-f for that subset of circumstances?
> I'm not yet 100% sure, but I'm getting there. In any case, the logic
> is very clear, although its rationale I only half-understand for now.
OK.
> > > The ELisp manual doesn't promise that these hooks will be called in
> > > balanced pairs.
> > It does. before-change-functions is described as:
> > .... a list of functions to call before any buffer modification.
> > after-change-functions is likewise described as:
> > .... a list of functions to call after any buffer modification.
> > . It may not explicitly say they are paired, but it says each hook is
> > called after every modification. This naturally pairs them up.
> Like I said, sticking to such a strict interpretation would cause our
> code to be unnecessarily much too complex. The modification hooks are
> supposed to tell you that changes are about to be, or have been, made
> in a region, but that doesn't necessarily mean you will have a single
> call of before- and after- hook for each of the partial changes.
OK, things are as they are.
I currently believe that most changes trigger before-change-functions but
EVERY CHANGE triggers after-change-functions. Can you confirm that this
is the case? If it isn't, could we fix Emacs so that it is?
If it is indeed the case, then a solution to the problem would be to
check that before- and after-c-f are called alternately. Any time
after-c-f is called twice in a row, we could reverse the change just made
(using the undo list), invoke before-c-f, redo the change, then let
after-c-f continue to completion. If necessary, we can temporarily
enable undo in a pre-command-hook function. Given how rarely b-c-f isn't
called, this would have a negligible effect on performance and store
usage.
This would be a better solution than reversing and redoing every change.
It will also work for older Emacsen, and will be relatively easy to
implement. It will be much easier to implement than a solution which
doesn't use before-change-functions at all.
What do you think about this?
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], (continued)
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/10
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/18
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/18
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Alan Mackenzie, 2016/08/19
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/19
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/19
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/19
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/19
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/02
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/02
- Re: Unbalanced change hooks (part 2),
Alan Mackenzie <=
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/08
- Re: Unbalanced change hooks (part 2), Stefan Monnier, 2016/08/08
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/08
Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/09
Re: Unbalanced change hooks (part 2), Phillip Lord, 2016/08/19