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

[Dmitry Gutov]

Hi Stefan,

On 15/12/2024 16:03, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> > Thank you for the recent addition of `trusted-content-p'. Is there a
> > possibility to use `trusted-content-p' in buffers which are not backed
> > by a file? I use Flymake in *scratch* or similar buffers and it seems
> > that this won't continue to work given that `trusted-content-p' needs a
> > `buffer-file-truename'.
>
> Good question.
> We don't really have a good answer yet, AFAIK, in large part because we
> don't have enough experience with it.
> Off the top of my head, here are some elements relevant to this
> discussion, in random order:
>
> - The current setup is a kind of "minimal" change for Emacs-30 because
>    it's late in the pretest, so as much as possible we should separate
>    the discussion into what's a simple enough solution for Emacs-30 and
>    what we should use in the longer term.

That was indeed quite abrupt, for a problem that's been with us at least 
since 2017 (the use of flymake-elisp-byte-compile in emacs-lisp-mode).

> - I think we do want some kind of hook, with which we can have (for
>    instance) `emacs-lisp-mode` tell Emacs to trust the user init file,
>    the early-init file, the custom-file, and all the files in
>    `load-path`.

Speaking of, it would be nice to see someone formulate the thread model 
we're trying to handle this way.

Indeed, should add files in load-path be considered "trusted"? If yes, 
why not do this automatically. If no, then what do we think about a 
scenario when a "trusted" file ends up loading a file from load-path 
which redefines some standard macro.