GNU bug report logs -
#74879
30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 55 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.