Re: More about blink-cursor-mode

[Stefan Monnier]

> which ensured that the value when evaluated before startup.el was
> loaded would be nil.

Any evidence that it matters?
Really, it shouldn't matter, so if you know of a place where it matters,
maybe we should fix it.  The initial value is simply forcibly overridden in
startup.el, without paying *any* attention to the old value.  At least
that's how it should work.

>    In any case all this round-about hack seems completely unnecessary
> It will be necessary for other options that still need to be given a
> correct Custom standard expression and for which the noninteractive
> coincidence will not happen.

No, the same "blind override" should apply there as well.

>    and if really the standard expression signals an error if it is
>    evaluated too early, then we can just wrap it with a
>    (condition-case nil ... (error nil)) or some such.

> One _definitely_ does not want to wrap a Custom standard expression in
> a condition-case.

Why not, exactly?

>    Seems like a much better option than this nasty unexplained stuff
>    we have now.
> The comment tried to explain it.

It did not explain why this particular workaround was used.
E.g. why (defvar cursor-blink-mode)?  It seems 100% useless since it's only
a byte-compiler directive and only has the effect of declaring the variable
2 lines earlier, but since the variable is not *used* in those two lines, it
shouldn't matter.  Why not wrap the expression in condition-case instead?
Or place `boundp' checks instead?  That's what I mean by "lack of
explanation".

> The comment left after your change does not make a lot of sense any
> more.

> Maybe it is better to put the:

> (defvar blink-cursor-mode)
> (unless (default-boundp 'blink-cursor-mode)
>    (setq-default blink-cursor-mode nil))

> with something like the original comment back in, to protect against
> future code changes, that might undo the current lucky coincidence.

Please *concretely* justify the need for such ugly code, before
considering re-installing it.

> If not, I believe that the comment in the patch below should be added.

If you want to add such a comment, it should start by explaining why it's
important that the initial value be nil rather than t or `slipper'.
Otherwise it makes no sense.

> The :group _definitely_ should be changed back to 'cursor, as the
> patch below does.

Fair enough ;-)


        Stefan