From: Pip Cet <pipcet@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36190@debbugs.gnu.org
Subject: bug#36190: 27.0.50; `put-text-property' etc. with buffer argument calls current buffer's `after-change-functions'
Date: Thu, 13 Jun 2019 19:42:29 +0000 [thread overview]
Message-ID: <CAOqdjBfR+A2Y224eEJKCRo5+LK7DorvT_72no8jV1YcNd1mVqw@mail.gmail.com> (raw)
In-Reply-To: <835zp9z4oj.fsf@gnu.org>
On Thu, Jun 13, 2019 at 7:06 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Thu, 13 Jun 2019 18:48:23 +0000
> > Cc: 36190@debbugs.gnu.org
> >
> > > > As far as I can tell, this makes `put-text-property' with a buffer
> > > > argument pretty useless.
> > >
> > > Only if you have a buffer-local value of after-change-functions.
> >
> > I'm not sure what you're saying.
>
> I'm saying that the buffer argument to put-text-property is pretty
> useless only if you consider after-change-functions. The primary
> purpose of put-text-property is to modify text properties, not to call
> after-change-functions. For that primary purpose, the buffer argument
> is not useless.
Thanks for clarifying. I suppose you could say that it's
after-change-functions (local, global, plus overlay modification
hooks) that have become useless, or will be called spuriously and with
potentially nonsensical arguments.
For example, this would break:
(push (lambda (beg end len)
(message "%S" (buffer-substring beg end)))
after-change-functions)
> > That seems pretty wrong to me. In which cases do you think we're
> > seeing the right behavior?
>
> Where did I say that this behavior was right?
You said "only if", so I assumed you were asserting the contrapositive.
> > Here's a first patch, which adds a "buffer" argument to
> > signal_after_change, to be explicit about where the change happens. It
> > should be pretty cheap in the case where we don't switch buffers.
>
> Not sure I have a clear idea of how you intend to use that additional
> argument. Are you suggesting that we switch to that buffer?
Yes:
@@ -2183,6 +2184,9 @@ signal_after_change (ptrdiff_t charpos,
ptrdiff_t lendel, ptrdiff_t lenins)
if (inhibit_modification_hooks)
return;
+ record_unwind_current_buffer ();
+ set_buffer_internal (buffer);
+
/* If we are deferring calls to the after-change functions
and there are no before-change functions,
just record the args that we were going to use. */
> If so,
> how is that different from not using the buffer argument at all, and
> instead wrapping the call to put-text-property with
> with-current-buffer?
I don't think they're usefully different, but put-text-property
doesn't appear to check the buffer is still live.
> Also, passing current_buffer sounds redundant to me anyway, because in
> that case signal_after_change will not need to do anything that it
> doesn't already do. I would pass NULL instead.
May I ask why? I think passing current_buffer is the clearest signal
we can send to someone reusing the code that they might have to change
this if they're dealing with more than one buffer.
As a practical matter, it's hard to change the text property functions
to use NULL when passed a nil argument, so we'd have functions using
current_buffer and others using NULL, and that seems needlessly
inconsistent.
next prev parent reply other threads:[~2019-06-13 19:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-13 13:48 bug#36190: 27.0.50; `put-text-property' etc. with buffer argument calls current buffer's `after-change-functions' Pip Cet
2019-06-13 16:36 ` Eli Zaretskii
2019-06-13 18:48 ` Pip Cet
2019-06-13 19:05 ` Eli Zaretskii
2019-06-13 19:27 ` Eli Zaretskii
2019-06-13 19:42 ` Pip Cet [this message]
2019-06-13 20:01 ` Eli Zaretskii
2019-06-13 20:57 ` Pip Cet
2019-06-13 21:37 ` Pip Cet
2019-06-14 7:41 ` Eli Zaretskii
2019-06-14 11:14 ` Pip Cet
2019-06-14 12:10 ` Eli Zaretskii
2019-06-15 15:14 ` Pip Cet
2019-06-15 15:23 ` Eli Zaretskii
2019-06-15 19:27 ` Pip Cet
2019-07-06 8:08 ` Eli Zaretskii
2019-07-06 15:27 ` Pip Cet
2019-07-06 16:22 ` Eli Zaretskii
2019-06-14 7:36 ` Eli Zaretskii
2019-06-17 11:38 ` Pip Cet
2019-06-17 15:59 ` Eli Zaretskii
2019-06-18 17:14 ` Pip Cet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOqdjBfR+A2Y224eEJKCRo5+LK7DorvT_72no8jV1YcNd1mVqw@mail.gmail.com \
--to=pipcet@gmail.com \
--cc=36190@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.