From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet 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: Mon, 17 Jun 2019 11:38:38 +0000 Message-ID: References: <83h88tzbly.fsf@gnu.org> <835zp9z4oj.fsf@gnu.org> <83y325xnk0.fsf@gnu.org> <83lfy4y5wm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="269163"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36190@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 17 13:55:41 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 1hcqEf-0017uG-49 for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Jun 2019 13:55:41 +0200 Original-Received: from localhost ([::1]:46342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcqEd-0004jg-OK for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Jun 2019 07:55:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55456) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcpzd-0004No-D3 for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2019 07:40:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hcpzZ-00049v-OS for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2019 07:40:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56775) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hcpzW-00047j-D7 for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2019 07:40:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hcpzW-0000cF-7Y for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2019 07:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Jun 2019 11:40: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.15607715652321 (code B ref 36190); Mon, 17 Jun 2019 11:40:02 +0000 Original-Received: (at 36190) by debbugs.gnu.org; 17 Jun 2019 11:39:25 +0000 Original-Received: from localhost ([127.0.0.1]:42086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hcpyv-0000bN-A2 for submit@debbugs.gnu.org; Mon, 17 Jun 2019 07:39:25 -0400 Original-Received: from mail-oi1-f180.google.com ([209.85.167.180]:40226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hcpyu-0000bA-4h for 36190@debbugs.gnu.org; Mon, 17 Jun 2019 07:39:24 -0400 Original-Received: by mail-oi1-f180.google.com with SMTP id w196so6746678oie.7 for <36190@debbugs.gnu.org>; Mon, 17 Jun 2019 04:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MwWvFtNcBRotd/UvMFwS3ti3cOIZcFtdi0gQK9Hwops=; b=pJANJQrGSwp8P1Hlb0jMuOEbgyBBZb/8GMtstrCZo8SSmZZYF6p/4I3teyNTK5vHSw 9GWsmPDRNZT8z29Wr2VRUUxdMGlb1E6MTtEmCwnfgrZUptV8tz8EYtxZBagrhtdGpa7O aLU6pQFiTKd6e/ixAo8QWJVwWq5/9+ICil6mk5h90fJr4W9wqsQ+FFVIiVl84o7jOzDi Os2b01tJ86tQvQcn8d2+YoilG1xykM335RjmBkrfemE7a3kF+N9Mar7XqMzm6tL1f0Qo ovDyEqZFw2uPYYhtlpNp+HmBfUHMhO/8UYF2jwQlvddx9qer0Tv0rWP5UCLwN8cRu11z 9x3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MwWvFtNcBRotd/UvMFwS3ti3cOIZcFtdi0gQK9Hwops=; b=TUB2L/1uDJbCy2BSL8zIXvLe50bEkMTogB9j+jgG3K5v8uxlpiRgj6879bHSFMmdov vUMWb33qJO340ryaHIvtRMdO539Jw5diFx5FM5m5LO9VkJxQWeShmd8PXkaDuGBL3hlG bD/37AF/nlULj7u/OjTRwqkqjQVfrzjSDi7dVcNR00Ouh4+LGBXPF0T2ueVEXfQvFpB9 CSHJEy7+zdsXbquPSuLgsTD/AeEg4yKfq90zq+oe8Y1HAZ2q7kLKyhS5URHw4yuhAIUR u/caC48xOqLRIXnRQtplEO7w6MU2tDPjNvZVVn0zyswZJc314bKpXa9eaPsAyaoIJHit mpOA== X-Gm-Message-State: APjAAAX5nmGFQ0ZlGbJgtyQHvvqamaE88kbVDXZPnBeh+AwlOizSXrh/ MAet6drJ/ev/RZhEIlXEXi4jfMKxYBOwH+UhIh8= X-Google-Smtp-Source: APXvYqzdSOOTHAk+fmJDiZKug/qcARHorspcCFH6UHd9Nl7Lvo0lz3fitNszQ7J9vpJ+fU/wwdaKQbbc2UKT0fsduTk= X-Received: by 2002:aca:aa93:: with SMTP id t141mr10428712oie.128.1560771557519; Mon, 17 Jun 2019 04:39:17 -0700 (PDT) In-Reply-To: <83lfy4y5wm.fsf@gnu.org> 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:160725 Archived-At: On Fri, Jun 14, 2019 at 7:36 AM Eli Zaretskii wrote: > > 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? I just don't see how the requirement to switch buffers for modifying text properties is so different, performance-wise, from the case of modifying buffer text; in the latter case, we simply accept we can do so only for the current buffer. In any case, the current code already switches buffers, it's just a question of doing so twice rather than once. > 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. Yes, I agree. However, half of those buffer switches are probably because the language server output would be directed into a buffer; you could avoid those using a filter function, I suppose. > > > 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. > > > 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. We could. I've looked at the code and I think the right thing to do, 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, ...); where run_before_change_hooks runs the before-change hooks but collects the modification hooks to be run after the modification in the same iteration. Right now, we're using global variables to achieve something similar, but, among other problems, that means modification hooks aren't reentrant. Modifying buffer B from buffer A's modification hooks sounds like it should be safe to me even when B has modification hooks, but it isn't. (In fact, I don't see why inhibit-modification-hooks isn't buffer-local). > > > > 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, ...); I find the above much less readable than the current version, I must say. > > 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? If that's what you're saying, I agree that using 0 as a short-hand for "use implicit base" is an odd decision for C to have made, but I'm not sure I see the similarity to the current argument.