bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36190: 27.0.50; `put-text-property' etc. with buffer argument calls


From: Pip Cet
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@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Mon, 17 Jun 2019 11:38:38 +0000
> > Cc: 36190@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.





reply via email to

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