bug#23568: 25.0.94; Mode line menus appear incorrectly in some monitor configurations

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Date: Fri, 02 Jun 2017 18:54:03 -0600
>> Cc: 23568@debbugs.gnu.org

>> Don't you want to throw an error when x and y are used, but are not
>> integers?
>
> If this is supposed to be used as part of mode-line display, then no.
> Signaling errors in the middle of redisplay is generally a bad idea,
> because they cause another redisplay cycle, which again signals an
> error, and Emacs just freezes.

I see. In the general case, is it recommended to silently fallback to a
different method, or should there be a log message?

I changed the procedure so that it only uses the coordinates if they're
numbers.

>> +(defun display-monitor-attribute (attribute &optional display x y)
>> +  "Return the value of the ATTRIBUTE of the current monitor.
>
> The doc string should say something about what "the current monitor"
> means, or have a link to where that is explained.

I expanded that section, copying a chunk of it from
`frame-monitor-attributes'.

>> +DISPLAY can be a display name, a terminal name, or a frame.
>
> "Terminal name" or "terminal object"?

`display-monitor-attributes' can take both, which is where I copied that
line from.

I don't think I should have done that, actually. I don't believe this
function makes sense for a terminal/display input, as a
terminal/display, as I understand it, can have multiple physical
monitors.

I changed all instances of `display' to `frame'. I'm still not sure on
the name, though. Perhaps a better prefix would be `physical-monitor-*',
or just `monitor-*'?

What do you think?

>> diff --git a/src/xmenu.c b/src/xmenu.c
>> index 2805249164..04d5bde2ba 100644
>> --- a/src/xmenu.c
>> +++ b/src/xmenu.c
>
> Why is this in xmenu.c?  Is the problem unique to X window system?

The xmenu.c part contains the actual bugfix, while the frame.el part is
just a partial abstraction for the fix so that other procedures can use
it (such as compute_tip_xy in xfns.c).

The procedure I'm editing (menu_position_func) is inside an #ifdef
USE_GTK, and uses x_display_pixel_{height,width} currently. I'm not sure
if it's useful outside of X currently.

I haven't tested the issue on other systems, but I don't think it's an
issue in Windows as half of the code came from Windows code according to
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22549#61.

Here's an updated diff:

multi-headv4.diff
Description: v4