From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Negative positions in frame parameters Date: Tue, 13 Apr 2010 10:02:42 -0700 Message-ID: References: <4BC4829D.5010202@swipnet.se><87ochns79i.fsf@lola.goethe.zz> <4BC49C58.8050303@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1271178219 18845 80.91.229.12 (13 Apr 2010 17:03:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 17:03:39 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 19:03:37 2010 Return-path: Envelope-to: ged-emacs-devel@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 1O1jWT-0005WX-7J for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 19:03:37 +0200 Original-Received: from localhost ([127.0.0.1]:41121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1jWS-0002Su-OU for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 13:03:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1jWN-0002Sk-7h for emacs-devel@gnu.org; Tue, 13 Apr 2010 13:03:31 -0400 Original-Received: from [140.186.70.92] (port=35413 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1jWK-0002Ry-LG for emacs-devel@gnu.org; Tue, 13 Apr 2010 13:03:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1jWI-00024d-9N for emacs-devel@gnu.org; Tue, 13 Apr 2010 13:03:28 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:59558) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1jWI-00024R-0m for emacs-devel@gnu.org; Tue, 13 Apr 2010 13:03:26 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3DH3NrI023095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Apr 2010 17:03:24 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3D7IbAM010279 for ; Tue, 13 Apr 2010 17:03:21 GMT Original-Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 171358001271178164; Tue, 13 Apr 2010 10:02:44 -0700 Original-Received: from dradamslap1 (/141.144.233.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Apr 2010 10:02:43 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BC49C58.8050303@swipnet.se> Thread-Index: AcrbJttrmkJlSIRSQg2yF4kRd8d5FAAAu7NQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BC4A3DA.008A:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123583 Archived-At: FWIW, I've been using the following functions forever, to make life simpler when trying to deal with the different possible representations that Emacs functions might return. I use this, for example, to move frames around incrementally. (To increment a value it needs to be in numeric form.) The functions are also here, in case mail wraparound makes them difficult to read: http://www.emacswiki.org/emacs/frame-fns.el ---- (defun frame-geom-value-numeric (type value &optional frame) "Return equivalent geometry value for FRAME in numeric terms. A geometry value equivalent to VALUE for FRAME is returned, where the value is numeric, not a consp. TYPE is the car of the original geometry spec (TYPE . VALUE). It is `top' or `left', depending on which edge VALUE is related to. VALUE is the cdr of a frame geometry spec: (left/top . VALUE). If VALUE is a consp, then it is converted to a numeric value, perhaps relative to the opposite frame edge from that in the original spec. FRAME defaults to the selected frame. Examples (measures in pixels) - Assuming display height/width=1024, frame height/width=600: 300 inside display edge: 300 => 300 (+ 300) => 300 300 inside opposite display edge: (- 300) => -300 -300 => -300 300 beyond display edge (= 724 inside opposite display edge): (+ -300) => -724 300 beyond display edge (= 724 inside opposite display edge): (- -300) => 724 In the last two examples, the returned value is relative to the opposite frame edge from the edge indicated in the input spec." (if (consp value) (if (natnump (cadr value)) ;; e.g. (+ 300) or (- 300) => 300 or -300 (funcall (car value) (cadr value)) ;; e.g. (+ -300) or (- -300) (let ((oppval (- (if (eq 'left type) (x-display-pixel-width) (x-display-pixel-height)) (cadr value) (if (eq 'left type) (frame-pixel-width frame) (frame-pixel-height frame))))) (if (eq '+ (car value)) (- oppval) ; e.g. (+ -300) => -724 oppval))) ; e.g. (- -300) => 724 ;; e.g. 300 or -300 value)) (defun frame-geom-spec-numeric (spec &optional frame) "Return equivalent geometry specification for FRAME in numeric terms. A geometry specification equivalent to SPEC for FRAME is returned, where the value is numeric, not a consp. SPEC is a frame geometry spec: (left . VALUE) or (top . VALUE). If VALUE is a consp, then it is converted to a numeric value, perhaps relative to the opposite frame edge from that in the original SPEC. FRAME defaults to the selected frame. Examples (measures in pixels) - Assuming display height=1024, frame height=600: top 300 below display top: (top . 300) => (top . 300) (top + 300) => (top . 300) bottom 300 above display bottom: (top - 300) => (top . -300) (top . -300) => (top . -300) top 300 above display top (= bottom 724 above display bottom): (top + -300) => (top . -724) bottom 300 below display bottom (= top 724 below display top): (top - -300) => (top . 724) In the last two examples, the returned value is relative to the opposite frame edge from the edge indicated in the input SPEC." (cons (car spec) (frame-geom-value-numeric (car spec) (cdr spec)))) (defun frame-geom-value-cons (type value &optional frame) "Return equivalent geometry value for FRAME as a cons with car `+'. A geometry value equivalent to VALUE for FRAME is returned, where the value is a cons with car `+', not numeric. TYPE is the car of the original geometry spec (TYPE . VALUE). It is `top' or `left', depending on which edge VALUE is related to. VALUE is the cdr of a frame geometry spec: (left/top . VALUE). If VALUE is a number, then it is converted to a cons value, perhaps relative to the opposite frame edge from that in the original spec. FRAME defaults to the selected frame. Examples (measures in pixels) - Assuming display height/width=1024, frame height/width=600: 300 inside display edge: 300 => (+ 300) (+ 300) => (+ 300) 300 inside opposite display edge: (- 300) => (+ 124) -300 => (+ 124) 300 beyond display edge (= 724 inside opposite display edge): (+ -300) => (+ -300) 300 beyond display edge (= 724 inside opposite display edge): (- -300) => (+ 724) In the 3rd, 4th, and 6th examples, the returned value is relative to the opposite frame edge from the edge indicated in the input spec." (cond ((and (consp value) (eq '+ (car value))) ; e.g. (+ 300), (+ -300) value) ((natnump value) (list '+ value)) ; e.g. 300 => (+ 300) (t ; e.g. -300, (- 300), (- -300) (list '+ (- (if (eq 'left type) ; => (+ 124), (+ 124), (+ 724) (x-display-pixel-width) (x-display-pixel-height)) (if (integerp value) (- value) (cadr value)) (if (eq 'left type) (frame-pixel-width frame) (frame-pixel-height frame))))))) (defun frame-geom-spec-cons (spec &optional frame) "Return equivalent geometry spec for FRAME as a cons with car `+'. A geometry specification equivalent to SPEC for FRAME is returned, where the value is a cons with car `+', not numeric. SPEC is a frame geometry spec: (left . VALUE) or (top . VALUE). If VALUE is a number, then it is converted to a cons value, perhaps relative to the opposite frame edge from that in the original spec. FRAME defaults to the selected frame. Examples (measures in pixels) - Assuming display height=1024, frame height=600: top 300 below display top: (top . 300) => (top + 300) (top + 300) => (top + 300) bottom 300 above display bottom: (top - 300) => (top + 124) (top . -300) => (top + 124) top 300 above display top (= bottom 724 above display bottom): (top + -300) => (top + -300) bottom 300 below display bottom (= top 724 below display top): (top - -300) => (top + 724) In the 3rd, 4th, and 6th examples, the returned value is relative to the opposite frame edge from the edge indicated in the input spec." (cons (car spec) (frame-geom-value-cons (car spec) (cdr spec))))