Subject: bug#70622: [PATCH] New window parameter 'cursor-type'

From: Eli Zaretskii <[email-masked]>
Date: Mon, 29 Apr 2024 09:31:49 +0300

> From: Eshel Yaron <[email-masked]>
> Cc: martin rudalics <[email-masked]>,  [email-masked]
> Date: Sun, 28 Apr 2024 21:05:59 +0200
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Eshel Yaron <[email-masked]>
> >> Cc: [email-masked]
> >> Date: Sun, 28 Apr 2024 17:00:33 +0200
> >>
> >> > Why only cons cells are supported?
> >>
> >> We need a convenient way to specify both "window parameter not set" and
> >> "window parameter set and says not to show a cursor".  Naturally, we
> >> want to use nil for "window parameter not set", but then nil is what the
> >> variable cursor-type uses for "don't to show a cursor".
> >
> > We have the same problem in the frame parameter by this name, and we
> > solve it there without these complications.  Why should the window
> > parameter be different?
> 
> This is a little different, though.  Indeed, the frame parameter also
> uses nil to denote "no cursor".  The variable, which overrides the frame
> parameter, uses t to delegate to the frame parameter, so it supports all
> values of the frame parameter (including nil), plus t.  But unlike a
> variable, we can't make the window parameter default to t (or any other
> non-nil value) as easily.

I still don't think I understand the difficultly.  The "window
parameter not set" can be detected by testing whether cursor-type is
an element in the alist returned by window-parameters, couldn't it?

> > It's confusing and hard to remember.
> 
> I went with this format because it lets you use all values of the
> cursor-type variable in a uniform manner (just wrap it in a list).

It is confusing to have several parameters and variables with a
similar semantics that each require special quirks to get the same
effect.  We should try to make the forms of the values of such
variables and parameters be uniform.

> Alternatively, we can use the exact same format for the window
> parameter as we do for the variable, except we interpret a window
> parameter nil value as "window parameter unset", not "no cursor", and
> instead add another value for the window parameter, 'none, that'll
> correspond to the nil value of the variable (so window parameter 'none
> would say not to show the cursor).

That's possible, but doesn't the absence of cursor-type parameter from
window-parameters already allow to solve that?

> This is in line with what we have
> for the mode-line-format variable and window parameter, for example.

Where do we use this convention for window parameters?