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: should `minibuffer-complete' use `abbreviate-file-name'? Date: Fri, 12 Oct 2007 23:03:14 -0700 Message-ID: References: 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 1192255474 18620 80.91.229.12 (13 Oct 2007 06:04:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2007 06:04:34 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 13 08:04:24 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 1Iga6m-0000CP-5o for ged-emacs-devel@m.gmane.org; Sat, 13 Oct 2007 08:04:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iga6f-0001lq-VU for ged-emacs-devel@m.gmane.org; Sat, 13 Oct 2007 02:04:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iga6N-0001Vj-48 for emacs-devel@gnu.org; Sat, 13 Oct 2007 02:03:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iga6M-0001Uy-0F for emacs-devel@gnu.org; Sat, 13 Oct 2007 02:03:54 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iga6L-0001Uo-Nq for emacs-devel@gnu.org; Sat, 13 Oct 2007 02:03:53 -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 1Iga6E-0000rP-G4; Sat, 13 Oct 2007 02:03:46 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9D63ikF029869; Sat, 13 Oct 2007 01:03:44 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l9D2lLQX015316; Sat, 13 Oct 2007 00:03:43 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-72-178.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3290063391192255385; Fri, 12 Oct 2007 23:03:05 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: 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:80764 Archived-At: > > set my directory-abbrev-alist up like > > (("^/exe" . "/very-long-path-here/exe")) > > This is definitely not the way directory-abbrev-alist > was intended to be used. So what? Regardless of the original intention, what's important is how it actually behaves. Unless there is some reason to think that the behavior is bugged and needs to be changed to conform rigidly to the intention you assume, the assumption should be dropped in favor of reality. Anyway, who's to say that that was the only intention, back in the dawn of history when this was introduced? Are you basing that assumption only on the doc or on the actual effect? The current doc speaks of symlinks as an useful example, but the actual behavior is not limited to symlinks. The effect doesn't exclude the user's interpretation and use case at all, AFAICT. The abbreviation mechanism in fact takes no account of whether there are any symlinks - they are certainly not a requirement. > `directory-abbrev-alist' should turn a valid filename into > another valid filename, the difference between the two being > mostly cosmetic. What's a valid filename in this context? Presumably, it's a valid directory name, but what's that? Syntactic validity only, or must it also correspond to an existing directory? This is a rewrite mechanism for directory names; that's all. The effect is just to match the regexp in the car against (part of) a directory name and to replace the matched part by the cdr, another directory name. Directory name does not imply existing directory. Why impose an interpretation that the directory name matched by the car must correspond to an existing directory? It is enough, for the actual effect, that it have directory-name syntax. If a user types a directory name that is matched by the regexp in the car, then that satisfies the requirement, even if the name s?he typed does not correspond to an existing directory. Beyond the rewriting, no use is ever made of the car - it's irrelevant whether it matches the name of an existing directory. That's the whole point of the rewrite: to get beyond the car and its matched name and use the cdr instead. The same is even true for the cdr: The abbreviation mechanism itself is agnostic on whether it names an existing directory. It is the use context, not the rewrite mechanism, that determines whether the name in the cdr is OK. That context might expect the name of an existing directory or it might expect only valid directory-name syntax (e.g. to create a new directory). And even if there were a requirement that the cdr always name an existing directory, that requirement would anyway be satisfied by the user's use case: /very-long-path-here/exe names an existing directory. It is the car, ^/exe, that matches a directory name, but one that does not name an existing directory. That's fine - the name matched by the car is never used as a directory; it is used only to come up with the cdr. > E.g. It should be (("^/very-long-path-here/exe" . "/exe") C'est toi qui le dit. The abbreviation mechanism doesn't impose that. > instead, or something like that. For shorthands, she can use > any number of other things like environment variables (which > *are* expanded by TAB) or bookmarks. The fact that there exist other shorthand means is not an argument that one should not also use this directory shorthand to go from short name to long (as well as from long to short). You wouldn't argue that because we have environment variables we should forego bookmarks, would you? BTW, the user mentioned that he also uses env variables with completion. Perhaps that's in fact what gave him the idea that it would be good for completion to also support dir abbreviations. The directory abbreviation mechanism substitutes the dir name in the cdr for whatever dir name the regexp in the car matches. If that is its only effect, as it seems to be, then there is nothing wrong with putting that effect to good uses that might not have been foreseen originally. Perhaps the user misread the doc, or perhaps he read it in a new and more general way. In any case, he discovered something new for himself that works and is useful. It would be even more useful to extend its use to completion, as he requested. My question was, and is, would there be any downside to letting completion take advantage of this shorthand? If it completes env vars, why not let it also complete dir abbrevs?