* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
[not found] ` <<83d1so1df3.fsf@gnu.org>
@ 2016-01-26 17:07 ` Drew Adams
0 siblings, 0 replies; 13+ messages in thread
From: Drew Adams @ 2016-01-26 17:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22466, bruce.connor.am
> > > 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
@ 2016-01-26 9:02 Artur Malabarba
2016-01-26 14:58 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Artur Malabarba @ 2016-01-26 9:02 UTC (permalink / raw)
To: 22466
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 9:02 Artur Malabarba
@ 2016-01-26 14:58 ` Eli Zaretskii
2016-01-26 16:36 ` Drew Adams
2016-01-26 17:25 ` Artur Malabarba
0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-01-26 14:58 UTC (permalink / raw)
To: Artur Malabarba; +Cc: 22466
> From: Artur Malabarba <bruce.connor.am@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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 14:58 ` Eli Zaretskii
@ 2016-01-26 16:36 ` Drew Adams
2016-01-26 17:03 ` Eli Zaretskii
2016-01-26 17:25 ` Artur Malabarba
1 sibling, 1 reply; 13+ messages in thread
From: Drew Adams @ 2016-01-26 16:36 UTC (permalink / raw)
To: Eli Zaretskii, Artur Malabarba; +Cc: 22466
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 16:36 ` Drew Adams
@ 2016-01-26 17:03 ` Eli Zaretskii
2016-01-26 18:41 ` Michael Albinus
[not found] ` <<87y4bc89pt.fsf@gmx.de>
0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-01-26 17:03 UTC (permalink / raw)
To: Drew Adams; +Cc: 22466, bruce.connor.am
> Date: Tue, 26 Jan 2016 08:36:56 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22466@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.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 17:03 ` Eli Zaretskii
@ 2016-01-26 18:41 ` Michael Albinus
2016-01-26 18:55 ` Eli Zaretskii
[not found] ` <<87y4bc89pt.fsf@gmx.de>
1 sibling, 1 reply; 13+ messages in thread
From: Michael Albinus @ 2016-01-26 18:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22466, bruce.connor.am
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Tue, 26 Jan 2016 08:36:56 -0800 (PST)
>> From: Drew Adams <drew.adams@oracle.com>
>> Cc: 22466@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.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 18:41 ` Michael Albinus
@ 2016-01-26 18:55 ` Eli Zaretskii
2016-01-26 19:31 ` Michael Albinus
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-01-26 18:55 UTC (permalink / raw)
To: Michael Albinus; +Cc: 22466, bruce.connor.am
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Drew Adams <drew.adams@oracle.com>, 22466@debbugs.gnu.org, bruce.connor.am@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 ;-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 18:55 ` Eli Zaretskii
@ 2016-01-26 19:31 ` Michael Albinus
0 siblings, 0 replies; 13+ messages in thread
From: Michael Albinus @ 2016-01-26 19:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22466, bruce.connor.am
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <<87y4bc89pt.fsf@gmx.de>]
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 14:58 ` Eli Zaretskii
2016-01-26 16:36 ` Drew Adams
@ 2016-01-26 17:25 ` Artur Malabarba
2016-01-26 20:15 ` Eli Zaretskii
1 sibling, 1 reply; 13+ messages in thread
From: Artur Malabarba @ 2016-01-26 17:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22466
Eli Zaretskii <eliz@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. :-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 17:25 ` Artur Malabarba
@ 2016-01-26 20:15 ` Eli Zaretskii
2016-01-27 20:20 ` Artur Malabarba
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-01-26 20:15 UTC (permalink / raw)
To: Artur Malabarba; +Cc: 22466
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: 22466@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-26 20:15 ` Eli Zaretskii
@ 2016-01-27 20:20 ` Artur Malabarba
2016-01-28 3:36 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Artur Malabarba @ 2016-01-27 20:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22466
Eli Zaretskii <eliz@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')?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash
2016-01-27 20:20 ` Artur Malabarba
@ 2016-01-28 3:36 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-01-28 3:36 UTC (permalink / raw)
To: Artur Malabarba; +Cc: 22466
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: 22466@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-01-28 3:36 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <<87y4bcsogq.fsf@gmail.com>
[not found] ` <<83powo1j71.fsf@gnu.org>
[not found] ` <<1bbf7218-bd5b-4618-822c-cd75884a81ee@default>
[not found] ` <<83d1so1df3.fsf@gnu.org>
2016-01-26 17:07 ` bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash Drew Adams
2016-01-26 9:02 Artur Malabarba
2016-01-26 14:58 ` Eli Zaretskii
2016-01-26 16:36 ` Drew Adams
2016-01-26 17:03 ` Eli Zaretskii
2016-01-26 18:41 ` Michael Albinus
2016-01-26 18:55 ` Eli Zaretskii
2016-01-26 19:31 ` Michael Albinus
[not found] ` <<87y4bc89pt.fsf@gmx.de>
[not found] ` <<834me01881.fsf@gnu.org>
2016-01-26 23:02 ` Drew Adams
2016-01-26 17:25 ` Artur Malabarba
2016-01-26 20:15 ` Eli Zaretskii
2016-01-27 20:20 ` Artur Malabarba
2016-01-28 3:36 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).