GNU bug report logs - #78087
31.0.50; [FR] Add hook for reacting to buffer trust changes

Previous Next

To reply to this bug, email your comments to 78087 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; [FR] Add hook for reacting to buffer trust changes
Date: Sun, 27 Apr 2025 12:17:32 +0200

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

Message #8 received at 78087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: monnier <at> iro.umontreal.ca, 78087 <at> debbugs.gnu.org
Subject: Re: bug#78087: 31.0.50;
 [FR] Add hook for reacting to buffer trust changes
Date: Sun, 27 Apr 2025 14:03:04 +0300

> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
> 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" <bug-gnu-emacs <at> gnu.org>
> 
> 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.

Message #11 received at 78087 <at> debbugs.gnu.org (full text, mbox):

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 78087 <at> debbugs.gnu.org
Subject: Re: bug#78087: 31.0.50; [FR] Add hook for reacting to buffer trust
 changes
Date: Sun, 27 Apr 2025 16:37:34 +0200

Hi Eli,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> 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" <bug-gnu-emacs <at> gnu.org>
>> 
>> 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

Message #14 received at 78087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: monnier <at> iro.umontreal.ca, 78087 <at> debbugs.gnu.org
Subject: Re: bug#78087: 31.0.50; [FR] Add hook for reacting to buffer trust
 changes
Date: Sun, 27 Apr 2025 22:15:34 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 78087 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Sun, 27 Apr 2025 16:37:34 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.