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: display.texi: (,) isn't documented. Date: Thu, 7 Jun 2007 14:20:54 -0700 Message-ID: References: <20070607202624.GA1264@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1181251429 14825 80.91.229.12 (7 Jun 2007 21:23:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 7 Jun 2007 21:23:49 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 07 23:23:48 2007 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.50) id 1HwPSO-00089A-8M for ged-emacs-devel@m.gmane.org; Thu, 07 Jun 2007 23:23:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HwPSN-0003NA-H1 for ged-emacs-devel@m.gmane.org; Thu, 07 Jun 2007 17:23:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HwPRK-00039O-Fg for emacs-devel@gnu.org; Thu, 07 Jun 2007 17:22:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HwPRJ-00038q-07 for emacs-devel@gnu.org; Thu, 07 Jun 2007 17:22:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HwPRI-00038l-Hf for emacs-devel@gnu.org; Thu, 07 Jun 2007 17:22:40 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HwPRI-0001OD-4I for emacs-devel@gnu.org; Thu, 07 Jun 2007 17:22:40 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l57LMaBN013725 for ; Thu, 7 Jun 2007 16:22:36 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l57KxXpH028247 for ; Thu, 7 Jun 2007 15:22:35 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt350.oracle.com with ESMTP id 2833904671181251260; Thu, 07 Jun 2007 14:21:00 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20070607202624.GA1264@muc.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 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:72440 Archived-At: > > I think explicit units help, and are consistent and clear also > > when only one unit is used (25c). I think they should be placed > > after the numbers, not before: 1225. > > So, 12L25C or 12l25c or 12y25x or some > > such. If we can spare a space, then it is even more readable: 12L 25C. > > "Lines" and "Columns" here aren't units - they're identifying > information. If the cursor is on L168, that's in no way 4 times its > being on L42. Perhaps it depends on how you interpret "L" or "lines". 168 lines from buffer top edge is exactly 4 times as far from buffer that edge as is 42 lines (modulo existence of header lines etc.). 50 columns from buffer left edge is 5 times as many columns as is 10 columns from that edge. "Line" as a unit here means line height (including, perhaps, inter-line spacing). You could even define this unit in terms of points or pixels (you agree that they are units, right?). It a relative unit, of course, defined in terms of `frame-char-height' (again, perhaps + inter-line spacing), so that 1 line in buffer foo might be 14 pixels and 1 line in buffer bar might be 10 pixels. And of course pixel is itself a relative unit, depending on monitor ppi... Likewise, for column and `frame-char-width'. A better argument might be to say that 25x 50y does not refer to 25 x units and 50 y units (which is why I spoke of x and y directions in that case, and of x and y as standing for horizontal and vertical). I really don't care which word you want to use: "unit", "label", "bizdink". If my write-the-units-after-the-quantities argument doesn't make sense to you in this context, that's OK. > As an analogy, you might live at "flat 15" in a block of > flats. That's not "15 flats", it's not a unit of measurement; it's > merely a label, and if building work happened, you might suddenly find > yourself living at "flat 30", for which you wouldn't want to pay twice > the rent. 30 flats from block edge (zero) - what's the problem? Now, if the street addresses of two successive flats are not consecutive, then there is perhaps a non-linear or even a bizarre relation between flat units and address units, but that doesn't invalidate either as a unit. I don't see the contradiction you see - or the relation between flat units and duobled rent. Perhaps your whole post was meant as humor and I'm just not getting it? I'm just hoping I understand "flat" correctly ;-). > You might tell a visitor to come in through the front door, up > the stairs, then you live at the third flat on the left. Here, "flat" IS > being used as a unit. > > Note the difference in order: "flat 15" vs. "the third flat". My monitor is 3 inches from the table edge (third inch from the edge) and 15 inches from the wall (inch 15 from the wall). So what?