From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: 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> References: <2C5117E03B57417289F8B3E16B1B8B61@us.oracle.com> Reply-To: Drew Adams , 4654@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1254902854 2512 80.91.229.12 (7 Oct 2009 08:07:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2009 08:07:34 +0000 (UTC) Cc: 4654@emacsbugs.donarmstrong.com To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 07 10:07:24 2009 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.50) id 1MvRYQ-0005Q3-J2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Oct 2009 10:07:23 +0200 Original-Received: from localhost ([127.0.0.1]:54892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvRYP-0006n5-OA for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Oct 2009 04:07:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvRYL-0006mh-MN for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2009 04:07:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvRYG-0006l3-E9 for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2009 04:07:16 -0400 Original-Received: from [199.232.76.173] (port=35040 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvRYF-0006kw-Vx for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2009 04:07:12 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:58810) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MvRYF-0001g0-Bo for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2009 04:07:11 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9787974028983; Wed, 7 Oct 2009 01:07:09 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n978053T026732; Wed, 7 Oct 2009 01:00:05 -0700 Resent-Date: Wed, 7 Oct 2009 01:00:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 07 Oct 2009 08:00:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4654 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4654-submit@emacsbugs.donarmstrong.com id=B4654.125490205925684 (code B ref 4654); Wed, 07 Oct 2009 08:00:04 +0000 Original-Received: (at 4654) by emacsbugs.donarmstrong.com; 7 Oct 2009 07:54:19 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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 Original-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 Original-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 Original-Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 20251411821254901816; Wed, 07 Oct 2009 00:50:16 -0700 Original-Received: from dradamslap1 (/141.144.169.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Oct 2009 00:50:15 -0700 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 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 07 Oct 2009 04:07:16 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list 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:31755 Archived-At: > > ~/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).