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

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

[Yuan Fu]

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


In GNU Emacs 29.0.60 (build 58, x86_64-apple-darwin22.3.0, NS
appkit-2299.40 Version 13.2.1 (Build 22D68)) of 2023-03-01 built on
Brown
Repository revision: 59365f928565f1be551b1697b9246b00cb87a9b7
Repository branch: emacs-29
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.2.1

Configured features:
ACL DBUS GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER
PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils shortdoc text-property-search help-fns
radix-tree time-date subr-x cl-extra help-mode icons cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 46845 11136)
(symbols 48 5645 0)
(strings 32 14791 2011)
(string-bytes 1 398282)
(vectors 16 10157)
(vector-slots 8 156538 31644)
(floats 8 80 19)
(intervals 56 649 42)
(buffers 984 14))

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

[Eli Zaretskii]

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

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