GNU bug report logs - #23568
25.0.94; Mode line menus appear incorrectly in some monitor configurations

Previous Next

Package: emacs;

Reported by: Alex <agrambot <at> gmail.com>

Date: Wed, 18 May 2016 02:29:01 UTC

Severity: normal

Found in version 25.0.94

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 23568 <at> debbugs.gnu.org
Subject: bug#23568: 25.0.94; Mode line menus appear incorrectly in some monitor configurations
Date: Sat, 03 Jun 2017 13:19:50 -0600
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Date: Fri, 02 Jun 2017 18:54:03 -0600
>> Cc: 23568 <at> 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 (text/x-diff, attachment)]

This bug report was last modified 7 years and 350 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.