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: File modes facilities. Date: Mon, 24 Oct 2005 10:13:07 -0700 Message-ID: References: <87irvm97r4.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1130174366 4016 80.91.229.2 (24 Oct 2005 17:19:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2005 17:19:26 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 19:19:16 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EU5sv-0006xu-V4 for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2005 19:13:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EU5sv-0007tW-Ae for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2005 13:13:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EU5sm-0007tH-5Y for emacs-devel@gnu.org; Mon, 24 Oct 2005 13:13:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EU5sl-0007t5-LP for emacs-devel@gnu.org; Mon, 24 Oct 2005 13:13:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EU5sl-0007t2-GI for emacs-devel@gnu.org; Mon, 24 Oct 2005 13:13:11 -0400 Original-Received: from [148.87.122.31] (helo=rgminet02.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EU5sl-0008Ic-AS for emacs-devel@gnu.org; Mon, 24 Oct 2005 13:13:11 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j9OHD8nv016425 for ; Mon, 24 Oct 2005 11:13:09 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9OHD8ok016341 for ; Mon, 24 Oct 2005 11:13:08 -0600 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j9OHD7lj016332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Oct 2005 11:13:08 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87irvm97r4.fsf-monnier+emacs@gnu.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:44747 Archived-At: > Yes, if you type the directory explicitly and absolutely (no > `../', `./', `~/'), then `load-library' will complete in that > directory. My point was that, without doing that, they complete > differently - they use different paths (directories). Yes, they do work differently. I haven't advocated to remove load-file and/or merge it into load-library for precisely this reason. But we could get rid of load-library if we could just add an interactive spec to `load'. As for getting rid of load-file, maybe you could make load-library's completion understand a leading "./" as meaning "relative to current dir" (similarly to what is done in most shells), or maybe make a C-u prefix tell load-library that the initial minibuffer content should be default-directory. Then maybe we could imagine getting rid of load-file. I almost wrote something similar (the "./" part) in my previous message, but I think that 1) it would be confusing and somewhat hidden functionality, and 2) people would also miss "../", "~/" etc. - IOW, they would miss completion from the `default-directory'. Yes, a C-u could signal a change from the completing behavior of `load-library' (absolute file name) to that of `load-file' (relative file name, default-directory). But why do that? What is the advantage of getting rid of `load-file', with its handy UI for file-name completion?