From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: x-display-pixel-width/height inconsistency Date: Sun, 24 Mar 2013 08:58:29 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> <83mwtu4p7c.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1364083124 14513 80.91.229.3 (23 Mar 2013 23:58:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Mar 2013 23:58:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 24 00:59:10 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 1UJYL7-0003gz-Vw for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 00:59:10 +0100 Original-Received: from localhost ([::1]:50423 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJYKk-0004Pr-6c for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2013 19:58:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJYKe-0004Oz-GK for emacs-devel@gnu.org; Sat, 23 Mar 2013 19:58:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJYKb-0000sG-Fx for emacs-devel@gnu.org; Sat, 23 Mar 2013 19:58:40 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:50547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJYKZ-0000qh-5R; Sat, 23 Mar 2013 19:58:35 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 8B667C055D; Sun, 24 Mar 2013 08:58:29 +0900 (JST) In-Reply-To: <83mwtu4p7c.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 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:158097 Archived-At: >>>>> On Sat, 23 Mar 2013 08:15:03 +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. It says "Window 98 AND Windows 2000". Probably because this document was written before XP or Me. > 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. Could you check GetSystemMetrics safely returns 0 for unknown arguments (because I can't test it)? If so, avoiding version tests would be better. >> 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. If these functions behave differently among the platforms on multi-monitor setups, then they should be named with different prefixes (i.e., w32-display-*, ns-display-*. Note that the current behavior is different even between W32 and NS). Of course, I prefer consistent behavior rather than having the different prefix. >> 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". My whole point is that functions for obtaining properties of each physical monitor on multi-monitor setups should be provided as a new function (or a new group of functions), rather than abusing the existing functions x-display-* on displays primarily designed after the notion of X11 "display" or "screen". Users would want to know several kinds of information about each monitor, such as the geometry (including the origin) or the workarea, not just about size in pixels. Tweeking x-display-pixel-width/height in a platform-specific way or adding functions such as display-usable-bounds in the NS port without considering the whole design for operations on monitors looks rather ad hoc to me. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp