From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: x-display-pixel-width/height inconsistency Date: Sat, 23 Mar 2013 08:15:03 +0200 Message-ID: <83mwtu4p7c.fsf@gnu.org> References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1364019313 8334 80.91.229.3 (23 Mar 2013 06:15:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Mar 2013 06:15:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 23 07:15:39 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UJHjn-0003Xz-6Q for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2013 07:15:31 +0100 Original-Received: from localhost ([::1]:36253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJHjP-0003cu-5l for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2013 02:15:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJHjL-0003bC-MD for emacs-devel@gnu.org; Sat, 23 Mar 2013 02:15:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJHjJ-0003W6-Da for emacs-devel@gnu.org; Sat, 23 Mar 2013 02:15:03 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:52883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJHjI-0003Sw-W7 for emacs-devel@gnu.org; Sat, 23 Mar 2013 02:15:01 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MK300D00O0L8400@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sat, 23 Mar 2013 08:14:59 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK300DCXO0Y8300@a-mtaout21.012.net.il>; Sat, 23 Mar 2013 08:14:59 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158074 Archived-At: > Date: Sat, 23 Mar 2013 09:32:31 +0900 > From: YAMAMOTO Mitsuharu > Cc: emacs-devel@gnu.org > > >>>>> On Fri, 22 Mar 2013 12:33:36 +0200, Eli Zaretskii 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".