[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 18:57:35 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
Hello, Eli.
On Wed, Aug 10, 2016 at 07:54:36PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 Aug 2016 16:18:21 +0000
> > Cc: Stefan Monnier <address@hidden>, address@hidden
> > From: Alan Mackenzie <address@hidden>
> > > > Then the old text was right: it's called before ANY modification.
> > > Convince Alan, and I will change it back.
> > For what it's worth, I don't like the vagueness of the doc as it
> > currently is, and I wouldn't be against changing it back _FOR 25.1_
> > We've got a bug, but it's not urgent enough to have to be fixed for
> > 25.1.
> I made further adjustments to the text. It is now closer to what it
> was before, but I don't feel it's wise for it to be as definitive as
> it was originally, as someone will surely interpret that too literally
> and file another bug report, or design a feature based on incorrect
> assumptions.
#########################################################################
Do @emph{not} expect the before-change hooks and the after-change
hooks be called in balanced pairs around each buffer change. Also
don't expect the before-change hooks to be called for every chunk of
text Emacs is about to delete. These hooks are provided on the
assumption that Lisp programs will use either before- or the
after-change hooks, but not both, and the boundaries of the region
where the changes happen might include more than just the actual
changed text, or even lump together several changes done piecemeal.
#########################################################################
I don't like that text at all. For what it's worth, I find it
objectionable in the extreme. It's not even true. One can (indeed,
often MUST) expect b-c-f and a-c-f to work in pairs, and it is only on
the rarest of occasions that they do not - it's taken ~10 years for this
bug to show up.
Editing text involves deletions and insertions. Deletions can be known
only in before-change-functions, insertions only in
after-change-functions. What you are proposing is partitioning Elisp
programs into those that know only deletions, and those that know only
insertions. Any program using syntax-ppss would by that principle be
debarred from using a-c-f, since s-ppss uses b-c-f. This is absurd.
If you insist on this strand of documentation (which is surely
controversial enough not to be allowed into Emacs 25.1 at this late
stage) then please provide a function called something like `old-text'
which an after-change function could use to recover deleted text.
CC Mode absolutely requires to know both deletions and insertions for
its proper functioning. Nobody has yet demonstrated that it can work
properly knowing only insertions, despite Stefan loudly and repeatedly
proclaiming it can.
Must I look forward to a bug report from some busybody moaning that CC
Mode "illegitimately" uses both change hooks?
OK, I've complained enough, so I ought to suggest something positive.
Here is what I would put into the documentation in place of that
paragraph. I think it is accurate and reasonable.
#########################################################################
Normally the before-change-functions and the after-change-functions
hooks are called in balanced pairs around each buffer change, enabling
state to be determined in a before-change function and used in an
after-change function. However on rare occasions,
before-change-functions is not called before a buffer change and
after-change-functions is thus called twice in succession. Your
program should be ready to deal with such an occurrence.
#########################################################################
[ .... ]
> Thanks.
--
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/09
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/10
- 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], Alan Mackenzie, 2016/08/10
- 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/10
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Alan Mackenzie, 2016/08/10
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/10
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Alan Mackenzie, 2016/08/10
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/10
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining],
Alan Mackenzie <=
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/10
- 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], Alan Mackenzie, 2016/08/11
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/11
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Daniel Colascione, 2016/08/28
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/28
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Daniel Colascione, 2016/08/28
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/28
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Daniel Colascione, 2016/08/28
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/28