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

[Eli Zaretskii <eliz@gnu.org>]

> 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?  It's confusing and hard to remember.

> > And I have a question: is this supposed to work for non-selected
> > windows as well?  The documentation you added says nothing about that,
> > but I wonder what was the intent?
> 
> Yes, it's supposed to work for non-selected windows as well.  Do you
> think that's worth mentioning explicitly in the documentation?

Not just that, but it also means one cannot specify a different cursor
type for a window when it's selected and when not selected, unlike
with buffers.  Is this anomaly justified?

> > The reason I ask is that we have two buffer-local variables, not one,
> > for both selected and non-selected windows, whereas your patch
> > provides just one window parameter.  How will it interact with the
> > buffer-local variables in both cases?
> 
> That's a really good point.  WRT cursor-in-non-selected-windows, I think
> there are two viable options:
> 
> 1. Give cursor-in-non-selected-windows precedence over the new window
>    parameter, and add another window parameter to override
>    cursor-in-non-selected-windows.
> 2. Give the new window parameter precedence also over
>    cursor-in-non-selected-windows.
> 
> In the updated patch, I went with option 2, so if you set the
> cursor-type window parameter, that overrides any buffer-local variable,
> whether or not the window is selected.  I think that's sensible enough,
> WDYT?

I tend to think option 1 is better, but I'm curious what others think.
Martin, WDYT?

> > In addition, what is supposed to happen when this new window-parameter
> > is changed? is the cursor supposed to be redrawn in the new shape
> > immediately, i.e. do you expect redisplay to happen right away to
> > update the relevant window?
> 
> Not necessarily.  In cases where we want to ensure the cursor is redrawn
> immediately in a non-selected window, we can use force-window-update
> after setting the window parameter.  Should that be mentioned in the
> documentation as well?

I think it would be better to make sure the parameter takes effect
immediately.  Documenting the force-window-update thing should be
fallback, if the immediate effect is impossible.

>        if (w == XWINDOW (echo_area_window))
>  	{
> -	  if (EQ (BVAR (b, cursor_type), Qt) || NILP (BVAR (b, cursor_type)))
> +	  win_cursor = window_parameter (w, Qcursor_type);
> +	  if (CONSP (win_cursor))
> +	    {
> +	      return get_specified_cursor_type (XCAR (win_cursor), width);
> +	    }

We don't use braces for a single-line block.