Is it somehow possible to meaningfully use window-start during a 'redisplay'?

Is it somehow possible to meaningfully use window-start during a 'redisplay'?

[dalanicolai]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

Hi all!

I am trying to use the functions window-start and window-end, within a
function that gets called from the window-configuration-change-hook as
follows:

(defun test ()
>   (interactive)
>   (let ((inhibit-read-only t))
>     (dotimes (i 9)
>       (let ((o (make-overlay (point) (progn (insert " ") (point)))))
> (insert "\n")
> (overlay-put o 'face `(:background ,(pcase (% i 3)
>      (0 "red")
>      (1 "green")
>      (2 "blue"))))
> (overlay-put o 'display '(space . (:width (600) :height (800))))
> (overlay-put o 'window (selected-window))))
>     (when (looking-back "\n")
>       (delete-char -1)))
>   (goto-char 7)
>
>   (print (current-buffer) #'external-debugging-output)
>   (print (window-buffer (selected-window)) #'external-debugging-output)
>   (print (point) #'external-debugging-output)
>
>   (force-window-update (selected-window))
>   (redisplay t)
>
>   (print (window-start) #'external-debugging-output)
>   (print (window-end nil t) #'external-debugging-output))
>
>
> (define-derived-mode test-mode special-mode "Test"
>   "Debug"
>   (add-hook 'window-configuration-change-hook #'test nil t))
>
> (add-to-list 'auto-mode-alist '("\\.debug\\'" . test-mode))
>

The above test function creates some 'space overlays' after which it
tries to determine the actual 'displayed' overlays by using
window-start and window-end. It prints debugging output to the
terminal (it is printing to the terminal because printing elsewhere
makes debugging redisplay issues more complicated).

Now when invoking the command manually in some buffer, the functions
window-start and window-end, work correctly, i.e. window-start returns
the same value as point (both 7, after the goto-char 7). Actually
using a simple '(redisplay)' before window-start is sufficient.

However, when triggering the function from the
'window-configuration-change-hook' (for that simply 'visit a new file'
ending with a '.debug' extension), the window-start and window-end
functions seem unusable; i.e even after adding

  (force-window-update (selected-window))
>   (redisplay t)
>

before using them, window-start still returns 1 while point is at 7.

I conclude that I can not redisplay during a redisplay this way.
Would it be possible to get the 'correct' values using window-start
and window-end during a redisplay/from the
'window-configuration-change-hook'?

Thanks

[-- Attachment #2: Type: text/html, Size: 3169 bytes --]

Re: Is it somehow possible to meaningfully use window-start during a 'redisplay'?

[dalanicolai]

[-- Attachment #1: Type: text/plain, Size: 3095 bytes --]

Thanks I have now found that I could add the window-start and
window-end (explicitly passing a non-nil update argument) part to the
'window-scroll-functions', which seems usable to me because I want to
call those functions after every scrolling action in the buffer.

However, the 'window-scroll-functions' docstring says that the value
of window-end is not valid in such a function, which indeed it is not
without passing the update argument. Could it be that the value of
window-end actually is valid when passing the update argument, as it
appears to be?

On Mon, 6 Nov 2023 at 14:59, dalanicolai <dalanicolai@gmail.com> wrote:

> Hi all!
>
> I am trying to use the functions window-start and window-end, within a
> function that gets called from the window-configuration-change-hook as
> follows:
>
> (defun test ()
>>   (interactive)
>>   (let ((inhibit-read-only t))
>>     (dotimes (i 9)
>>       (let ((o (make-overlay (point) (progn (insert " ") (point)))))
>> (insert "\n")
>> (overlay-put o 'face `(:background ,(pcase (% i 3)
>>      (0 "red")
>>      (1 "green")
>>      (2 "blue"))))
>> (overlay-put o 'display '(space . (:width (600) :height (800))))
>> (overlay-put o 'window (selected-window))))
>>     (when (looking-back "\n")
>>       (delete-char -1)))
>>   (goto-char 7)
>>
>>   (print (current-buffer) #'external-debugging-output)
>>   (print (window-buffer (selected-window)) #'external-debugging-output)
>>   (print (point) #'external-debugging-output)
>>
>>   (force-window-update (selected-window))
>>   (redisplay t)
>>
>>   (print (window-start) #'external-debugging-output)
>>   (print (window-end nil t) #'external-debugging-output))
>>
>>
>> (define-derived-mode test-mode special-mode "Test"
>>   "Debug"
>>   (add-hook 'window-configuration-change-hook #'test nil t))
>>
>> (add-to-list 'auto-mode-alist '("\\.debug\\'" . test-mode))
>>
>
> The above test function creates some 'space overlays' after which it
> tries to determine the actual 'displayed' overlays by using
> window-start and window-end. It prints debugging output to the
> terminal (it is printing to the terminal because printing elsewhere
> makes debugging redisplay issues more complicated).
>
> Now when invoking the command manually in some buffer, the functions
> window-start and window-end, work correctly, i.e. window-start returns
> the same value as point (both 7, after the goto-char 7). Actually
> using a simple '(redisplay)' before window-start is sufficient.
>
> However, when triggering the function from the
> 'window-configuration-change-hook' (for that simply 'visit a new file'
> ending with a '.debug' extension), the window-start and window-end
> functions seem unusable; i.e even after adding
>
>   (force-window-update (selected-window))
>>   (redisplay t)
>>
>
> before using them, window-start still returns 1 while point is at 7.
>
> I conclude that I can not redisplay during a redisplay this way.
> Would it be possible to get the 'correct' values using window-start
> and window-end during a redisplay/from the
> 'window-configuration-change-hook'?
>
> Thanks
>
>

[-- Attachment #2: Type: text/html, Size: 4129 bytes --]

Re: Is it somehow possible to meaningfully use window-start during a 'redisplay'?

[Eli Zaretskii]

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Mon, 6 Nov 2023 15:25:39 +0100
> 
> However, the 'window-scroll-functions' docstring says that the value
> of window-end is not valid in such a function, which indeed it is not
> without passing the update argument. Could it be that the value of
> window-end actually is valid when passing the update argument, as it
> appears to be?

In most cases, when you call window-end with UPDATE argument non-nil,
the value will be valid, but I don't recommend relying on that without
testing, especially when all kinds of non-default modes and hooks are
around that can invalidate the window's end.

Why do you need to know the window-end position in a window-scroll
function?  Why cannot you access it in some other way?