Blink Cursor mode is off by default

Blink Cursor mode is off by default

[Eli Zaretskii]

Commit 2db57579b08ac99c464b6d3698648b3167fc5d55 caused what the
Subject says: blink-cursor-mode is now off by default on GUI frames.
(I see this on Windows, but I cannot imagine it is any different on
other GUI platforms.)  (Judging by lack of complaints, perhaps we
should just turn that mode off by default ;-)

It happened because that commit moved the call to
custom-reevaluate-setting to an earlier place during startup, and the
initial window-system is not yet set up at that place.  So the
condition in blink-cursor-mode evaluates to nil, and the mode is
disabled.

I can see several ways out of this:

  . Move the call to custom-reevaluate-setting back where it was, and
    instead call custom-reevaluate-setting in that earlier place only
    for Info-default-directory-list, which was the original reason why
    the call was moved;
  . Add a call to custom-reevaluate-setting for blink-cursor-mode
    where the window-system is already set up;
  . Call custom-reevaluate-setting for all the delayed-init variables
    twice: once where we do that now, and again where we did that
    before the above commit;
  . Introduce yet another variable similar to
    custom-delayed-init-variables, but separate from it, and put on
    it all the delayed-init variables that need the window-system to
    be set up, leaving all the rest in custom-delayed-init-variables.

I tend to favor the 3rd alternative, as it is relatively easy and at
the same time reliable.  The first two mean a significant maintenance
burden to consider each new variable whether it needs an additional
evaluation after window-system setup; the last alternative is maybe
too complex.

Comments?

Re: Blink Cursor mode is off by default

[Stefan Monnier]

>   . Call custom-reevaluate-setting for all the delayed-init variables
>     twice: once where we do that now, and again where we did that
>     before the above commit;

I tend to agree that this is the better option.  The main downside, IIUC
is if the user does

    (blink-cursor-mode -1)

in his early-init.el, which will be overridden by the second
custom-reevaluate-setting.


        Stefan

Re: Blink Cursor mode is off by default

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 11 Jun 2018 13:14:15 -0400
> 
> >   . Call custom-reevaluate-setting for all the delayed-init variables
> >     twice: once where we do that now, and again where we did that
> >     before the above commit;
> 
> I tend to agree that this is the better option.  The main downside, IIUC
> is if the user does
> 
>     (blink-cursor-mode -1)
> 
> in his early-init.el, which will be overridden by the second
> custom-reevaluate-setting.

Well, yes, but they aren't supposed to do that in that file, right?

Re: Blink Cursor mode is off by default

[Stefan Monnier]

> Well, yes, but they aren't supposed to do that in that file, right?

Not sure: a valid choice now is to do all your customizations in
early-init.el and not use any .emacs.d/init.el at all.


        Stefan

Re: Blink Cursor mode is off by default

[dancol]

>> Well, yes, but they aren't supposed to do that in that file, right?

What about temporarily setting a variable watcher on blink-cursor-mode so
we can tell whether early init touched it?

> Not sure: a valid choice now is to do all your customizations in
> early-init.el and not use any .emacs.d/init.el at all.

That's what I do now.

Re: Blink Cursor mode is off by default

[Eli Zaretskii]

> Date: Mon, 11 Jun 2018 16:19:42 -0700
> From: dancol@dancol.org
> Cc: "Eli Zaretskii" <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> >> Well, yes, but they aren't supposed to do that in that file, right?
> 
> What about temporarily setting a variable watcher on blink-cursor-mode so
> we can tell whether early init touched it?

I think it's too gross.

> > Not sure: a valid choice now is to do all your customizations in
> > early-init.el and not use any .emacs.d/init.el at all.
> 
> That's what I do now.

I suggest you don't.  This is not what early-init.el is for.

Re: Blink Cursor mode is off by default

[Daniel Colascione]

On 06/11/2018 07:31 PM, Eli Zaretskii wrote:
>> Date: Mon, 11 Jun 2018 16:19:42 -0700
>> From: dancol@dancol.org
>> Cc: "Eli Zaretskii" <eliz@gnu.org>,
>>   emacs-devel@gnu.org
>>
>>>> Well, yes, but they aren't supposed to do that in that file, right?
>>
>> What about temporarily setting a variable watcher on blink-cursor-mode so
>> we can tell whether early init touched it?
> 
> I think it's too gross.

Why? We have a tool. Let's use it.

> 
>>> Not sure: a valid choice now is to do all your customizations in
>>> early-init.el and not use any .emacs.d/init.el at all.
>>
>> That's what I do now.
> 
> I suggest you don't.  This is not what early-init.el is for.

Why not? Now I can have the entire configuration loaded before the first 
frame is created. It looks clean.

Re: Blink Cursor mode is off by default

[Eli Zaretskii]

On June 12, 2018 5:33:32 AM GMT+03:00, Daniel Colascione <dancol@dancol.org> wrote:
> On 06/11/2018 07:31 PM, Eli Zaretskii wrote:
> >> Date: Mon, 11 Jun 2018 16:19:42 -0700
> >> From: dancol@dancol.org
> >> Cc: "Eli Zaretskii" <eliz@gnu.org>,
> >>   emacs-devel@gnu.org
> >>
> >>>> Well, yes, but they aren't supposed to do that in that file,
> right?
> >>
> >> What about temporarily setting a variable watcher on
> blink-cursor-mode so
> >> we can tell whether early init touched it?
> > 
> > I think it's too gross.
> 
> Why? We have a tool. Let's use it.

I cannot explain it, but it sounds inelegant.

I think we can use (get var 'standard-value) instead to detect
variables that were modified in early-init, and refrain from
reinitializing them the second time.

> >>> Not sure: a valid choice now is to do all your customizations in
> >>> early-init.el and not use any .emacs.d/init.el at all.
> >>
> >> That's what I do now.
> > 
> > I suggest you don't.  This is not what early-init.el is for.
> 
> Why not? Now I can have the entire configuration loaded before the
> first 
> frame is created. It looks clean.

Clean, but unsafe, as important parts of startup has not yet
been done.  E.g., anything related to fonts or faces will probably
not work reliably at that point.

There's a reason why we read the user init file at some specific
place and not before.

Re: Blink Cursor mode is off by default

[dancol]

> On June 12, 2018 5:33:32 AM GMT+03:00, Daniel Colascione
> <dancol@dancol.org> wrote:
>> On 06/11/2018 07:31 PM, Eli Zaretskii wrote:
>> >> Date: Mon, 11 Jun 2018 16:19:42 -0700
>> >> From: dancol@dancol.org
>> >> Cc: "Eli Zaretskii" <eliz@gnu.org>,
>> >>   emacs-devel@gnu.org
>> >>
>> >>>> Well, yes, but they aren't supposed to do that in that file,
>> right?
>> >>
>> >> What about temporarily setting a variable watcher on
>> blink-cursor-mode so
>> >> we can tell whether early init touched it?
>> >
>> > I think it's too gross.
>>
>> Why? We have a tool. Let's use it.
>
> I cannot explain it, but it sounds inelegant.
>
> I think we can use (get var 'standard-value) instead to detect
> variables that were modified in early-init, and refrain from
> reinitializing them the second time.

Does that work? In the case of (blink-cursor-mode -1), we just set
blink-cursor-mode to nil --- but it starts nil anyway, so we can't tell
the difference. The standard-value property doesn't help, I think.

>> >>> Not sure: a valid choice now is to do all your customizations in
>> >>> early-init.el and not use any .emacs.d/init.el at all.
>> >>
>> >> That's what I do now.
>> >
>> > I suggest you don't.  This is not what early-init.el is for.
>>
>> Why not? Now I can have the entire configuration loaded before the
>> first
>> frame is created. It looks clean.
>
> Clean, but unsafe, as important parts of startup has not yet
> been done.  E.g., anything related to fonts or faces will probably
> not work reliably at that point.

Works fine for me. We don't run early init _that_ early: it comes before
packages and site files, but the basic machinery is up. All I want is the
ability to configure the first frame before it appears, and only X
resources and early-init provide this ability.

Re: Blink Cursor mode is off by default

[Eli Zaretskii]

> Date: Mon, 11 Jun 2018 21:12:52 -0700
> From: dancol@dancol.org
> Cc: "Daniel Colascione" <dancol@dancol.org>,
>  monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> > I think we can use (get var 'standard-value) instead to detect
> > variables that were modified in early-init, and refrain from
> > reinitializing them the second time.
> 
> Does that work? In the case of (blink-cursor-mode -1), we just set
> blink-cursor-mode to nil --- but it starts nil anyway, so we can't tell
> the difference. The standard-value property doesn't help, I think.

You are right: sadly, this doesn't work, certainly not when the user
customization doesn't change the value that custom-reevaluate-setting
sets.  We have no infrastructure I could find that records anywhere
the fact that user customizations changed did something, and in the
specific case of a minor mode, custom-reevaluate-setting simply calls
the mode function, so it does exactly what user customizations do.

> > Clean, but unsafe, as important parts of startup has not yet
> > been done.  E.g., anything related to fonts or faces will probably
> > not work reliably at that point.
> 
> Works fine for me. We don't run early init _that_ early: it comes before
> packages and site files, but the basic machinery is up. All I want is the
> ability to configure the first frame before it appears, and only X
> resources and early-init provide this ability.

You are lucky, or maybe your customizations are sophisticated enough
to work around the problems.

Anyway, I consider the problem with failed initialization of cursor
blinking serious enough to be in need of fixing.  So I installed the
second re-evaluation of custom-delayed-init-variables, and also added
some blurb to the docs that advises against putting in the early init
file what doesn't have to be there.  I consider the problem with
clobbering user customizations in early-init.el a secondary one,
especially since we already do that with one or two variables anyway,
although it would be good to fix that, of course.

Re: Blink Cursor mode is off by default

[Stefan Monnier]

> Anyway, I consider the problem with failed initialization of cursor
> blinking serious enough to be in need of fixing.  So I installed the
> second re-evaluation of custom-delayed-init-variables, and also added
> some blurb to the docs that advises against putting in the early init
> file what doesn't have to be there.

Good, thanks.

> I consider the problem with clobbering user customizations in
> early-init.el a secondary one, especially since we already do that
> with one or two variables anyway, although it would be good to fix
> that, of course.

I think in the case of blink-cursor-mode, that mode should simply be
t by default, point, with no need for reevaluation.

That t value would simply have no effect in those cases where we
can't (or don't know how to) make it effective (e.g. ms-dos, tty,
noninteractive).  Sorry, no sample patch this time ;-)


        Stefan

Re: Blink Cursor mode is off by default

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: dancol@dancol.org, emacs-devel@gnu.org
> Date: Tue, 12 Jun 2018 11:52:33 -0400
> 
> I think in the case of blink-cursor-mode, that mode should simply be
> t by default, point, with no need for reevaluation.

Didn't Daniel just invest some non-trivial work into having it off on
TTYs, so that the blink-cursor timer won't run in vain?

But if that's possible without losing anything, I don't mind.  It's
just one example of what can go wrong with too early reevaluation of
defcustoms, and there's nothing wrong with a solution specific to this
mode, as long as the general solution is there.

Re: Blink Cursor mode is off by default

[dancol]

>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Cc: dancol@dancol.org, emacs-devel@gnu.org
>> Date: Tue, 12 Jun 2018 11:52:33 -0400
>>
>> I think in the case of blink-cursor-mode, that mode should simply be
>> t by default, point, with no need for reevaluation.
>
> Didn't Daniel just invest some non-trivial work into having it off on
> TTYs, so that the blink-cursor timer won't run in vain?

I did --- which means that we can enable blink-cursor-mode itself
unconditionally and only pay for it when we happen to have a GUI terminal.
Stefan's idea is a good one, but I wish we'd query the GTK setting too.

Yes, please allow pre-configuration of first frame [was: Blink Cursor mode is off by default]

[N. Jackson]

At 21:12 -0700 on Monday 2018-06-11, dancol wrote:
>
> All I want is the ability to configure the first frame
> before it appears, and only X resources and early-init
> provide this ability.

It would certainly seem to be a nice improvement if the first
frame was not displayed before all the user configuration
effecting its size and appearance was available. While it is
superficial and thus unimportant in some ways, the current
behaviour with flashing/jumping frames looks unprofessional
and makes a poor first impression.

It doesn't sound right, though, that a fix for this should
involve the user having to mess around with intiialisation
order etc. -- it should "just work".

It seems that this might be a worthwhile project for "someone"
to work on? (Perhaps they could fix the problem of not being
able to un-apply themes at the same time?)

N.

Re: Yes, please allow pre-configuration of first frame [was: Blink Cursor mode is off by default]

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Fri, 15 Jun 2018 10:14:24 -0400
> 
> It would certainly seem to be a nice improvement if the first
> frame was not displayed before all the user configuration
> effecting its size and appearance was available. While it is
> superficial and thus unimportant in some ways, the current
> behaviour with flashing/jumping frames looks unprofessional
> and makes a poor first impression.
> 
> It doesn't sound right, though, that a fix for this should
> involve the user having to mess around with intiialisation
> order etc. -- it should "just work".

I agree.  A warning, though: this task is not for the faint at heart,
there are quite a few obstacles to negotiate, to do this without
breaking several important features that get set up at startup.

> It seems that this might be a worthwhile project for "someone"
> to work on?

Yes.  I suggest to file a wishlist bug report about that, and perhaps
also add it to TODO.

Thanks.

Re: Yes, please allow pre-configuration of first frame [was: Blink Cursor mode is off by default]

[Stefan Monnier]

> It doesn't sound right, though, that a fix for this should
> involve the user having to mess around with intiialisation
> order etc. -- it should "just work".
>
> It seems that this might be a worthwhile project for "someone"
> to work on? (Perhaps they could fix the problem of not being
> able to un-apply themes at the same time?)

I don't really understand what you suggest doing: the .emacs file is
read *after* creating the first frame, so there's no way to avoid
"flashing" without breaking some .emacs files.


        Stefan

Re: Yes, please allow pre-configuration of first frame [was: Blink Cursor mode is off by default]

[Daniel Colascione]

On 06/15/2018 02:34 PM, Stefan Monnier wrote:
>> It doesn't sound right, though, that a fix for this should
>> involve the user having to mess around with intiialisation
>> order etc. -- it should "just work".
>>
>> It seems that this might be a worthwhile project for "someone"
>> to work on? (Perhaps they could fix the problem of not being
>> able to un-apply themes at the same time?)
> 
> I don't really understand what you suggest doing: the .emacs file is
> read *after* creating the first frame, so there's no way to avoid
> "flashing" without breaking some .emacs files.

The file could just run against a dummy frame that happens to look like 
the GUI frame we'll eventually create.

Re: Yes, please allow pre-configuration of first frame [was: Blink Cursor mode is off by default]

[Stefan Monnier]

>>> It doesn't sound right, though, that a fix for this should
>>> involve the user having to mess around with intiialisation
>>> order etc. -- it should "just work".
>>>
>>> It seems that this might be a worthwhile project for "someone"
>>> to work on? (Perhaps they could fix the problem of not being
>>> able to un-apply themes at the same time?)
>>
>> I don't really understand what you suggest doing: the .emacs file is
>> read *after* creating the first frame, so there's no way to avoid
>> "flashing" without breaking some .emacs files.
>
> The file could just run against a dummy frame that happens to look like the
> GUI frame we'll eventually create.

To reduce the breakage, the frame had batter be as real as possible
(e.g. plain normal frame, just `invisible`), but still: what will happen
when the .emacs code ends up prompting the user in the minibuffer?

It will inevitably introduce changes which in some cases are undesirable,


        Stefan

Re: Yes, please allow pre-configuration of first frame [was: Blink Cursor mode is off by default]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sat, 16 Jun 2018 13:20:21 -0400
> Cc: emacs-devel@gnu.org
> 
> > The file could just run against a dummy frame that happens to look like the
> > GUI frame we'll eventually create.
> 
> To reduce the breakage, the frame had batter be as real as possible
> (e.g. plain normal frame, just `invisible`), but still: what will happen
> when the .emacs code ends up prompting the user in the minibuffer?

What if we create and display a small special frame, "normal" enough
to support everything any .emacs could expect, but devoid of stuff
like the menu bar, the tool bar, and the scroll bars?  Many
applications show something like that at startup, so I think that
would look "professional" enough.

Re: Yes, please allow pre-configuration of first frame [was: Blink Cursor mode is off by default]

[Daniel Colascione]

>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Date: Sat, 16 Jun 2018 13:20:21 -0400
>> Cc: emacs-devel@gnu.org
>>
>> > The file could just run against a dummy frame that happens to look
>> like the
>> > GUI frame we'll eventually create.
>>
>> To reduce the breakage, the frame had batter be as real as possible
>> (e.g. plain normal frame, just `invisible`), but still: what will happen
>> when the .emacs code ends up prompting the user in the minibuffer?

Display the frame in the unlikely case that we stop and wait for input.

> What if we create and display a small special frame, "normal" enough
> to support everything any .emacs could expect, but devoid of stuff
> like the menu bar, the tool bar, and the scroll bars?  Many
> applications show something like that at startup, so I think that
> would look "professional" enough.

Splash screens are awful: they're disruptive and excuse poor startup times.

Re: Blink Cursor mode is off by default

[Stefan Monnier]

>> Why not? Now I can have the entire configuration loaded before the
>> first  frame is created. It looks clean.

Agreed.  I used to have a local hack that caused the .emacs to be read
before creating the initial frame, so now I can finally drop this hack.

> Clean, but unsafe, as important parts of startup has not yet
> been done.  E.g., anything related to fonts or faces will probably
> not work reliably at that point.

Some things won't work, of course, but it's not new: the same problems
affect ~/.emacs when Emacs is run as a daemon.

> There's a reason why we read the user init file at some specific
> place and not before.

There are advantages to using ~/.emacs (e.g. emacs --debug-init drops
you in the debugger instead of dumping a stack trace), but it's not
universally superior.


        Stefan

Re: Blink Cursor mode is off by default

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Mon, 11 Jun 2018 18:13:12 -0400
> 
> > Well, yes, but they aren't supposed to do that in that file, right?
> 
> Not sure: a valid choice now is to do all your customizations in
> early-init.el and not use any .emacs.d/init.el at all.

But we already have a couple of variables for which we call
custom-reevaluate-setting one more time, so this issue is already
here.

Re: Blink Cursor mode is off by default

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Commit 2db57579b08ac99c464b6d3698648b3167fc5d55 caused what the
> Subject says: blink-cursor-mode is now off by default on GUI frames.
> (I see this on Windows, but I cannot imagine it is any different on
> other GUI platforms.)  (Judging by lack of complaints, perhaps we
> should just turn that mode off by default ;-)

Bug #30994?


Michael.

Re: Blink Cursor mode is off by default

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org,  Radon Rosborough <radon.neon@gmail.com>
> Date: Mon, 11 Jun 2018 22:43:35 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Commit 2db57579b08ac99c464b6d3698648b3167fc5d55 caused what the
> > Subject says: blink-cursor-mode is now off by default on GUI frames.
> > (I see this on Windows, but I cannot imagine it is any different on
> > other GUI platforms.)  (Judging by lack of complaints, perhaps we
> > should just turn that mode off by default ;-)
> 
> Bug #30994?

Right ;-)