Re: Making TTY menus more visual

[Jared Finder via "Emacs development discussions." <emacs-devel@gnu.org>]

On 2020-10-13 7:33 am, Eli Zaretskii wrote:
>> Date: Mon, 12 Oct 2020 14:30:38 -0700
>> From: Jared Finder <jared@finder.org>
>> Cc: emacs-devel@gnu.org
>> 
>> The manual is not clear of the format of a posn for clicks outside a
>> window, such as on the menu bar or tab bar. From the behavior I see,
>> posn-window will return nil and posn-x-y will return (x . y) in frame
>> coordinates. I rely on that in this patch. If this is accurate, I can
>> update the manual.
> 
> Are you sure posn-window cannot return a frame?  For example, on a
> TTY, I get this:
> 
>   (posn-at-x-y 0 0 (selected-frame))
>    => (#<frame F1 069b0190> nil (0 . 0) 0)
> 
> And (0,0) are coordinates in the frame's menu bar.

A ha! A bug! Behavior is different depending on options selected at 
configure time.

Behavior with ./configure --with-x=no:
(posn-at-x-y 0 0 (selected-frame))
=> (nil nil (0 . 0) 0)
(selected-frame)
=> #<frame F1 0x55be32685d38>

Behavior with ./configure --with-x=yes:
(posn-at-x-y 0 0 (selected-frame))
=> (#<frame F1 0x561fedbc6b98> nil (0 . 0) 0)
(selected-frame)
=> #<frame F1 0x561fedbc6b98>

This bug has been around a while, on Debian (Emacs 26.1), emacs-no-x vs 
emacs-gtk shows the same difference in behavior.

Do you have a preference for a fix? Some options:

#1) If I was designing the API from scratch, I'd expect something like 
the following:

A function posn-window returns a window or nil if the coordinate is 
outside of any window.
A function posn-frame returns a frame. Always succeeds, since posn 
coordinates are always inside a frame.

This is compatible with --with-x=no behavior.

#2) An alternative would be to return "most specific information 
available". Something like the following:

A function posn-window-or-frame, which returns a window if the 
coordinate is inside a window and returns a frame if the coordinate is 
outside a window.
A deprecated alias posn-window for the function above.

This is compatible with --with-x=yes behavior.

I found at one other behavior difference, if you pass in out of bounds 
coordinates (example: 1000 0 for a TTY), --with-x=no you get the value 
as if you passed in 0 0, but --with-x=yes assumes the coordinate is 
valid. There are probably other differences. I can do a pass over this 
function, I'd like to know the razor to use.

> Does it make sense to install this patch on its own?  If so, we can
> install it without waiting for the legal paperwork, the changes are
> small enough.

Yes, the issue existed prior to my changes when using TMM in a terminal.

   -- MJF