GNU bug report logs - #70622
[PATCH] New window parameter 'cursor-type'

Previous Next

Full log

Message #20 received at 70622 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: rudalics <at> gmx.at, 70622 <at> debbugs.gnu.org
Subject: Re: bug#70622: [PATCH] New window parameter 'cursor-type'
Date: Mon, 29 Apr 2024 09:31:49 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: martin rudalics <rudalics <at> gmx.at>,  70622 <at> debbugs.gnu.org
> Date: Sun, 28 Apr 2024 21:05:59 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Eshel Yaron <me <at> eshelyaron.com>
> >> Cc: 70622 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.