From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Lisp primitives and their calling of the change hooks
Date: Thu, 4 Jan 2018 21:11:54 +0000 [thread overview]
Message-ID: <20180104211154.GC6846@ACM> (raw)
In-Reply-To: <jwvwp0x7b44.fsf-monnier+emacs@gnu.org>
Hello, Stefan.
On Thu, Jan 04, 2018 at 13:16:23 -0500, Stefan Monnier wrote:
> As mentioned, I'd consider that [insert-file-contents not calling
> b-c-f] as a bug.
> > insert-file-contents, in circumstances explored in
> > summer 2016, invokes only a-c-f, not b-c-f.
> And indeed, I considered it a bug and AFAIK this is now fixed.
Hey! It is indeed fixed. Thanks! I didn't know that.
[ .... ]
> > I would be surprised indeed if there weren't others, too.
> I would too.
> > However, we could improve the documentation of this situation in the
> > elisp manual.
> We currently say:
> 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.
> which is lax enough that any behavior could be argued to be acceptable.
> IOW I think it's too lax. We should probably try and fix it to reflect
> the fact that every change should be covered by the last preceding b-c-f
> and should be followed by a corresponding call to a-c-f (and this
> before the next call to b-c-f).
Is that quite right? The upcase-region call in my test had no a-c-f
call, almost certainly because there were no lower case letters in the
buffer at the time. From your answers in this thread, I'm thinking that
every primitive-call which could change the buffer will have exactly one
b-c-f and zero or more a-c-f's.
How about something like this to replace that paragraph from the elisp
manual?
The primitives which atomically insert or delete a contiguous chunk
of text into or from a buffer will call `before-change-functions'
and `after-change-functions' in balanced pairs, once for each
change. The arguments to these hooks will exactly delimit the
change being made. Calls to these primitives comprise the vast bulk
of buffer changes.
Other, more complex primitives aim to call `before-change-functions'
once before making any changes, then to call
`after-change-functions' zero, one, or several times, depending on
how many individual changes the primitive makes. The `BEG' and
`END' arguments to `before-change-functions' will enclose a region
in which the individual changes are made, but won't necessarily be
the minimal such region. The `BEG', `END', and `OLD-LEN' arguments
to each successive call of `after-change-functions' will accurately
delimit the current change.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2018-01-04 21:11 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 12:45 Lisp primitives and their calling of the change hooks Alan Mackenzie
2018-01-03 21:51 ` Stefan Monnier
2018-01-04 15:51 ` Alan Mackenzie
2018-01-04 18:16 ` Stefan Monnier
2018-01-04 21:11 ` Alan Mackenzie [this message]
2018-01-04 21:36 ` Stefan Monnier
2018-01-06 15:18 ` Alan Mackenzie
2018-01-06 15:51 ` Stefan Monnier
2018-01-06 16:18 ` Eli Zaretskii
2018-01-06 19:06 ` Alan Mackenzie
2018-01-06 20:24 ` Alan Mackenzie
2018-01-07 11:36 ` Alan Mackenzie
2018-01-07 11:49 ` Eli Zaretskii
2018-01-07 12:08 ` Alan Mackenzie
2018-01-07 13:56 ` Alan Mackenzie
2018-01-07 15:21 ` [SUSPECTED SPAM] " Stefan Monnier
2018-01-07 16:47 ` Eli Zaretskii
2018-01-07 17:50 ` Stefan Monnier
2018-01-07 17:58 ` Eli Zaretskii
2018-01-07 19:04 ` Stefan Monnier
2018-01-07 19:48 ` Alan Mackenzie
2018-01-07 19:58 ` Eli Zaretskii
2018-01-07 21:10 ` Alan Mackenzie
2018-01-08 3:41 ` Eli Zaretskii
2018-01-08 19:24 ` Alan Mackenzie
2018-01-08 21:15 ` Eli Zaretskii
2018-01-08 22:24 ` Stefan Monnier
2018-01-09 3:55 ` Eli Zaretskii
2018-01-09 13:30 ` Stefan Monnier
2018-01-09 18:50 ` Eli Zaretskii
2018-01-09 19:53 ` Alan Mackenzie
2018-01-09 20:05 ` Eli Zaretskii
2018-01-10 18:29 ` Alan Mackenzie
2018-01-12 16:40 ` Alan Mackenzie
2018-01-09 20:07 ` Stefan Monnier
2018-01-10 18:45 ` Alan Mackenzie
2018-01-10 19:30 ` Stefan Monnier
2018-01-10 19:48 ` Alan Mackenzie
2018-01-10 20:33 ` Stefan Monnier
2018-01-10 21:03 ` Alan Mackenzie
2018-01-11 13:36 ` Stefan Monnier
2018-01-11 17:39 ` Alan Mackenzie
2018-01-11 19:35 ` Stefan Monnier
2018-01-11 19:46 ` Alan Mackenzie
2018-01-11 20:15 ` Stefan Monnier
2018-01-11 21:20 ` Alan Mackenzie
2018-01-11 23:42 ` Stefan Monnier
2018-01-12 16:14 ` Alan Mackenzie
2018-01-10 22:06 ` Clément Pit-Claudel
2018-01-10 22:20 ` Alan Mackenzie
2018-01-08 4:29 ` Stefan Monnier
2018-01-07 17:54 ` Alan Mackenzie
2018-01-07 18:05 ` Eli Zaretskii
2018-01-05 6:55 ` Eli Zaretskii
2018-01-05 11:41 ` Alan Mackenzie
2018-01-05 13:00 ` Eli Zaretskii
2018-01-05 13:34 ` Alan Mackenzie
2018-01-05 14:08 ` Eli Zaretskii
2018-01-05 15:54 ` Alan Mackenzie
2018-01-05 16:50 ` Stefan Monnier
2018-01-05 17:38 ` Alan Mackenzie
2018-01-05 18:09 ` Stefan Monnier
2018-01-05 19:53 ` Eli Zaretskii
2018-01-05 22:28 ` Stefan Monnier
2018-01-06 9:05 ` Eli Zaretskii
2018-01-06 15:26 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180104211154.GC6846@ACM \
--to=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).