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

Previous Next

Full log

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.