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: Thu, 13 Jun 2019 20:57:08 +0000
> Cc: 36190@debbugs.gnu.org
> 
> > > +  record_unwind_current_buffer ();
> > > +  set_buffer_internal (buffer);
> >
> > Ugh! switching buffers just to run a hook!  This will kill
> >  performance in some cases.
> 
> I really don't think it will have a noticeable impact on performance,
> but if you can think of a scenario, we could try to fix it.

Switching buffers means rebinding values of all the buffer-local
variables, of which there could be quite a few.  Or am I missing
something?

One scenario where this could be painful could be reading a stream of
data that results in many changes in text properties, such as
fontifying a buffer of program source by using syntactical analysis
data received from a language server.  If you read and apply the input
one object at a time, this will result in many buffer switches.

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

> >  Maybe we should warn
> > in the documentation that calling these functions with BUFFER being
> > other than the current buffer might hurt performance when
> > after-change-functions is non-nil.
> 
> It'll hurt performance even when after-change-functions is nil, so
> such a warning would be overspecific.

We could avoid switching buffers if the hook is nil, at least in
principle.  If not, it's even worse than I feared.

> > > As a practical matter, it's hard to change the text property functions
> > > to use NULL when passed a nil argument
> >
> > How is it harder than passing current_buffer?
> 
> The code path goes through
> 
>   if (NILP (object))
>     XSETBUFFER (object, current_buffer);

I meant in the cases where you pass the literal current_buffer.

But even the above is not a problem:

  struct buffer *b;
  if (NILP (object))
    {
      XSETBUFFER (object, current_buffer);
      b = NULL;
    }
  else if (BUFFERP (object))
    b = XBUFFER (object);
  [...]
  signal_after_change (b, ...);

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