From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.bugs Subject: bug#5721: Feature request: Function that returns absolute coordinates Date: Thu, 15 Jul 2010 18:27:26 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1279186287 386 80.91.229.12 (15 Jul 2010 09:31:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Jul 2010 09:31:27 +0000 (UTC) Cc: 5721@debbugs.gnu.org To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 15 11:31:23 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKmo-0001LB-D9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Jul 2010 11:31:22 +0200 Original-Received: from localhost ([127.0.0.1]:49880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZKmn-0004cq-PZ for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Jul 2010 05:31:21 -0400 Original-Received: from [140.186.70.92] (port=53652 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZKlp-0004QR-Tf for bug-gnu-emacs@gnu.org; Thu, 15 Jul 2010 05:30:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZKlo-0001a3-Me for bug-gnu-emacs@gnu.org; Thu, 15 Jul 2010 05:30:21 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60618) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKlo-0001Zu-Jw for bug-gnu-emacs@gnu.org; Thu, 15 Jul 2010 05:30:20 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OZKja-0008Ju-AG; Thu, 15 Jul 2010 05:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: YAMAMOTO Mitsuharu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Jul 2010 09:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5721 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5721-submit@debbugs.gnu.org id=B5721.127918604531976 (code B ref 5721); Thu, 15 Jul 2010 09:28:02 +0000 Original-Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 09:27:25 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKix-0008Jh-7j for submit@debbugs.gnu.org; Thu, 15 Jul 2010 05:27:23 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKit-0008Jc-Tm for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 05:27:21 -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 ED651C0557; Thu, 15 Jul 2010 18:27:26 +0900 (JST) In-Reply-To: <4C3ECE08.2040604@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 =?UTF-8?Q?(Shij=C5=8D)?= APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 15 Jul 2010 05:28:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:38544 Archived-At: >>>>> On Thu, 15 Jul 2010 10:59:52 +0200, Jan Dj=E4rv = said: >>> That would require unscaled everywhere, even in pos-x-y, window >>> sizes, font sizes and so on. I didin't think that was your >>> suggestion. >>=20 >> No, they are all frame-relative, so scaled by the scaling factor. >>=20 >> The only places currently I can think of in the "absolute" category >> are the frame parameters `left' and `top', and some screen >> parameters such as `display-pixel-height', etc. Most of the values >> in Lisp are designed as frame-relative. > But many operations add and subtract from frame top, left and > display width/height. How many? I don't know, I just suspect that > there are many based on what I've seen when editing existing lisp > files in Emacs. Not to mention C files. Such operations are inherently relative-absolute conversions, and such tasks should be done by a special conversion function we are introducing. For most such use cases, we must take window decorations (including the title bar) by the window manager into account anyway, and the relative-scaled <-> absolute-unscaled conversion function will make it more accurate, concise, and makes the intention clear. >>>> Again, if we used absolute scaled coordinates to specify `left' >>>> and `top' frame parameters, we could only place the frame to the >>>> position whose coordinates are multiples of the scale factor. >>=20 >>> As I said earlier, special functions to deal with that for those >>> that care. >>=20 >> I don't understand. What happens if a user moved the frame to >> (101, 101) using the mouse under the scale factor 2, and he checked >> (frame-parameter nil 'left)? > Is 101 scaled or unscaled? If scaled, left would be 101. If not > scaled, left would be 50. Loss of precision? Sure, but does it > matter in most cases? Of course scaled. > Another idea would be if Emacs had its own internal coordinate > system, say 0.0 to 1.0 or some integer based one, that already is > display independent. It would fit nicely with the GnomeCanvas idea > (see other thread). A bunch of work though... What would happen to the absolute scaled coordinate system if scaling factors are different from frame to frame? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp