bug#36190: 27.0.50; `put-text-property' etc. with buffer argument calls current buffer's `after-change-functions'

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Mon, 17 Jun 2019 11:38:38 +0000
> Cc: 36190@debbugs.gnu.org
> 
> > Switching buffers means rebinding values of all the buffer-local
> > variables, of which there could be quite a few.  Or am I missing
> > something?
> 
> I just don't see how the requirement to switch buffers for modifying
> text properties is so different, performance-wise, from the case of
> modifying buffer text; in the latter case, we simply accept we can do
> so only for the current buffer.

It isn't different.  It's just that (a) modifying another buffer's
text is relatively rare, and (b) this is one more such switch.

> In any case, the current code already switches buffers, it's just a
> question of doing so twice rather than once.

Yes.  IOW, we get hit by that one more time.

> > > > I wish we had a better alternative.
> > >
> > > (Such as not calling regular modification hooks for text property changes?)
> >
> > I thought about that, but I don't think this would be acceptable.
> 
> It's certainly not something to be done on the spur of the moment, but
> it is something I feel Emacs did wrongly, perhaps because XEmacs did
> things differently, if I understand correctly. I'm not sure I'm aware
> of even a single place where text properties are used for something
> that's integrally part of buffer text.

I don't think this i a part of the problem: applications that don't
want the side effects of text properties can use overlays instead.

> when someone has time to test things properly, is to rewrite all
> buffer-modifying functions to look like this:
> 
>   Lisp_Object hooks = run_before_change_hooks (...);
>   modify_buffer ();
>   run_after_change_hooks (hooks, ...);

I think that'd be a welcome refactoring, if indeed this paradigm
doesn't break in some subtle use case (Emacs internals are frequently
like that).

> >   struct buffer *b;
> >   if (NILP (object))
> >     {
> >       XSETBUFFER (object, current_buffer);
> >       b = NULL;
> >     }
> >   else if (BUFFERP (object))
> >     b = XBUFFER (object);
> >   [...]
> >   signal_after_change (b, ...);
> 
> I find the above much less readable than the current version, I must say.

I guess we will have to disagree then, because this is boilerplate C
ion Emacs sources.

> > > It was out of genuine interest, because passing NULL to implicitly
> > > specify a default argument is something that people advocate against,
> >
> > Not to specify the default, but to indicate that no action is needed
> > at all wrt the buffer.  It is similar to the last argument to
> > 'strtol', for example.
> 
> The `base' argument, you mean?

Sorry, meant the penultimate argument, ENDPTR.