[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70622: [PATCH] New window parameter 'cursor-type'
From: |
Eli Zaretskii |
Subject: |
bug#70622: [PATCH] New window parameter 'cursor-type' |
Date: |
Mon, 29 Apr 2024 09:31:49 +0300 |
> From: Eshel Yaron <me@eshelyaron.com>
> Cc: martin rudalics <rudalics@gmx.at>, 70622@debbugs.gnu.org
> Date: Sun, 28 Apr 2024 21:05:59 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Eshel Yaron <me@eshelyaron.com>
> >> Cc: 70622@debbugs.gnu.org
> >> 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?
- bug#70622: [PATCH] New window parameter 'cursor-type', Eshel Yaron, 2024/04/28
- bug#70622: [PATCH] New window parameter 'cursor-type', Eli Zaretskii, 2024/04/28
- bug#70622: [PATCH] New window parameter 'cursor-type', Eshel Yaron, 2024/04/28
- bug#70622: [PATCH] New window parameter 'cursor-type', Eli Zaretskii, 2024/04/28
- bug#70622: [PATCH] New window parameter 'cursor-type', Eshel Yaron, 2024/04/28
- bug#70622: [PATCH] New window parameter 'cursor-type',
Eli Zaretskii <=
- bug#70622: [PATCH] New window parameter 'cursor-type', Eshel Yaron, 2024/04/29
- bug#70622: [PATCH] New window parameter 'cursor-type', Eli Zaretskii, 2024/04/29
- bug#70622: [PATCH] New window parameter 'cursor-type', martin rudalics, 2024/04/29
- bug#70622: [PATCH] New window parameter 'cursor-type', Eli Zaretskii, 2024/04/29
- bug#70622: [PATCH] New window parameter 'cursor-type', martin rudalics, 2024/04/30
- bug#70622: [PATCH] New window parameter 'cursor-type', Eli Zaretskii, 2024/04/30
- bug#70622: [PATCH] New window parameter 'cursor-type', martin rudalics, 2024/04/29