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

From: Eshel Yaron <[email-masked]>
Date: Mon, 29 Apr 2024 10:18:33 +0200

Eli Zaretskii <[email-masked]> writes:

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

Perhaps I'm missing something, but I think it's not so simple.  We
can't/shouldn't interpret a value of nil differently from no alist entry
at all, since there's no way to remove alist entries (in order to unset
the window parameter) from lisp, right?

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

Agreed.  If we could use exactly the same format for the values of the
variable and window parameter that would be best.  But AFAIU we need
some encoding (special quirk) when translating from variable values (VV)
to window parameter values (WPV), due to the competing interpretations
for nil.  The first encoding I proposed is simple and uniform: cons to
go from VV to WPV, car to go the other way.  The alternative encoding I
proposed below, following mode-line-format, is trivial for most VV, but
not uniform, because one needs to translate nil to 'none when going from
VV to WPV.

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

See above.  Please let me know if I'm mistaken about the possibility of
differentiating a value of nil from the absence of an alist entry.

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

See "(elisp) Window Parameters":

‘mode-line-format’
     This parameter replaces the value of the buffer-local variable
     ‘mode-line-format’ (*note Mode Line Basics::) of this window's
     buffer whenever this window is displayed.  The symbol ‘none’ means
     to suppress display of a mode line for this window.

Here the window parameter has the same set of possible values as the
variable, except the window parameter also has the value 'none, which
corresponds to the variable's nil value.  The nil value of the window
parameter means "window parameter not set".