bug#61948: 29.0.60; window-at returns nil when tab-bar-mode is on

[Yuan Fu]

> On Mar 4, 2023, at 12:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 3 Mar 2023 19:02:06 -0800
>> 
>> To reproduce:
>> 
>> 1. Type C-x t 2 to turn on tab-bar-mode
>> 2. Evaluate (window-at 0 0), it returns nil
>> 3. Evaluating (window-at 50 50) also returns nil
>> 4. Turn off tab-bar-mode, and (window-at 0 0) returns a live window
>> 
>> window-at-x-y is the same
> 
> What did you expect the function to return instead in these cases?
> 
> Both of these functions ignore the tool-bar and the tab-bar
> pseudo-windows, so as long as the coordinates are inside those two
> windows, both functions return nil.  (This was not called out in their
> doc strings; I've now added this caveat to the doc strings of these
> two functions.)
> 
> So the call with both X and Y zero returns nil because that point is
> within the area of the frame where these functions always return nil.
> 
> As for the call with X and Y being 50, it returns nil for different
> reasons:
> 
>  . for window-at, X and Y are measured in columns and rows, so likely
>    Y = 50 is outside of the frame created by "emacs -Q";
>  . for window-at-x-y, Y = 50 is still inside the tab-bar
>    pseudo-window; on my system using Y = 53 or larger returns the
>    window showing *scratch*; it could be that the threshold value on
>    your system is a bit different
> 
> Given the above, do you still think there's a bug here?  If so, please
> describe the real use case where you needed this.
> 
> Thanks.

Ah! Should’ve tried (window-at-x-y 100 100). In my brain 50 pixels is pretty 
far so I thought (50 . 50) must be in a window.

Indeed, it’s a false alarm. Sorry for the noise. 

Yuan