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

Previous Next

Full log

View this message in rfc822 format

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

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

I'd give 'cursor-in-non-selected-windows' precedence over the new window
parameter and not add another window parameter to override it.  IIUC
that's what a buffer-local value of 'cursor-in-non-selected-windows'
currently does to a 'cursor-type' frame parameter.

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

I think 'set-window-parameter' should handle 'cursor-type' specially -
when it changes, it should set that window's redisplay flag.

martin

Previous Next

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