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: Thu, 13 Jun 2019 23:01:03 +0300 Message-ID: <83y325xnk0.fsf@gnu.org> References: <83h88tzbly.fsf@gnu.org> <835zp9z4oj.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="140495"; 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 Thu Jun 13 22:02:13 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 1hbVvI-000aO1-SN for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Jun 2019 22:02:12 +0200 Original-Received: from localhost ([::1]:45402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbVvH-0000FN-Rl for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Jun 2019 16:02:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57775) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbVv9-00008z-Ou for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 16:02:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbVv8-0001l9-LZ for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 16:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50874) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hbVv8-0001l0-HQ for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 16:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hbVv8-00068S-9w for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 16:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Jun 2019 20:02:02 +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.156045607923527 (code B ref 36190); Thu, 13 Jun 2019 20:02:02 +0000 Original-Received: (at 36190) by debbugs.gnu.org; 13 Jun 2019 20:01:19 +0000 Original-Received: from localhost ([127.0.0.1]:36185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hbVuQ-00067O-4g for submit@debbugs.gnu.org; Thu, 13 Jun 2019 16:01:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hbVuK-000675-RT for 36190@debbugs.gnu.org; Thu, 13 Jun 2019 16:01:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hbVuF-0001PX-Kt; Thu, 13 Jun 2019 16:01:07 -0400 Original-Received: from [176.228.60.248] (port=1378 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hbVuB-0007d4-7f; Thu, 13 Jun 2019 16:01:07 -0400 In-reply-to: (message from Pip Cet on Thu, 13 Jun 2019 19:42:29 +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:160524 Archived-At: > From: Pip Cet > Date: Thu, 13 Jun 2019 19:42:29 +0000 > Cc: 36190@debbugs.gnu.org > > > 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); Ugh! switching buffers just to run a hook! This will kill performance in some cases. We had something similar with JSON parsing a few months ago. I wish we had a better alternative. 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. > > 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? To make the code speak for itself. With passing current_buffer, you now rely on subroutines of set_buffer_internal two or 3 levels down to test whether we are already in that buffer and do nothing. Meanwhile, you wasted cycles on 2 or 3 function calls, and forced someone who reads the code to go down that rabbit hole if they want to understand what happens in that particular case. > 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. Each function has commentary, where you can say that NULL means not to switch buffers because we are already there. That is a more clear signal, IME. > 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? > so we'd have functions using current_buffer and others using NULL, > and that seems needlessly inconsistent. Sorry, I don't see any inconsistency. We do such things (for other kinds of arguments) all over the place. It's really a matter of stylistic preferences, but you did ask why...