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

[martin rudalics]

>>> +DEFUN ("set-window-cursor-type", Fset_window_cursor_type,
>>> +       Sset_window_cursor_type, 2, 2, 0,
>>> +       doc: /* Set the `cursor-type' of WINDOW to TYPE.
>>> +
>>> +This setting takes precedence over the variable `cursor-type', and TYPE
>>> +has the same format as the value of that variable.  WINDOW nil means use
>>> +the selected window.  */)
>>> +  (Lisp_Object window, Lisp_Object type)
>>> +{
>>> +  struct window *w = decode_live_window (window);
>>> +
>>> +  wset_cursor_type (w, type);
>>
>> Shouldn't we validate the value of TYPE before plugging it into the
>> window?  I know we will validate it at display time, but maybe it's a
>> good idea to do that here as well, and signal an error up front?
>
> AFAICT there are no invalid values, since we take "any other value" to
> mean the same as 'hollow' (see C-h v cursor-type), so I think not
> validating anything should be perfectly valid :)
>
>> Martin, WDYT?

I think Eshel is right.

>>> +DEFUN ("window-cursor-type", Fwindow_cursor_type, Swindow_cursor_type,
>>> +       0, 1, 0,
>>> +       doc: /* Return the `cursor-type' of WINDOW.
>>> +WINDOW must be a live window and defaults to the selected one.  */)
>>> +  (Lisp_Object window)
>>> +{
>>> +  return decode_live_window (window)->cursor_type;
>>> +}
>>
>> This will AFAIU return t if the value is Qt.  Should we return the
>> value actually in effect in that case?
>
> Maybe, but that's a bit tricky because we need to consider whether or
> not the window is selected and what cursor-in-non-selected-windows has
> to say to figure out what the cursor will actually look like.  Currently
> this function just provides Lisp with access to the window slot, so we
> have all the needed information available in Lisp.  I suggest keeping
> 'window-cursor-type' simple and, if the need arises, providing a Lisp
> function that calculates the effective cursor type for a given window.
> WDYT?

If needed, the function can be given a second argument that allows to
retrieve either the value specified for this window or the effective
value used.

'set-window-cursor-type' like all other functions and parameters in this
context suffers from the problem that there's no common concept wrt
setting window/buffer/frame-local values.  This matters when a
buffer-local value changes or another buffer is shown in a window.  For
margins or fringes the PERSISTENT argument can be used to tell whether a
window-specified value shall survive subsequent 'set-window-buffer'
calls.  Setting the buffer variable for these doesn't take effect
immediately.

For 'set-window-cursor-type' we probably should say that any value it
sets is "persistent" (survives subsequent 'set-window-buffer' calls)
unless the value delegates the choice to the 'cursor-type' variable or
frame parameter and that it takes effect immediately.

And we _could_ tell that setting the 'cursor-type' variable takes effect
"pretty soon", that is when an associated window is redisplayed so it
does not have to wait until the next 'set-window-buffer' call, that it
can be overridden by 'set-window-cursor-type' in quite some ways, and
that 'set-window-buffer' won't use the buffer value when another way has
been specified via 'set-window-cursor-type'.  If I'm right, obviously.

martin