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
Message #35 received at 74879 <at> debbugs.gnu.org (full text, mbox):
> 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.
- You should be able to get fully-featured Flymake in *scratch*
with (setq-local trusted-files :all).
Maybe we should do that when we setup *scratch*?
Which other non-file buffers would need that? The minibuffer?
- Trust sucks, so we really should work on better solutions where we
don't need to rely on trust, such as running code in `bwrap` or other
kinds of sandboxes.
- 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`.
- There is overlap with `safe-local-variable-directories`,
`enable-local-variables` and it would be nice to consolidate (which
can require delicate timing if we want the major mode to inform which
content to trust).
- Stefan
This bug report was last modified 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.