Subject: bug#78087: 31.0.50; [FR] Add hook for reacting to buffer trust changes

From: Eli Zaretskii <[email-masked]>
Date: Sun, 27 Apr 2025 22:15:34 +0300

> From: Eshel Yaron <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Sun, 27 Apr 2025 16:37:34 +0200
> 
> Eli Zaretskii <[email-masked]> 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.