From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36190: 27.0.50; `put-text-property' etc. with buffer argument calls current buffer's `after-change-functions' Date: Fri, 14 Jun 2019 10:36:57 +0300 Message-ID: <83lfy4y5wm.fsf@gnu.org> References: <83h88tzbly.fsf@gnu.org> <835zp9z4oj.fsf@gnu.org> <83y325xnk0.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="245461"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36190@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 14 09:38:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hbgmp-0011dX-Ib for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Jun 2019 09:38:11 +0200 Original-Received: from localhost ([::1]:49072 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbgmo-0000k0-7l for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Jun 2019 03:38:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42317) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbgmh-0000jg-6j for bug-gnu-emacs@gnu.org; Fri, 14 Jun 2019 03:38:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbgmg-00075B-3d for bug-gnu-emacs@gnu.org; Fri, 14 Jun 2019 03:38:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51233) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hbgmg-000750-0N for bug-gnu-emacs@gnu.org; Fri, 14 Jun 2019 03:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hbgmf-0002nt-SR for bug-gnu-emacs@gnu.org; Fri, 14 Jun 2019 03:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jun 2019 07:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36190 X-GNU-PR-Package: emacs Original-Received: via spool by 36190-submit@debbugs.gnu.org id=B36190.156049782610698 (code B ref 36190); Fri, 14 Jun 2019 07:38:01 +0000 Original-Received: (at 36190) by debbugs.gnu.org; 14 Jun 2019 07:37:06 +0000 Original-Received: from localhost ([127.0.0.1]:36543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hbglm-0002mQ-2P for submit@debbugs.gnu.org; Fri, 14 Jun 2019 03:37:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hbglg-0002lj-TH for 36190@debbugs.gnu.org; Fri, 14 Jun 2019 03:37:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hbglb-0006WT-Nn; Fri, 14 Jun 2019 03:36:55 -0400 Original-Received: from [176.228.60.248] (port=3952 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hbgla-0001H5-UG; Fri, 14 Jun 2019 03:36:55 -0400 In-reply-to: (message from Pip Cet on Thu, 13 Jun 2019 20:57:08 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:160545 Archived-At: > From: Pip Cet > 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.