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

From: martin rudalics <[email-masked]>
Date: Fri, 10 May 2024 10:58:58 +0200

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