Re: x-display-pixel-width/height inconsistency

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 23 Mar 2013 09:32:31 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> >>>>> On Fri, 22 Mar 2013 12:33:36 +0200, Eli Zaretskii <eliz@gnu.org> said:
> 
> > How did you deduce that SM_CXVIRTUALSCREEN and SM_CYVIRTUALSCREEN
> > are not available on those old systems?  Can you point me to some
> > documentation which has the details?
> 
> http://msdn.microsoft.com/ja-jp/library/cc429812.aspx
> (in Japanese.  But probably you can find "Window 98" and "Windows
> 2000" around SM_CXVIRTUALSCREEN/SM_CYVIRTUALSCREEN)

Does it say something like "Starting from Windows 98 and Windows
2000"?  That's what I get from other sources on the Internet that talk
about this subject.

> > If we do need to distinguish those systems, there's os_subtype
> > variable, which can help you be sure that you include both Windows
> > 9X and NT 4.0, as version info on 9X is somewhat tricky.
> 
> I think it is enough to distinguish Windows 95 and Windows NT 4.0 from
> the other versions, and both 95 and NT4 seem to have the same major
> and minor versions (4 and 0) maybe by accident, while they have
> different os_subtype values.  (Correct me if wrong.)

I actually think we should always call GetSystemMetrics, and if that
returns a failure indication, call the old code.  Testing versions is
usually less desirable.

> > I'm bothered by the fact that you change the behavior of these
> > functions in backward-incompatible ways, without properly
> > documenting what values they return.  The new doc strings do not add
> > _anything_ to the vagueness of the previous description wrt what
> > exactly are the "display dimensions".  Now, you may be right about
> > what these primitives do on X11 (I don't know enough about that to
> > tell, and the man pages I've seen are not helpful), but if so, we
> > should clearly document their semantics, either in the doc strings
> > or/and in the ELisp manual.  We certainly should mention the change
> > in behavior in NEWS.
> 
> As I've already mentioned, the elisp info already contains the
> description about the semantics under multi-monitor setups.
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00469.html

That talks about display-pixel-width/height, while I was talking about
x-display-pixel-width/height, the primitives where you propose the
changes.  The latter are not mentioned in the ELisp manual at all, so
their doc strings are the only source of documentation for them.

Moreover, your changes touch x-display-mm-width/height as well, so now
display-mm-width/height, whose documentation in the ELisp manual
doesn't mention multiple terminals at all, will behave differently as
well.

> > Personally, I am still unsure how will dimensions of "the bounding
> > rectangle of all display monitors" be helpful to any Lisp program;
> > can you tell why you think returning that is a good idea?  Maybe we
> > should change the X11 implementation instead?
> 
> Please look at my other posts:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00553.html
>   http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00555.html

I've read all the thread, and I'm still asking the question, because
nothing there seems to provide the answer.  Maybe you should re-read
my question.

What you say in those messages boils down to

  . the X11 behavior is documented in the manual

  . Emacs on X11 cannot distinguish between physical monitors that
    belong to the same display

As I write above, the first point is only partially true
(display-mm-width/height are not documented as describing the virtual
screen, and the x-display-* primitives are not documented at all).  As
for the second point, I don't see how it can be any guideline to make
a decision, since both NS and W32 _can_ distinguish between physical
monitors (if we include the appropriate code).

So the question still stands: which behavior should be considered
"correct" and which a "missing feature".