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 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).



reply via email to

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