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: Stefan Monnier
Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]
Date: Thu, 18 Aug 2016 12:56:32 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

> One questionable place is insert-file-contents: it deliberately never
> calls the before-change-functions when it deletes portions of the
> text, only when it inserts text.

So, if insert-file-contents only deletes a portion of text, it doesn't
call before-change-functions at all?  That'd be a bug, yes.

> I don't really understand the reasons behind your insisting on
> before-change-functions being called before any changes in this case,

For example, because syntax-ppss uses before-change-functions to notice
when the cache needs to be flushed, and that is necessary for any
change, including deletions, and whether the deletion is performed by 
insert-file-contents or something else is mostly irrelevant.

> but maybe a simple way out would be to announce at the beginning of
> the function that the entire range between point-min and point-max is
> about to be changed, when REPLACE is non-nil.

That'd be pessimistic, but yes, it's an easy way to fix the bug, and
it'd probably be good enough.

> Another place where before-change-functions is not called, but
> after-change-functions are is set-buffer-multibyte.  Moreover, if the
> function is called with a nil argument, we don't call
> after-change-functions as well.  Is that supposed to be handled as a
> buffer change or not?

Good question.  I guess it would make sense to call b-c-f on the
whole buffer.  This said, I think we should strongly discourage use of
set-buffer-multibyte in non-empty buffers, so it's not terribly
important: in the "normal" case set-buffer-multibyte should not perform
any buffer modification anyway.

> In the low levels of encoding and decoding routines, we sometimes call
> the hooks and sometimes don't, depending on what is the source and the
> destination of the en/decoding, and whether there are pre-write or
> pre-write conversions.  But the buffer in question is a temporary
> conversion buffer, so do we care?

The temp-conversion-buffer is an internal implementation detail.
I'd rather we never call a/b-c-f in those, but it's not terribly important.

> In message_dolog, which is called by any code which logs a message in
> *Messages*, we never call the before-change-functions for the
> *Messages* buffer, but we do call the after-change-functions for it.
> Problem or not?

The *Messages* buffer is sufficiently special that I'm not worried.

> That's all I found.

Great, thank you very much.

> It intentionally refrains from saying "any and all modifications", and
> instead tries to be more vague.  Do you still think this is not good
> enough?

I think it's good enough.


        Stefan



reply via email to

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