bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> I can live with that for now.
>> It's probably not much worse than
>>
>>     (add-function :override (local 'trusted-content-function) #'always)
>>
>> [ BTW, I just renamed the var to `trusted-content`.  ]
>
> I think it is not as good as a central configuration variable where I
> configure the trust for buffers or files. Now configuring trust is
> scattered across multiple major modes. My proposal was for a global hook
> variable which is consulted by `trusted-content-p' and then checks
> certain trust list for files or buffers. This way it is easier to check
> what we are trusting.

Both `trusted-content-function` and `trusted-content-functions` would be
"normal" hooks in the sense that they are neither specifically global
nor specifically local: the code that adds elements to it get to choose
whether to add it buffer-locally or globally.

For major modes, it makes a lot more sense to add elements locally,
since that avoids having to worry about the performance impact on the
rest of Emacs and things like that.

> The thought was rather that auto completion may be dangerous in general

Maybe I have too narrow a view of completion, but my impression is that
completion is usually safe.  The situation in ELisp where we perform
macro expansion to try and get the set of local variables in scope and
where that macro expansion can end up running local code is rather
unusual, AFAIK.

What kind of situation are you thinking of where completion is unsafe?

> My initial proposal was about a global `trusted-buffer-functions' hook

I don't see any reason to restrict such a hook to be global.

> but I may have not communicated this clearly enough. I have two problems
> with the buffer-local approach:

The `trusted-buffer-function` I sketched would similarly not be
restricted to be buffer-local.  IOW local/global is orthogonal to
whether we go with `trusted-buffer-functions` or
`trusted-buffer-function`.

> I just took another look at the `trusted-content-p' function on the
> emacs-30 branch:
>
> (defun trusted-content-p ()
>   (and (not untrusted-content)
>        buffer-file-truename
>        ...))
>
> There is a check for `buffer-file-truename' which means that the issue
> with non-file-backed buffers remains (Ielm or scratch). Probably (eq
> trusted-content :all) should be checked first?

Duh!  I forgot that the same change toned down the warnings, so I
didn't look at the right place when "testing".  Thanks for the heads up,
I just fixed it in `emacs-30`.

> At the same time one could consolidate the untrusted-content and
> trusted-content variables as Eshel suggested?
>
> (defun trusted-content-p ()
>   (and (not untrusted-content) ;; only for backward compat (deprecated)
>        (not (eq trusted-content :untrusted)) ;; replaces untrusted-content
>        (or (eq trusted-content :all)
>            (and buffer-file-name
>                 ...))))

I could go along with that (not for `emacs-30`, tho).
I'd prefer to get a bit more experience before deciding to do that, tho.


        Stefan