GNU bug report logs - #75936
monitor width reporting

Previous Next

Full log

View this message in rfc822 format

From: "david" <david <at> ngdr.net>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, rudalics <at> gmx.at, 75936 <at> debbugs.gnu.org
Subject: bug#75936: monitor width reporting
Date: Sat, 01 Feb 2025 13:21:17 -0700

> If one of the builds is with XRandR and the other without, then the
> differences in the results are expected, and this is not a bug.

I am rather shocked that you do not see this as a bug.  Personally, I see
it as definitional.  Two apparently identical builds that give different
results for display geometry does not indicate a bug?  How about garbled
output, displayed to a remote user, simply because the user's build is
different, albeit not advertised as such, from the software creator's
build?  That sort of performance is not good for the reputation of Emacs I
can assure you.

At the very least, the build information should indicate the difference.
It happens that I have just carried out a re-build because I realized that
one build had been done with cairo, the other not, and the display was poor
in one case.  And I read the difference in the build information.  If the
build information in the current case had shown a difference, I should have
investigated.

I think it is worth pointing out that you did not know why there is a
problem, even with the debug output in front of you.  Fortunately someone
else had the right knowledge.  Given that, it seems to me that to assert
"the differences in the results are expected" is somewhat disingenuous.

Also, I think that it is worth pointing out that I have absolutely zero
knowledge of XRandR, just like most people.  I have no idea how it was
involved in a build; I am confident that I did not choose to use it, unless
directed to it by the output from configure.  There is a mention of
information sources, including XRandR, in *note:(elisp)Multiple Terminals,
otherwise the mention does not help.

A better solution than only providing, important, build information would
be also to address comprehension problems such as the combination of the
output of (display-screens) and the geometry provided in the output of
(frame-monitor-attributes).  The documentation "This function returns the
attributes of the physical monitor dominating (see above) FRAME, which
defaults to the selected frame." is misleading when the actual information
on a two monitor setup is the attributes of both monitors, reported as one
combined-screen by (display-screens), not, in fact, the attributes of the
dominating monitor.

So, leaving out a lot of detail, it comes back to the build: with or
without XRandR.  Without is inadequate; it turns out that build information
is not important, it is vital.  Alternatively, when writing software it is
necessary to rely on non-software knowledge, e.g., usual screen sizes.  The
latter is what I do now: since the screen height is constant (assumption)
the screen aspect ratio (what I am trying to establish) is not likely to be
less than 1.24 nor more than 2.5.  Since the reported width changes by a
factor of 2 it is not difficult to get it right.  But it will go wrong at
some point.

So you and I have different definitions of a bug.  I see why you take the
view you do; but it is narrow and unhelpful to someone writing user
software.  Crashing Emacs software is a bug for me.  Flagging build
characteristics at least gives a warning.

Previous Next

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