From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Null filename ("") is considered to correspond to an existing, readable, and writable file?
Date: Tue, 3 Jan 2006 10:51:16 -0800 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICKEAPDBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <usls5p4fg.fsf@gnu.org>
In "Relative File Names" we read:
<Elisp text defining relative and absolute file names>
In "File Name Expansion" we read:
<Elisp text on converting relative to absolute names>
-- Variable: default-directory
<definition of `default-directory'>
Could you please state what is unclear in these fragments?
They are clear, as far as they go. As I said, the definition of relative is
essentially "every name that is not absolute". That is fine as a definition,
but it would be clearer to also explicitly point out that a null name ("")
is relative, because it does not start with... It's not needed for the
quasi-formal definition, but it is helpful as documentation. That is all.
So what _is_ the question at hand, wrt the manual(s)?
1) See above.
2) The doc (both doc strings and manual blurb) for the functions mentioned
should explicitly describe the file-name argument, saying that a) it can be
relative or absolute, and reminding readers that b) "" is a relative name,
so that the function returns non-nil, because it tests the directory. Such a
reminder of the definition of relative might not be needed for each function
in the manual that takes a file-name arg, but these functions, because of
their names, encourage misinterpretation wrt "".
> > 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.
I tried to provide a pointer to the answer: if you find and read those
discussions, you might find it. I didn't necessarily need a
thank-you, but something less unkind would be nice.
I don't see anything unkind in my reply (certainly nothing unkind was meant)
or particularly helpful in your pointer. Like you, I don't have the time to
scour the posts of the past "some months" (looking for what keywords?). I
don't expect anyone to do that. If the advantage of this design was
discussed (I must have missed it), someone must be able to summarize the
rationale.
prev parent reply other threads:[~2006-01-03 18:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-02 22:57 Null filename ("") is considered to correspond to an existing, readable, and writable file? Drew Adams
2006-01-03 1:22 ` Luc Teirlinck
2006-01-03 3:27 ` Drew Adams
2006-01-03 4:41 ` Luc Teirlinck
2006-01-03 8:24 ` Drew Adams
2006-01-03 18:13 ` Eli Zaretskii
2006-01-03 4:56 ` Luc Teirlinck
2006-01-03 5:32 ` Eli Zaretskii
2006-01-03 8:25 ` Drew Adams
2006-01-03 15:50 ` Stefan Monnier
2006-01-03 18:51 ` Drew Adams
2006-01-03 19:16 ` Eli Zaretskii
2006-01-03 19:25 ` Drew Adams
2006-01-03 19:40 ` Luc Teirlinck
2006-01-03 20:23 ` Luc Teirlinck
2006-01-03 21:09 ` Drew Adams
2006-01-07 20:04 ` Thien-Thi Nguyen
2006-01-03 18:11 ` Eli Zaretskii
2006-01-03 18:51 ` Drew Adams
2006-01-03 19:13 ` Eli Zaretskii
2006-01-03 19:23 ` Drew Adams
2006-01-03 18:51 ` Drew Adams [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DNEMKBNJBGPAOPIJOOICKEAPDBAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).