GNU bug report logs -
#22466
25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
Previous Next
To reply to this bug, email your comments to 22466 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 11:04:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Artur Malabarba <bruce.connor.am <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 26 Jan 2016 11:04:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
1. From “emacs -Q” evaluate `(load-theme 'tango-dark)'. Any other theme
with a dark background will also do.
2. Then, notice how every time you evaluate the following code, the
screen flashes white for a moment, and then resumes the exact same
appearance.
(progn (disable-theme 'tango-dark)
(load-theme 'tango-dark))
Of course, “resuming the same appearance” is expected, the problem is
that the white flash is distracting, unnecessary, and eye-hurting.
I understand _why_ it happens (after `disable-theme' the background is
actually white), but I don't see why it _has_ to happen. That is, why
does Emacs redisplay the frame in the middle of lisp evaluation, instead
of waiting until the end of the command loop?
More importantly, is this redisplay (or “partial redisplay”, or whatever
it is) be avoided, so Emacs doesn't flash white on my pretty little eyes?
-----
ps: In case it helps, investigation shows that this is caused by this
form inside `disable-theme':
(set-frame-parameter frame 'background-color
(custom--frame-color-default
frame :background "background" "Background"
"unspecified-bg" "white"))
I'm not saying this form is wrong. I'm just pointing to where it happens.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 14:59:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> From: Artur Malabarba <bruce.connor.am <at> gmail.com>
> Date: Tue, 26 Jan 2016 09:02:29 +0000
>
>
> 1. From “emacs -Q” evaluate `(load-theme 'tango-dark)'. Any other theme
> with a dark background will also do.
>
> 2. Then, notice how every time you evaluate the following code, the
> screen flashes white for a moment, and then resumes the exact same
> appearance.
>
> (progn (disable-theme 'tango-dark)
> (load-theme 'tango-dark))
>
> Of course, “resuming the same appearance” is expected, the problem is
> that the white flash is distracting, unnecessary, and eye-hurting.
>
> I understand _why_ it happens (after `disable-theme' the background is
> actually white), but I don't see why it _has_ to happen. That is, why
> does Emacs redisplay the frame in the middle of lisp evaluation, instead
> of waiting until the end of the command loop?
It's not redisplay that does this. It's the fact that disable-theme
changes the frame's background color, and when that happens, we
immediately clear the frame using the new background color, as part of
the modify-frame-parameters call.
Redisplay only handles the portions of display where there's text and
other decorations that we manage. Clearing the frame with the new
background color is not redisplay's job.
> More importantly, is this redisplay (or “partial redisplay”, or whatever
> it is) be avoided, so Emacs doesn't flash white on my pretty little eyes?
>
> -----
>
> ps: In case it helps, investigation shows that this is caused by this
> form inside `disable-theme':
>
> (set-frame-parameter frame 'background-color
> (custom--frame-color-default
> frame :background "background" "Background"
> "unspecified-bg" "white"))
>
> I'm not saying this form is wrong. I'm just pointing to where it happens.
What happens if you remove that from disable-theme? (I don't really
understand why it has to specify "white".)
Anyway, how come you get to doing this so often it hurts your eyes?
Aren't people setting their beloved theme once when the session
starts, and then never change it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 16:38:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> Anyway, how come you get to doing this so often it hurts your eyes?
> Aren't people setting their beloved theme once when the session
> starts, and then never change it?
I can't speak for the OP, but no, users can well want to cycle
through a set of themes before choosing one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 17:03:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 26 Jan 2016 08:36:56 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 22466 <at> debbugs.gnu.org
>
> > Anyway, how come you get to doing this so often it hurts your eyes?
> > Aren't people setting their beloved theme once when the session
> > starts, and then never change it?
>
> I can't speak for the OP, but no, users can well want to cycle
> through a set of themes before choosing one.
Yes, once. Until they choose that one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 17:08:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> > > Anyway, how come you get to doing this so often it hurts your eyes?
> > > Aren't people setting their beloved theme once when the session
> > > starts, and then never change it?
> >
> > I can't speak for the OP, but no, users can well want to cycle
> > through a set of themes before choosing one.
>
> Yes, once. Until they choose that one.
But they might do this over and over, in different contexts.
Anyway, I've made the point. Up to you whether it matters.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 18:42:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 22466 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Tue, 26 Jan 2016 08:36:56 -0800 (PST)
>> From: Drew Adams <drew.adams <at> oracle.com>
>> Cc: 22466 <at> debbugs.gnu.org
>>
>> > Anyway, how come you get to doing this so often it hurts your eyes?
>> > Aren't people setting their beloved theme once when the session
>> > starts, and then never change it?
>>
>> I can't speak for the OP, but no, users can well want to cycle
>> through a set of themes before choosing one.
>
> Yes, once. Until they choose that one.
On my todo list there is also writing tramp-theme.el. Something, which
makes it obvious that you are editing a remote file, or not. Even more
important: you are editing a file as root, or not.
This could fall into the category of enabling-disabling the theme more
often than just at the start of your session.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 18:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Drew Adams <drew.adams <at> oracle.com>, 22466 <at> debbugs.gnu.org, bruce.connor.am <at> gmail.com
> Date: Tue, 26 Jan 2016 19:41:18 +0100
>
> On my todo list there is also writing tramp-theme.el. Something, which
> makes it obvious that you are editing a remote file, or not. Even more
> important: you are editing a file as root, or not.
>
> This could fall into the category of enabling-disabling the theme more
> often than just at the start of your session.
I hope that theme won't change my frame's background color ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 19:32:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 22466 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I hope that theme won't change my frame's background color ;-)
Don't know yet. What about blinking alarm red, in case you are root? :-)
The screen flash, as discussed in this bug, would be a feature then.
Another option would be white foreground / white background. For
security reasons. :-)
Hmm. Maybe I let you customize it yourself ...
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 19:56:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 22466 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It's not redisplay that does this. It's the fact that disable-theme
> changes the frame's background color, and when that happens, we
> immediately clear the frame using the new background color, as part of
> the modify-frame-parameters call.
>
> Redisplay only handles the portions of display where there's text and
> other decorations that we manage. Clearing the frame with the new
> background color is not redisplay's job.
Thanks, that's good to know.
>> (set-frame-parameter frame 'background-color
>> (custom--frame-color-default
>> frame :background "background" "Background"
>> "unspecified-bg" "white"))
>>
>> I'm not saying this form is wrong. I'm just pointing to where it happens.
>
> What happens if you remove that from disable-theme?
Then there's no flashing, but then if I simply disable the theme
(without enabling a new one) I'm left with theme's background.
> (I don't really understand why it has to specify "white".)
I guess it's meant to reset the face to the default. Although, I don't
see why this is explicitly necessary for the default
background/foreground colors, but isn't necessary for other faces.
> Anyway, how come you get to doing this so often it hurts your eyes?
> Aren't people setting their beloved theme once when the session
> starts, and then never change it?
I never change my main color theme, but I always have a second theme
enabled that only affects the mode-line. This second theme is changed
occasionally and it always causes a flash (even though the theme has
nothing to do with the background).
Besides, custom themes are not just for faces. This also came up because
someone is writing a package that simultaneously toggles between
different values for a set of variables (called a context) using
custom-themes. That's something that's designed to be used a couple
times a day.
Anyway, it's not a huge defficiency and it's not worth any large
efforts. I brought it up because I thought there was an eager redisplay
happening somewhere and that might point to a deeper bug, but you've
clearly explained that's not the case. :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 20:16:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> From: Artur Malabarba <bruce.connor.am <at> gmail.com>
> Cc: 22466 <at> debbugs.gnu.org
> Date: Tue, 26 Jan 2016 17:25:36 +0000
>
> >> (set-frame-parameter frame 'background-color
> >> (custom--frame-color-default
> >> frame :background "background" "Background"
> >> "unspecified-bg" "white"))
> >>
> >> I'm not saying this form is wrong. I'm just pointing to where it happens.
> >
> > What happens if you remove that from disable-theme?
>
> Then there's no flashing, but then if I simply disable the theme
> (without enabling a new one) I'm left with theme's background.
So disable-theme actually means go back to the default theme? If so,
when someone changes a theme, they don't really need to call
disable-theme, right? They could just call load-theme with the new
theme as an argument?
> I never change my main color theme, but I always have a second theme
> enabled that only affects the mode-line. This second theme is changed
> occasionally and it always causes a flash (even though the theme has
> nothing to do with the background).
>
> Besides, custom themes are not just for faces. This also came up because
> someone is writing a package that simultaneously toggles between
> different values for a set of variables (called a context) using
> custom-themes. That's something that's designed to be used a couple
> times a day.
Then it would make sense to find a way of switching a theme without
changing the frame's background color, if that's possible (i.e. if the
new theme keeps the same background color). If there's a function
missing for that, I'd suggest to add one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Tue, 26 Jan 2016 23:04:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> > On my todo list there is also writing tramp-theme.el. Something, which
> > makes it obvious that you are editing a remote file, or not. Even more
> > important: you are editing a file as root, or not.
> >
> > This could fall into the category of enabling-disabling the theme more
> > often than just at the start of your session.
>
> I hope that theme won't change my frame's background color ;-)
I heard that Michael is working on a special background color
that will take effect only when the user is Eli Zaretskii.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Wed, 27 Jan 2016 22:22:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 22466 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So disable-theme actually means go back to the default theme? If so,
> when someone changes a theme, they don't really need to call
> disable-theme, right? They could just call load-theme with the new
> theme as an argument?
I'm not sure why you reach this conclusion. `disable-theme' is meant to
disable a single theme. If I have theme X enabled, then (disable-theme 'X) is
supposed to restore the default Emacs appearance. If have two themes enabled (X
and Y), then (disable-theme 'X) is supposed to give me just the
appearance of theme Y.
Right now, that's indeed what it does. But if I remove the form (as you
asked) then it fails to do the above (it doesn't remove the background
set by the disabled theme).
> Then it would make sense to find a way of switching a theme without
> changing the frame's background color, if that's possible (i.e. if the
> new theme keeps the same background color). If there's a function
> missing for that, I'd suggest to add one.
How about just running that form only when necessary (i.e., only if the
disabled theme actually sets the frame `background-color')?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Thu, 28 Jan 2016 03:38:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> From: Artur Malabarba <bruce.connor.am <at> gmail.com>
> Cc: 22466 <at> debbugs.gnu.org
> Date: Wed, 27 Jan 2016 20:20:43 +0000
>
> > Then it would make sense to find a way of switching a theme without
> > changing the frame's background color, if that's possible (i.e. if the
> > new theme keeps the same background color). If there's a function
> > missing for that, I'd suggest to add one.
>
> How about just running that form only when necessary (i.e., only if the
> disabled theme actually sets the frame `background-color')?
Yes, something like that. Or maybe add a new switch-theme API that
receives both the old and a new theme, and changes the background
color only if the new theme sets a different one.
Merged 20016 22466.
Request was from
Mauro Aranda <maurooaranda <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Thu, 05 Nov 2020 22:09:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Fri, 07 Mar 2025 11:54:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 22466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Artur Malabarba <bruce.connor.am <at> gmail.com>
>> Cc: 22466 <at> debbugs.gnu.org
>> Date: Wed, 27 Jan 2016 20:20:43 +0000
>>
>> > Then it would make sense to find a way of switching a theme without
>> > changing the frame's background color, if that's possible (i.e. if the
>> > new theme keeps the same background color). If there's a function
>> > missing for that, I'd suggest to add one.
>>
>> How about just running that form only when necessary (i.e., only if the
>> disabled theme actually sets the frame `background-color')?
>
> Yes, something like that. Or maybe add a new switch-theme API that
> receives both the old and a new theme, and changes the background
> color only if the new theme sets a different one.
With the provided recipe, I only see a flash at the scroll-bar
position, unlike in older versions.
I'll be testing the attached patch for a while, which introduces a
new switch-theme command.
[0001-New-command-switch-theme.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Fri, 07 Mar 2025 12:07:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 22466 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 7 Mar 2025 08:53:25 -0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Artur Malabarba <bruce.connor.am <at> gmail.com>
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Artur Malabarba <bruce.connor.am <at> gmail.com>
> >> Cc: 22466 <at> debbugs.gnu.org
> >> Date: Wed, 27 Jan 2016 20:20:43 +0000
> >>
> >> > Then it would make sense to find a way of switching a theme without
> >> > changing the frame's background color, if that's possible (i.e. if the
> >> > new theme keeps the same background color). If there's a function
> >> > missing for that, I'd suggest to add one.
> >>
> >> How about just running that form only when necessary (i.e., only if the
> >> disabled theme actually sets the frame `background-color')?
> >
> > Yes, something like that. Or maybe add a new switch-theme API that
> > receives both the old and a new theme, and changes the background
> > color only if the new theme sets a different one.
>
> With the provided recipe, I only see a flash at the scroll-bar
> position, unlike in older versions.
>
> I'll be testing the attached patch for a while, which introduces a
> new switch-theme command.
Thanks.
Would it be a better UI if instead of prompting with
Enable custom theme:
Disable custom theme:
we would prompt like this:
Switch off theme (default none):
Switch on theme:
I think this order is preferable, since "switch-SOMETHING"
conceptually means turn off OLD, then turn on NEW, not the other way
around, even if the implementation does it in the reverse order for
some technical reasons.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22466; Package
emacs.
(Fri, 07 Mar 2025 12:27:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 22466 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/3/25 09:06, Eli Zaretskii wrote:
>> Date: Fri, 7 Mar 2025 08:53:25 -0300
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, Artur Malabarba
<bruce.connor.am <at> gmail.com>
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Artur Malabarba <bruce.connor.am <at> gmail.com>
>> >> Cc: 22466 <at> debbugs.gnu.org
>> >> Date: Wed, 27 Jan 2016 20:20:43 +0000
>> >>
>> >> > Then it would make sense to find a way of switching a theme
without
>> >> > changing the frame's background color, if that's possible
(i.e. if the
>> >> > new theme keeps the same background color). If there's a function
>> >> > missing for that, I'd suggest to add one.
>> >>
>> >> How about just running that form only when necessary (i.e., only
if the
>> >> disabled theme actually sets the frame `background-color')?
>> >
>> > Yes, something like that. Or maybe add a new switch-theme API that
>> > receives both the old and a new theme, and changes the background
>> > color only if the new theme sets a different one.
>>
>> With the provided recipe, I only see a flash at the scroll-bar
>> position, unlike in older versions.
>>
>> I'll be testing the attached patch for a while, which introduces a
>> new switch-theme command.
>
> Thanks.
>
> Would it be a better UI if instead of prompting with
>
> Enable custom theme:
> Disable custom theme:
>
> we would prompt like this:
>
> Switch off theme (default none):
> Switch on theme:
>
> I think this order is preferable, since "switch-SOMETHING"
> conceptually means turn off OLD, then turn on NEW, not the other way
> around, even if the implementation does it in the reverse order for
> some technical reasons.
Thank you Eli, that does indeed look better for the UI.
Updated patch attached. If it works fine, I'll add a NEWS entry.
[0001-New-command-switch-theme.patch (text/x-patch, attachment)]
This bug report was last modified 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.