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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36190 <at> debbugs.gnu.org
Subject: bug#36190: 27.0.50; `put-text-property' etc. with buffer argument calls current buffer's `after-change-functions'
Date: Tue, 18 Jun 2019 17:14:09 +0000

On Mon, Jun 17, 2019 at 3:58 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Mon, 17 Jun 2019 11:38:38 +0000
> > Cc: 36190 <at> debbugs.gnu.org
> > > > > 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.

I've seen performance problems with overlays, and the subtle API
differences made switching, for me, difficult. You're right, though,
that this is certainly not part of this bug report, which I think the
latest patch I sent would fix for now (although I'd be happy to see it
fixed any other way, too).

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

It would almost certainly be an observable change in behavior, but I'm
testing something and it doesn't seem to fall apart entirely, at
least.

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

Thanks again for explaining, I'll think about it more.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.