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: Sat, 13 Oct 2007 08:06:32 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1192297534 19492 80.91.229.12 (13 Oct 2007 17:45:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2007 17:45:34 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 13 17:08:18 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 1Igib7-0005NF-JI for ged-emacs-devel@m.gmane.org; Sat, 13 Oct 2007 17:08:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Igib0-0004v4-RS for ged-emacs-devel@m.gmane.org; Sat, 13 Oct 2007 11:08:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Igiax-0004uq-UD for emacs-devel@gnu.org; Sat, 13 Oct 2007 11:08:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Igiax-0004ue-96 for emacs-devel@gnu.org; Sat, 13 Oct 2007 11:08:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Igiax-0004ub-3k for emacs-devel@gnu.org; Sat, 13 Oct 2007 11:08:03 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Igias-0005Z4-Kb; Sat, 13 Oct 2007 11:07:58 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l9DF7t59023891; Sat, 13 Oct 2007 09:07:56 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l9DF7tDc028489; Sat, 13 Oct 2007 09:07:55 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-72-178.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3290428331192287983; Sat, 13 Oct 2007 08:06:23 -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:80799 > > 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. > > If you want to know what it will do if you set variables to values > that are not intended to be used, you can read the code. I did, including all of the distribution Lisp code that uses it. I see nothing in the code that contradicts what I said. There is nothing that prevents FROM from matching a valid directory name that might not in fact directly name an existing directory. The code still works fine in that case. And at least some users have been putting that behavior to good use. > I made it clearer in the doc string what cases are > supposed to be used. The only change you made, that I can see, was adding this phrase: "FROM and TO should be equivalent names, which refer to the same directory." I don't see how that contradicts what I said either. In the user's use case that I cited, FROM is ^/exe and TO is /very-long-path-here/exe. Both FROM and TO are equivalent names in terms of their effect, and both effectively refer to the same directory, /very-long-path-here/exe. Even if FROM had been ^/foo, they would be equivalent names and refer to the same directory, if what ^/foo matches is a directory name. 1. FROM: ^/foo 2. what FROM matches (e.g. typed by user): /foobar 3. replacement for the match: /very-long-path-here/exe 4. TO: /very-long-path-here/exe #3 and #4 are identical names for the same directory. #1 is an equivalent name, by the behavior of `directory-abbrev-alist', to #4. I believe that what I've described is what the code actually does. Don't you think so? That behavior might not be as limited as what you intended, but that is the current behavior AFAICT. And I don't see why the behavior should be changed to fit the more limited scenario you apparently have in mind. This is a useful mechanism. We've already had two users (not counting me) who reported using it this way: (1) the user I mentioned and (2) Juanma.