From unknown Mon Sep 08 20:52:11 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#4654 <4654@debbugs.gnu.org> To: bug#4654 <4654@debbugs.gnu.org> Subject: Status: 23.1; Elisp manual doc of abbreviate-file-name Reply-To: bug#4654 <4654@debbugs.gnu.org> Date: Tue, 09 Sep 2025 03:52:11 +0000 retitle 4654 23.1; Elisp manual doc of abbreviate-file-name reassign 4654 emacs submitter 4654 "Drew Adams" severity 4654 normal thanks From drew.adams@oracle.com Tue Oct 6 10:54:02 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Oct 2009 17:54:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96Hs0aT010805 for ; Tue, 6 Oct 2009 10:54:01 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvEEa-00025E-78 for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 13:54:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvEEV-0001ug-9p for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 13:53:59 -0400 Received: from [199.232.76.173] (port=48319 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvEEV-0001uK-5q for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 13:53:55 -0400 Received: from acsinet12.oracle.com ([141.146.126.234]:25785) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MvEEU-0004Jo-JY for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 13:53:54 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n96Hp57o023910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Oct 2009 17:51:06 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n968ccxi014283 for ; Tue, 6 Oct 2009 17:54:39 GMT Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 20239367761254851628; Tue, 06 Oct 2009 10:53:48 -0700 Received: from dradamslap1 (/141.144.169.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Oct 2009 10:53:48 -0700 From: "Drew Adams" To: Subject: 23.1; Elisp manual doc of abbreviate-file-name Date: Tue, 6 Oct 2009 10:54:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpGrgFj3lL4ybh8TDu0xAfvOXYX+g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4ACB842D.01C8:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) The doc string mentions this qualification, but the Elisp manual does not: " (unless the home directory is a root directory)". Please mention this in the manual also. Question: Why? What is the rationale for not substituting `~' when it is a root directory? If the reason is short to express, perhaps it should be included in the doc. Understanding the rationale helps one remember what the function does. In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-29 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' From monnier@IRO.UMontreal.CA Tue Oct 6 13:22:03 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Oct 2009 20:22:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96KM2w3004405 for ; Tue, 6 Oct 2009 13:22:03 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvGXp-0008Sz-QS for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 16:22:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvGXk-0008M4-1K for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 16:22:00 -0400 Received: from [199.232.76.173] (port=32857 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvGXj-0008Lv-Nq for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 16:21:55 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:40449) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvGXj-0008VQ-G4 for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 16:21:55 -0400 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n96KLF44022119; Tue, 6 Oct 2009 16:21:15 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 4D0BA3A23A; Tue, 6 Oct 2009 16:21:15 -0400 (EDT) From: Stefan Monnier To: Drew Adams Cc: 4654@debbugs.gnu.org, Subject: Re: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Message-ID: References: Date: Tue, 06 Oct 2009 16:21:15 -0400 In-Reply-To: (Drew Adams's message of "Tue, 6 Oct 2009 10:54:09 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3378=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) > Question: Why? What is the rationale for not substituting `~' when it > is a root directory? If the reason is short to express, perhaps it > should be included in the doc. Understanding the rationale helps one > remember what the function does. "a root directory" means "/". The reason is that substituting "/" for "~" doesn't really abbreviate anything. If anythingn to me it "looks" longer because I expect ~ to expand to something longer. Stefan From drew.adams@oracle.com Tue Oct 6 15:14:34 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Oct 2009 22:14:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96MEXsG023037 for ; Tue, 6 Oct 2009 15:14:34 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvIIi-00071S-HJ for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 18:14:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvIIc-0006xD-Ns for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 18:14:31 -0400 Received: from [199.232.76.173] (port=57817 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvIIc-0006xA-Iq for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 18:14:26 -0400 Received: from rcsinet12.oracle.com ([148.87.113.124]:37064 helo=rgminet12.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MvIIc-0000UH-8G for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2009 18:14:26 -0400 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n96MDu4h006080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Oct 2009 22:13:58 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n96MEewd006132; Tue, 6 Oct 2009 22:14:46 GMT Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 20245941891254867233; Tue, 06 Oct 2009 15:13:53 -0700 Received: from dradamslap1 (/141.144.169.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Oct 2009 14:12:28 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4654@debbugs.gnu.org>, References: Subject: RE: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Date: Tue, 6 Oct 2009 14:12:51 -0700 Message-ID: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpGwvRQNmd20svrSNu03VBTd9ykLwAAY5lw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4ACBC137.000B:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-CrossAssassin-Score: 2 > > Question: Why? What is the rationale for not substituting > > `~' when it is a root directory? If the reason is short to > > express, perhaps it should be included in the doc. > > Understanding the rationale helps one remember what the > > function does. > > "a root directory" means "/". The reason is that substituting "/" for > "~" doesn't really abbreviate anything. If anythingn to me it "looks" > longer because I expect ~ to expand to something longer. 1. Don't tell me; put it in the doc., please. ;-) That's the point of the bug report. I would add that the doc could be a tiny bit clearer that the expanded form of the home dir is replaced by ~, and not vice versa. The current phrasing ("substitutes "~" for the user's home directory") is correct, but many people routinely misread such phrases. (You yourself just made this mistake, for example: You said "substituting / for ~", when you presumably meant "substituting ~ for /".) In particular, it is not uncommon for people to incorrectly substitute "replace" for "substitute". Using "replace" here (and reversing the order) is likely to be a bit clearer. Clarity would be enhanced further by adding a simple example. 2. FWIW, I don't have a set opinion on this, but I lean toward saying that this exception for a root homedir should in fact be removed. Why? Because `~' lets you know that it _is_ the home directory. ~/foo/ tells you that foo is directly under the home directory. On the other hand, /foo/ tells you that foo is directly under the root, which ~/foo/ does not tell you. This goes along with what you were saying about expecting ~ to expand to something longer. ~ tells you that you are at the home dir, but it doesn't tell you where that is. Each side thus has a legitimate argument that additional info is provided. But it's not a toss-up, since the _purpose_ of the function is to use ~. That, and also the elimination of a shaky exception (Occam's razor), is why I lean toward always using ~, even for a root homedir. Finally, the one-char length difference argument should be irrelevant here. And on Windows the length argument actually goes the other way: ~ is shorter than c:\\. Anyway, this bug report is about the doc - please clear that up. From monnier@iro.umontreal.ca Tue Oct 6 22:47:36 2009 Received: (at 4654) by emacsbugs.donarmstrong.com; 7 Oct 2009 05:47:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n975lZTh002243 for <4654@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 22:47:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAPfHy0pMCqug/2dsb2JhbACBUdMShCoEhzQ X-IronPort-AV: E=Sophos;i="4.44,517,1249272000"; d="scan'208";a="47219969" Received: from 76-10-171-160.dsl.teksavvy.com (HELO ceviche.home) ([76.10.171.160]) by ironport2-out.pppoe.ca with ESMTP; 07 Oct 2009 01:47:30 -0400 Received: by ceviche.home (Postfix, from userid 20848) id D73ADB4190; Wed, 7 Oct 2009 01:47:29 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <4654@debbugs.gnu.org> Subject: Re: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Message-ID: References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> Date: Wed, 07 Oct 2009 01:47:29 -0400 In-Reply-To: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> (Drew Adams's message of "Tue, 6 Oct 2009 14:12:51 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > ~/foo/ tells you that foo is directly under the home directory. Actually, you can see right there: "~/foo" is longer than "/foo", so it would be wrong for abbreviate-file-name to do such a replacement, since it wouldn't abbreviate. > it's not a toss-up, since the _purpose_ of the function is to use ~. No it's not. The purpose is to abbreviate, i.e. make shorter. > Anyway, this bug report is about the doc - please clear that up. Patch welcome. I myself have no idea what wording would please you better, and the current wording is crystal clear to my mind. Stefan From drew.adams@oracle.com Wed Oct 7 00:54:18 2009 Received: (at 4654) by emacsbugs.donarmstrong.com; 7 Oct 2009 07:54:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n977sHG3025672 for <4654@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 00:54:18 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n977s6LL006270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Oct 2009 07:54:08 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n96I1DHF009173; Wed, 7 Oct 2009 07:54:47 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 20251411821254901816; Wed, 07 Oct 2009 00:50:16 -0700 Received: from dradamslap1 (/141.144.169.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Oct 2009 00:50:15 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4654@debbugs.gnu.org> References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> Subject: RE: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Date: Wed, 7 Oct 2009 00:50:41 -0700 Message-ID: <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpHEbKbmipgURx2RsSEpTmZShbUmgACngmw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4ACC491D.01A7:SCFMA4539814,ss=1,fgs=0 > > ~/foo/ tells you that foo is directly under the home directory. > > Actually, you can see right there: "~/foo" is longer than "/foo", Yes, you already said that once, and I already agreed with it once. Let me agree with it again: it is one character longer. So it is not strictly an abbreviation. I cannot argue with that. However, there is nothing about this function that is necessarily abbreviation. It is only in a general, average, overall, figurative sense that this function performs abbreviation. > so it would be wrong for abbreviate-file-name to do such a > replacement, since it wouldn't abbreviate. That's being a bit too black-and-white, don't you think? In that case, it is even more "wrong" to return c:\\foo instead of ~/foo, which is what we do now on Windows. That's 3 chars longer, a threefold worsening of your non-shortening problem. ;-) (Yes, I said that before too, but it apparently had no effect on your must-be-shorter argument.) The point is that unless you want the function to do somthing different in this regard (home-dir replacement) on different platforms, strictly applying a criterion of abbreviation in the sense of shortening is not TRT. In this case (HOME as root) at least, we should decide based on something other than simply whatever is shorter. The stated feature of "abbreviation" for this function has two aspects: (1) substituting a defined "abbreviation" from `directory-abbrev-list' - which is _not_ necessarily shorter than what it replaces, in fact, and (2) substituting `~' for the home dir. Neither aspect is always abbreviation in the sense of using something shorter. IOW, the word "abbreviation" is used wrt this function only in a vague, suggestive way. It cannot be seen as substitution of something necessarily shorter. Nit-picking about a string being one-character longer is beside the point. > > it's not a toss-up, since the _purpose_ of the function is to use ~. > > No it's not. The purpose is to abbreviate, i.e. make shorter. No, it's not. And it cannot be, in general - see above. The stated purpose of the function is two-fold: (1) substitute a defined alias (we call it an "abbreviation", but it is not necessarily shorter than what it replaces), and (2) substitute `~' for the home dir (which is likewise not necessarily abbreviation in the sense of replacement by something shorter, at least on Windows). The substitution we use should have the merits of (a) telling users something (which is why I pointed out the advantages of both approaches in terms of providing additional information) and (b) being consistent. a. Always substituting `~' for the home dir is consistent; and it tells you where the file is wrt the home dir. b. Substituting `~' for the home dir except when it is the root dir breaks consistency; but it does tell you where the file is wrt root (in that one exceptional case only - otherwise, it tells you where the file is wrt the home dir). It also has the advantage of legacy: consistency with the past and existing code. c. If we were to substitute `~' for the home dir except when that is the root dir, on UNIX etc., but not substitute it for the home dir when that is the root dir, on Windows, that would ensure that `~' substitution would always shorten the file name. But that would introduce additional inconsistency. And in any case, substituting using `directory-abbrev-alist' does not guarantee shortening at all. Nothing prevents such "abbreviation" from lengthening the name. Overall, (a) is a better choice than (b) or (c) - unless the legacy consideration has particular importance here for some reason (I don't think it does). From eliz@gnu.org Wed Oct 7 03:24:04 2009 Received: (at 4654-done) by emacsbugs.donarmstrong.com; 7 Oct 2009 10:24:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.8 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout3.012.net.il (mtaout3.012.net.il [84.95.2.7]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n97AO2G4021692 for <4654-done@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 03:24:04 -0700 Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KR5005003G5RM00@i_mtaout3.012.net.il> for 4654-done@emacsbugs.donarmstrong.com; Wed, 07 Oct 2009 12:23:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.224.43]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KR500LQL3JUOSF0@i_mtaout3.012.net.il>; Wed, 07 Oct 2009 12:23:55 +0200 (IST) Date: Wed, 07 Oct 2009 12:21:55 +0200 From: Eli Zaretskii Subject: Re: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name In-reply-to: <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , 4654-done@debbugs.gnu.org Cc: monnier@iro.umontreal.ca Reply-to: Eli Zaretskii Message-id: <83ab03mrlo.fsf@gnu.org> References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> > From: "Drew Adams" > Date: Wed, 7 Oct 2009 00:50:41 -0700 > Cc: 4654@emacsbugs.donarmstrong.com > > a. Always substituting `~' for the home dir is consistent; and it tells you > where the file is wrt the home dir. > > b. Substituting `~' for the home dir except when it is the root dir breaks > consistency; but it does tell you where the file is wrt root (in that one > exceptional case only - otherwise, it tells you where the file is wrt the home > dir). It also has the advantage of legacy: consistency with the past and > existing code. > > c. If we were to substitute `~' for the home dir except when that is the root > dir, on UNIX etc., but not substitute it for the home dir when that is the root > dir, on Windows, that would ensure that `~' substitution would always shorten > the file name. But that would introduce additional inconsistency. > > And in any case, substituting using `directory-abbrev-alist' does not guarantee > shortening at all. Nothing prevents such "abbreviation" from lengthening the > name. > > Overall, (a) is a better choice than (b) or (c) - unless the legacy > consideration has particular importance here for some reason (I don't think it > does). I hope no one is seriously suggesting to change the behavior of one of the oldest Emacs APIs... I fixed the manual. The description now says This function applies abbreviations from @code{directory-abbrev-alist} to its argument, and also substitutes @samp{~} for the user's home directory if the argument names a file in the home directory or one of its subdirectories. (If the home directory is a root directory, it is not replaced with @samp{~}, because this does not make the result shorter on many systems.) You can use it for directory names and for file names, because it recognizes abbreviations even as part of the name. I hope this is something everybody can live with. From monnier@iro.umontreal.ca Wed Oct 7 07:09:20 2009 Received: (at 4654) by emacsbugs.donarmstrong.com; 7 Oct 2009 14:09:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n97E9Idx025100 for <4654@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 07:09:20 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAFM+zEpMCqug/2dsb2JhbACBUtULhCoEhzQ X-IronPort-AV: E=Sophos;i="4.44,519,1249272000"; d="scan'208";a="47233192" Received: from 76-10-171-160.dsl.teksavvy.com (HELO pastel.home) ([76.10.171.160]) by ironport2-out.pppoe.ca with ESMTP; 07 Oct 2009 10:09:12 -0400 Received: by pastel.home (Postfix, from userid 20848) id 50C3281F0; Wed, 7 Oct 2009 10:09:12 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <4654@debbugs.gnu.org> Subject: Re: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Message-ID: References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> Date: Wed, 07 Oct 2009 10:09:12 -0400 In-Reply-To: <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> (Drew Adams's message of "Wed, 7 Oct 2009 00:50:41 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> so it would be wrong for abbreviate-file-name to do such a >> replacement, since it wouldn't abbreviate. > That's being a bit too black-and-white, don't you think? Not really. Clearly abbreviate-file-name does not guarantee that the returned file name will be shorter. But it *should* aim to "do no harm", i.e. not make file names longer (although it doesn't guarantee that either, IIUC, since it depends on directory-abbrev-alist which is free to lengthen at the user's heart's content). > In that case, it is even more "wrong" to return c:\\foo instead of > ~/foo, which is what we do now on Windows. That's 3 chars longer, > a threefold worsening of your non-shortening problem. ;-) No: the relevant question is not "does it make it shorter", but "does it make it longer". So it's OK (tho suboptimal) to keep "C:\\foo" as is, but it's not OK to turn "/foo" into "~/foo". I wouldn't mind if someone wants to change that behavior in w32, but I'll leave that to people who actually care about w32. > The stated feature of "abbreviation" for this function has two > aspects: (1) substituting a defined "abbreviation" from > `directory-abbrev-list' - which is _not_ necessarily shorter than what > it replaces, in fact, and (2) substituting `~' for the home dir. I think that's the core of the misunderstanding. The purpose of abbreviate-file-name is not to apply the above two steps. Those steps are just the current way to reach the real goal, which is to abbreviate the file name. Admittedly, "abbreviate" is not exactly meant here as "shorten" but rather as "make it more concise/easy/pretty for the user", but still to a first approximation "not longer" is a very good design guideline. Stefan From drew.adams@oracle.com Wed Oct 7 08:19:24 2009 Received: (at 4654-done) by emacsbugs.donarmstrong.com; 7 Oct 2009 15:19:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n97FJNTi003300 for <4654-done@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 08:19:24 -0700 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n97FIu6q029518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Oct 2009 15:18:57 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n97D9xfM002105; Wed, 7 Oct 2009 15:19:41 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 20263208501254928722; Wed, 07 Oct 2009 08:18:42 -0700 Received: from dradamslap1 (/141.144.224.222) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Oct 2009 08:18:40 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , <4654-done@debbugs.gnu.org> Cc: References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> <83ab03mrlo.fsf@gnu.org> Subject: RE: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Date: Wed, 7 Oct 2009 08:19:06 -0700 Message-ID: <1E8768BDE1464D019FC9EED701E222F4@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ab03mrlo.fsf@gnu.org> Thread-Index: AcpHOEvdZWzP79/uTbKq14hMJtaf9gAKD6DQ 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.4ACCB172.00ED:SCFMA4539814,ss=1,fgs=0 > I hope no one is seriously suggesting to change the behavior of one of > the oldest Emacs APIs... That's what I suggested, raising arguments in favor. But I did also raise the countervailing weight of legacy. In terms of code, it is likely to be simpler to be able to always depend on `~', rather than sometimes `C:\\', sometimes `F:\\' (etc.), and sometimes `/'. But yes, it might require some code adaptation, if existing code depends on the current inconsistency. > I fixed the manual. The description now says > > (If the home directory is a root directory, it is not > replaced with @samp{~}, because this does not make the result > shorter on many systems.) > > I hope this is something everybody can live with. Thank you. Consider also making clearer the direction of substitution (e.g a one-line example). As Stefan's own misstatement shows, it's easy for readers to understand the substitution backwards. From drew.adams@oracle.com Wed Oct 7 08:21:34 2009 Received: (at 4654) by emacsbugs.donarmstrong.com; 7 Oct 2009 15:21:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n97FLXA1003949 for <4654@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 08:21:34 -0700 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n97FLbiX023623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Oct 2009 15:21:39 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n97FLsN5032334; Wed, 7 Oct 2009 15:21:55 GMT Received: from abhmt015.oracle.com by acsmt356.oracle.com with ESMTP id 20260278691254928878; Wed, 07 Oct 2009 08:21:18 -0700 Received: from dradamslap1 (/141.144.224.222) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Oct 2009 08:21:18 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4654@debbugs.gnu.org> References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com><0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> Subject: RE: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Date: Wed, 7 Oct 2009 08:21:44 -0700 Message-ID: <17D6D2FB21064E7C9178477A0ECEA571@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpHV8LVaSG2rPfBTRK4ZGJgB8VpzAAB24kA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4ACCB1F4.0103:SCFMA4539814,ss=1,fgs=0 > > The stated feature of "abbreviation" for this function has two > > aspects: (1) substituting a defined "abbreviation" from > > `directory-abbrev-list' - which is _not_ necessarily > > shorter than what it replaces, in fact, and (2) substituting > > `~' for the home dir. > > I think that's the core of the misunderstanding. The purpose of > abbreviate-file-name is not to apply the above two steps. Those steps > are just the current way to reach the real goal, which is to > abbreviate the file name. Do we have a spec declaring the intended purpose, or are we just making it up as we go along? The closest thing we have to a statement of the purpose is the doc, along with the code and its comments, of course. None of those support your claim of the purpose. > Admittedly, "abbreviate" is not exactly meant here as > "shorten" but rather as "make it more concise/easy/pretty for > the user", That's precisely the point. It's not exactly about shortening. The question is whether ~/foo is more useful/pretty/understandable/consistent for the user than (sometimes) c:\\foo and (sometimes) /foo. > but still to a first approximation "not longer" is > a very good design guideline. No, not a very good guideline for usability and understandability. A one-char length difference has no special utility for a user. And that one-character difference is the length argument you are making here. Consistency (always seeing `~' when the home dir is involved) is more important here for users. IMHO. From eliz@gnu.org Wed Oct 7 10:46:39 2009 Received: (at 4654) by emacsbugs.donarmstrong.com; 7 Oct 2009 17:46:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout5.012.net.il (mtaout5.012.net.il [84.95.2.13]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n97HkaDx025623 for <4654@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 10:46:38 -0700 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KR500K00NUXFU00@i_mtaout5.012.net.il> for 4654@emacsbugs.donarmstrong.com; Wed, 07 Oct 2009 19:46:30 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.84.229]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KR500CV9O1ID450@i_mtaout5.012.net.il>; Wed, 07 Oct 2009 19:46:30 +0200 (IST) Date: Wed, 07 Oct 2009 19:44:30 +0200 From: Eli Zaretskii Subject: Re: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name In-reply-to: <1E8768BDE1464D019FC9EED701E222F4@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: 4654@debbugs.gnu.org, monnier@iro.umontreal.ca Reply-to: Eli Zaretskii Message-id: <8363arm741.fsf@gnu.org> References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> <83ab03mrlo.fsf@gnu.org> <1E8768BDE1464D019FC9EED701E222F4@us.oracle.com> > From: "Drew Adams" > Cc: > Date: Wed, 7 Oct 2009 08:19:06 -0700 > > > I fixed the manual. The description now says > > > > (If the home directory is a root directory, it is not > > replaced with @samp{~}, because this does not make the result > > shorter on many systems.) > > > > I hope this is something everybody can live with. > > Thank you. > > Consider also making clearer the direction of substitution (e.g a one-line > example). As Stefan's own misstatement shows, it's easy for readers to > understand the substitution backwards. That is why the text quoted above makes a point of saying "replaced with", which should be unequivocal. From drew.adams@oracle.com Wed Oct 7 10:57:01 2009 Received: (at 4654) by emacsbugs.donarmstrong.com; 7 Oct 2009 17:57:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n97Hv0Ps026998 for <4654@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 10:57:01 -0700 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n97HuW6o016885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Oct 2009 17:56:34 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n96GgrLT028181; Wed, 7 Oct 2009 17:57:22 GMT Received: from abhmt007.oracle.com by acsmt357.oracle.com with ESMTP id 20267159791254938138; Wed, 07 Oct 2009 12:55:38 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Oct 2009 10:55:37 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: <4654@debbugs.gnu.org>, References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> <83ab03mrlo.fsf@gnu.org> <1E8768BDE1464D019FC9EED701E222F4@us.oracle.com> <8363arm741.fsf@gnu.org> Subject: RE: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Date: Wed, 7 Oct 2009 10:55:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8363arm741.fsf@gnu.org> Thread-Index: AcpHdh/g9DdtdWNlRCqQ6BkLPknhXQAAQJwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4ACCD663.0055:SCFMA4539814,ss=1,fgs=0 > > > I fixed the manual. The description now says > > > > > > (If the home directory is a root directory, it is not > > > replaced with @samp{~}, because this does not make the result > > > shorter on many systems.) > > > > Consider also making clearer the direction of substitution > > (e.g a one-line example). As Stefan's own misstatement shows, > > it's easy for readers to understand the substitution backwards. > > That is why the text quoted above makes a point of saying "replaced > with", which should be unequivocal. Yes, thanks, that helps (even though it is mentioned only wrt the root-dir special casing). From monnier@iro.umontreal.ca Wed Oct 7 18:09:23 2009 Received: (at 4654-done) by emacsbugs.donarmstrong.com; 8 Oct 2009 01:09:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9819LRK015251 for <4654-done@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 18:09:22 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAALZzEpMCqug/2dsb2JhbACBUtZMhCoEhzg X-IronPort-AV: E=Sophos;i="4.44,522,1249272000"; d="scan'208";a="47273507" Received: from 76-10-171-160.dsl.teksavvy.com (HELO ceviche.home) ([76.10.171.160]) by ironport2-out.pppoe.ca with ESMTP; 07 Oct 2009 21:09:15 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 1788AB41E9; Wed, 7 Oct 2009 21:09:15 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: "'Eli Zaretskii'" , <4654-done@debbugs.gnu.org> Subject: Re: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Message-ID: References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> <0F408BF94DA24CFCB960917D03E903BA@us.oracle.com> <83ab03mrlo.fsf@gnu.org> <1E8768BDE1464D019FC9EED701E222F4@us.oracle.com> Date: Wed, 07 Oct 2009 21:09:14 -0400 In-Reply-To: <1E8768BDE1464D019FC9EED701E222F4@us.oracle.com> (Drew Adams's message of "Wed, 7 Oct 2009 08:19:06 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Consider also making clearer the direction of substitution (e.g a one-line > example). As Stefan's own misstatement shows, it's easy for readers to > understand the substitution backwards. Given the name of the function, the direction of the substitution is unequivocal. Stefan From drew.adams@oracle.com Wed Oct 7 20:32:56 2009 Received: (at 4654-done) by emacsbugs.donarmstrong.com; 8 Oct 2009 03:32:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n983WtQR008292 for <4654-done@emacsbugs.donarmstrong.com>; Wed, 7 Oct 2009 20:32:56 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n983XuwN016834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Oct 2009 03:33:58 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n97GIMBa018957; Thu, 8 Oct 2009 03:33:34 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 20277167481254972741; Wed, 07 Oct 2009 20:32:21 -0700 Received: from dradamslap1 (/24.5.184.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Oct 2009 20:32:21 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: "'Eli Zaretskii'" , <4654-done@debbugs.gnu.org> References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com><0F408BF94DA24CFCB960917D03E903BA@us.oracle.com><83ab03mrlo.fsf@gnu.org><1E8768BDE1464D019FC9EED701E222F4@us.oracle.com> Subject: RE: bug#4654: 23.1; Elisp manual doc of abbreviate-file-name Date: Wed, 7 Oct 2009 20:32:24 -0700 Message-ID: <5D113C0B5B9B4DB4962CE61C4FD5CB90@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcpHtRy421CZzvenQfS9jqxOu1TrewAEgsWA X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4ACD5D5D.018A:SCFMA4539814,ss=1,fgs=0 > > Consider also making clearer the direction of substitution > > (e.g a one-line example). As Stefan's own misstatement shows, > > it's easy for readers to understand the substitution backwards. > > Given the name of the function, the direction of the substitution > is unequivocal. The question is not whether it is equivocal. I said from the beginning that it is correct. The question is whether it is clear enough. This is a classic gotcha for some readers. From unknown Mon Sep 08 20:52:11 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 05 Nov 2009 15:24:11 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator