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: Null filename ("") is considered to correspond to an existing, readable, and writable file? Date: Tue, 3 Jan 2006 00:25:03 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1136279382 7750 80.91.229.2 (3 Jan 2006 09:09:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2006 09:09:42 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 10:09:40 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EtiAk-00033v-6W for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2006 10:09:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtiCL-00008F-SQ for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2006 04:11:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EthWo-00064P-UF for emacs-devel@gnu.org; Tue, 03 Jan 2006 03:28:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EthVL-0005tU-0h for emacs-devel@gnu.org; Tue, 03 Jan 2006 03:27:51 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EthVJ-0005tB-3V for emacs-devel@gnu.org; Tue, 03 Jan 2006 03:26:49 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EthWU-0001wz-EB for emacs-devel@gnu.org; Tue, 03 Jan 2006 03:28:02 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k038P5IC009495 for ; Tue, 3 Jan 2006 02:25:06 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k038P5Ea001152 for ; Tue, 3 Jan 2006 01:25:05 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-104-171.vpn.oracle.com [141.144.104.171]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k038P4bX001141 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 3 Jan 2006 01:25:05 -0700 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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:48647 Archived-At: > Besides, where is the section of the manual that says that, > unless stated otherwise, all file-name arguments to functions > are relative This is a basic notion of every filesystem: every file is relative to the current directory, unless it begins with the root directory string. I don't thing the Emacs manual should teach such basics. That every file is relative to its directory is not the question. You guys are adamant, but in contradictory ways. To support the "obviousness" that all file-name arguments to all functions are relative file names (which cannot be true, BTW), you provide the platitude that all files are relative to their directory. Luc is adamant that this file-name argument need _not_ be a relative file name. Experiment shows that Luc is right on this one. But you make my point: the doc for this function says nothing about its file-name argument, so it's anyone's guess - try it and see... > and they are all relative to the `default-directory'? In Emacs, `default-directory' is the variable that stores the current directory that is in effect when you are in that file's buffer. The Emacs manual says in the node "File Names": Of course a file is relative to its directory. I know what `default-directory' is. Each buffer has a default directory which is normally the same as the directory of the file visited in that buffer. When you enter a file name without a directory, the default directory is used. If you specify a directory in a relative fashion, with a name that does not start with a slash, it is interpreted with respect to the default directory. The default directory is kept in the variable `default-directory', which has a separate value in every buffer. Clear enough? Perfect. That paragraph, as you point out, is from the Emacs manual, not the Elisp manual. It is about _entering_ file names in response to prompts. What you enter is not necessarily what the function uses as an argument. The paragraph is not about file-name arguments to Emacs-Lisp functions. And it says only that relative file names are taken relative to the default directory. It does not speak at all to the question at hand. > Beyond the doc, wouldn't you expect functions with these > names to return nil for a "" argument? What's the purpose > of not checking this case, correctly > applying the meaning of the function's name and returning nil? > > Is it so that you can use (file-exists-p "") to test the existence of > directory `default-directory'? What's the advantage of such a > "feature"? > There are other, more readable ways to test that: (file-exists-p > default-directory), for instance. > > Sorry, I still don't get it. Why is the design like this? This was discussed here some months ago, although I couldn't find that thread in the few minutes I had to look for it. I already said that I assumed this was "by design". I asked what the design _advantage_ is. No answer, so far. Anyway, the design is as it is. My point was that the arguments to these functions should be documented more clearly - in particular, the case of a "filename" of "" should be mentioned - especially given the names of these functions.