bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Artur Malabarba]

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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Eli Zaretskii]

> 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?

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Drew Adams]

> 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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Eli Zaretskii]

> 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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Michael Albinus]

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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Eli Zaretskii]

> 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 ;-)

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Michael Albinus]

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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Drew Adams]

> > 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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Artur Malabarba]

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. :-)

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Eli Zaretskii]

> 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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Artur Malabarba]

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')?

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Eli Zaretskii]

> 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.

bug#22466: 25.0.50; disable-theme apparently forces a redisplay and causes a screen flash

[Drew Adams]

> > > 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.