bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45068: [PATCH] 28.0.50; Update Modus themes 1.0.2 (backward-incompat


From: Mauro Aranda
Subject: bug#45068: [PATCH] 28.0.50; Update Modus themes 1.0.2 (backward-incompatible)
Date: Tue, 02 Mar 2021 08:03:49 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.50 (gnu/linux)

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Protesilaos Stavrou <info@protesilaos.com> writes:
>
>> On 2021-03-01, 23:34 +0000, "Basil L. Contovounesios" <contovob@tcd.ie> 
>> wrote:

>>> BTW, do we need to warn anywhere that require-theme may unconditionally
>>> load files from custom-theme-load-path, or somehow protect against this?
>>
>> That would be consistent with load-theme.
>
> Right, but I'm wondering whether require-theme ought to be consistent in
> this regard.
>
> load-theme is a user-level command, and arbitrary themes are considered
> risky Lisp, so it has to (conditionally) display the code and ask the
> user if they think it looks okay.
>
> require-theme, OTOH, sounds like it's a behind-the-scenes noninteractive
> plumbing function to be used by themes themselves, so wouldn't the user
> be prompted twice if a theme called require-theme on an element of
> custom-available-themes?  IOW, it seems to me like require-theme's
> "safety" should already be handled/covered by the theme using it.

I was the one that raised the question about loading a theme via
require-theme unconditionally (Protesilaos had a NO-CONFIRM non-nil in
one of the early versions of the patch), so if that bit of the patch is
wrong I'm the one to blame.

I'll just say that I raised the question because (usually) theme files
are just settings, so for a user to check the safety it is normally
enough to go through the custom-theme-set-* functions and see what the
theme is setting.  Now the user would be asked to check a require-theme
call for its safety, and since a call to require-theme looks a lot like
require, it might not be obvious that it can load (and enable) any theme
it wants.  And if a theme uses require-theme to do that, it can "hide"
the "unsafe theme" settings, because the first element of
custom-enabled-themes will just be the "safe" theme.

Those were my reasons, feel free to ignore them if you think they make
no sense.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]