emacs-devel
[Top][All Lists]
Advanced

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

Re: Blink Cursor mode is off by default


From: Eli Zaretskii
Subject: Re: Blink Cursor mode is off by default
Date: Tue, 12 Jun 2018 18:20:12 +0300

> Date: Mon, 11 Jun 2018 21:12:52 -0700
> From: address@hidden
> Cc: "Daniel Colascione" <address@hidden>,
>  address@hidden,
>  address@hidden
> 
> > 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.



reply via email to

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