From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 27 06:17:48 2025 Received: (at submit) by debbugs.gnu.org; 27 Apr 2025 10:17:49 +0000 Received: from localhost ([127.0.0.1]:39356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8z52-0006bo-Iv for submit@debbugs.gnu.org; Sun, 27 Apr 2025 06:17:48 -0400 Received: from lists.gnu.org ([2001:470:142::17]:47470) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u8z4z-0006bY-FB for submit@debbugs.gnu.org; Sun, 27 Apr 2025 06:17:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u8z4r-0005TA-KR for bug-gnu-emacs@gnu.org; Sun, 27 Apr 2025 06:17:38 -0400 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u8z4q-0002FA-7t for bug-gnu-emacs@gnu.org; Sun, 27 Apr 2025 06:17:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1745749055; bh=WO6qu+tDUuXaqZ69oP5NuIMVxbkXDgYxVhhw0vnBSQo=; h=From:To:Subject:Date:From; b=bn/84xowcfkGANz+Y2pfKMDma6xpB8xAKkwcwMEtus/kAJKP851czBSELFEHyF5BZ rhzAdcTtpb/IpvIKKIdJbcDORrOxv43YrKB2YVtK7eQKX3c372f2PrJur9VSEC6C4S BBkNel0NMpoCzp7Ofkjiupt7jAgDsbd2Xi/NHr/z7aZmglj3LDXOzRRUvvh2+BoqXL mxswbqEC3EzueJTVuwFKgPGFIBW2tWgX84Qg/BJ5F+1Ck65FFkfYixP5ne5P1/mhJE zCShtZbi5myhkxQ0Qkb3ptMXg9ayppmTDfGNoIyuKotlc2J0MIH5Jx1ymZHkTlWmY+ yhrmdjY3ujLkg== From: Eshel Yaron To: bug-gnu-emacs@gnu.org Subject: 31.0.50; [FR] Add hook for reacting to buffer trust changes X-Debbugs-Cc: Stefan Monnier Date: Sun, 27 Apr 2025 12:17:32 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hi, It'd be great to have a hook executed when a buffer becomes (un)trusted. For example, that'd allow us to enable a previously disabled elisp-flymake-byte-compile when users mark a buffer as trusted. WDYT? (One way to do that, which I'm experimenting with in my Emacs branch, is to hide trusted-content behind API functions that take care to run such a hook for buffers that may be affected by changes to trust settings.) Thanks, Eshel From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 27 07:03:16 2025 Received: (at 78087) by debbugs.gnu.org; 27 Apr 2025 11:03:16 +0000 Received: from localhost ([127.0.0.1]:39622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8zn1-00015C-M8 for submit@debbugs.gnu.org; Sun, 27 Apr 2025 07:03:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60006) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u8zmz-00014t-Cd for 78087@debbugs.gnu.org; Sun, 27 Apr 2025 07:03:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u8zmt-00071u-Nl; Sun, 27 Apr 2025 07:03:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zTcAA7pQQus/7BCWelZDgDLuPuNqogSVLqxaRENWN9s=; b=gDZqgh8l7PYI X1u9Ny9mvhDSld3fD/QXJZUzjNOkwcllm3KYAP0v9azt7tt87FwtWGZCGGVATyDkbxy2HIEjLKszT fks38dNlzh0o1wJgse+R+NNjaHd3exEbr4RMtiKiH3DY/8nR5x3uzq34i5yhijc9Gr3x3oHH4Cp0a Ydc1KikX4MbpCd+pD4kOaRbBn8xNMQgxgPcO5ggBbjFwvUNENe9bOHwh8YOsT4MHsTN/pNS68j0qI 7rmtcEZOOia2QE7ciWqpYm7QKossFfeVWnFb9zKY48jAZ4mQ0kDroPDT5g4j5/GqWL8r3vzE72geF gg5Xum3LlqTKcSvn0cO1Lg==; Date: Sun, 27 Apr 2025 14:03:04 +0300 Message-Id: <86y0vlrhnb.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#78087: 31.0.50; [FR] Add hook for reacting to buffer trust changes References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78087 Cc: monnier@iro.umontreal.ca, 78087@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Stefan Monnier > Date: Sun, 27 Apr 2025 12:17:32 +0200 > From: Eshel Yaron via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > It'd be great to have a hook executed when a buffer becomes (un)trusted. > For example, that'd allow us to enable a previously disabled > elisp-flymake-byte-compile when users mark a buffer as trusted. WDYT? You should be able to use variable-watcher for that, I think. The function invoked when the value changes could then call the hook, if the conditions for that are satisfied. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 27 10:37:41 2025 Received: (at 78087) by debbugs.gnu.org; 27 Apr 2025 14:37:41 +0000 Received: from localhost ([127.0.0.1]:43251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u938X-0004wk-BB for submit@debbugs.gnu.org; Sun, 27 Apr 2025 10:37:41 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:42252 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u938T-0004wI-Th for 78087@debbugs.gnu.org; Sun, 27 Apr 2025 10:37:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1745764657; bh=gJJ09a2bk17SaDCh3x4glQ7LZzNuFetJ7qCRjL1Osu0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tRIdBkNJ6qp8h+cD3K+ML1Y2dshTyhdqyY7EgNwGKQftUKGtCqjxwk/37jP/lcBAu eNTPwRldUa5D9ksa00LJx+LsaL7jZ50tRD7Lrupw4Ptc0ZqLY4l9thMf63y/fBsJkJ kqd3yGPYVH1i5zdc3ySaiEBczhnOz+Mbi/d8GQYHRm6sMnn0F0UPynctV/iaZ6q4F6 sGjywGpN4Rhc1/y44Cd/zYx4+XhafXNIs2+bVzNZAkGXgnKyJ0ylO1Cq3GHTI6BTqe 5yxvEcTykJJcxdbljQw0GwAlhqbk15l8t0c+hVQ+OPN6J5AXE4ymj+MLGXhDrB4fYo f5XXfE6Dq5taQ== From: Eshel Yaron To: Eli Zaretskii Subject: Re: bug#78087: 31.0.50; [FR] Add hook for reacting to buffer trust changes In-Reply-To: <86y0vlrhnb.fsf@gnu.org> References: <86y0vlrhnb.fsf@gnu.org> Date: Sun, 27 Apr 2025 16:37:34 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78087 Cc: monnier@iro.umontreal.ca, 78087@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eli, Eli Zaretskii writes: >> Cc: Stefan Monnier >> Date: Sun, 27 Apr 2025 12:17:32 +0200 >> From: Eshel Yaron via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> It'd be great to have a hook executed when a buffer becomes (un)trusted. >> For example, that'd allow us to enable a previously disabled >> elisp-flymake-byte-compile when users mark a buffer as trusted. WDYT? > > You should be able to use variable-watcher for that, I think. The > function invoked when the value changes could then call the hook, if > the conditions for that are satisfied. Thanks, I think something like that could work, although it'd be a bit of a hassle to figure out which buffers are affected by an arbitrary change to trusted-content... We'd basically need to compare the old value with the new value and see which file names were added/deleted, which might get quite slow in some cases, for example if we're adding one file name to an existing long list. Another concern is that trusted-content-p does not rely on one variable, but on four, and a change in each of these four can change the result of subsequent trusted-content-p calls. Namely, the relevant variables are trusted-content, untrusted-content, user-init-file and buffer-file-truename. Maybe it's OK not to cover all of these variables, though. Alternatively we can add new (un)trust-buffer/file/directory functions, which would modify trusted-content and run a hook for affected buffers. These functions wouldn't have to puzzle out what changed since they'd be making the change, and we could recommend using them instead of setting trusted-content directly. Eshel From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 27 15:15:50 2025 Received: (at 78087) by debbugs.gnu.org; 27 Apr 2025 19:15:50 +0000 Received: from localhost ([127.0.0.1]:44653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u97Th-0005sJ-QK for submit@debbugs.gnu.org; Sun, 27 Apr 2025 15:15:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38024) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u97Te-0005ru-S3 for 78087@debbugs.gnu.org; Sun, 27 Apr 2025 15:15:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u97TX-00023F-8h; Sun, 27 Apr 2025 15:15:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6vahyK7BTH4LzAP3He82kkU+20a6247tVHp6g4M5DM4=; b=EJdeHslOZSo4 CSVeUIP0LvOMRbFG3G0c3FAQU+0EE9dbsj4UZNVu6ejkPLU4TFcCl1LKF4MP9gi2k0fatWOVvBa56 kknAqem21mkUizke054Bl154COPB3D3gqZz91aMjoDtQh0u65K07nYrOXF9UkFXofFwcQpMMGHOvB pxkuyRZuBQtLgHD2AhTEP+vIyAvN3ebWbvaEaeDNQh4vN2IhvzA909uoFGl5mt/lsxRoyAh6Ec1fz OinnpEEU0szZ0yKVgLmJD38LaB3bXtmB26l37tEYVK2mP24kf4vxfarmjUVatFPkH+7l52ZS+9VwB dUEg8m3qL9OH/TEnvP+RKg==; Date: Sun, 27 Apr 2025 22:15:34 +0300 Message-Id: <86plgxquuh.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (message from Eshel Yaron on Sun, 27 Apr 2025 16:37:34 +0200) Subject: Re: bug#78087: 31.0.50; [FR] Add hook for reacting to buffer trust changes References: <86y0vlrhnb.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78087 Cc: monnier@iro.umontreal.ca, 78087@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eshel Yaron > Cc: 78087@debbugs.gnu.org, monnier@iro.umontreal.ca > Date: Sun, 27 Apr 2025 16:37:34 +0200 > > Eli Zaretskii writes: > > > You should be able to use variable-watcher for that, I think. The > > function invoked when the value changes could then call the hook, if > > the conditions for that are satisfied. > > Thanks, I think something like that could work, although it'd be a bit > of a hassle to figure out which buffers are affected by an arbitrary > change to trusted-content... We'd basically need to compare the old > value with the new value and see which file names were added/deleted, > which might get quite slow in some cases, for example if we're adding > one file name to an existing long list. > > Another concern is that trusted-content-p does not rely on one variable, > but on four, and a change in each of these four can change the result of > subsequent trusted-content-p calls. Namely, the relevant variables are > trusted-content, untrusted-content, user-init-file and buffer-file-truename. > Maybe it's OK not to cover all of these variables, though. The upside is that we do that once, and we have the solution forever after. > Alternatively we can add new (un)trust-buffer/file/directory functions, > which would modify trusted-content and run a hook for affected buffers. > These functions wouldn't have to puzzle out what changed since they'd be > making the change, and we could recommend using them instead of setting > trusted-content directly. trusted-content is a user option. It is un-Emacsy to get in the way of users customizing user options. We could add a setter to the option (which means users will have to use setopt instead of setq), but that's about all.