unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Null filename ("") is considered to correspond to an existing,  readable, and writable file?
Date: Tue, 03 Jan 2006 20:11:31 +0200	[thread overview]
Message-ID: <usls5p4fg.fsf@gnu.org> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICKEAKDBAA.drew.adams@oracle.com>

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 3 Jan 2006 00:25:03 -0800
> 
>     > 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.

Perhaps it isn't, but your wording (above) suggested it was.  I'm
sure, if you re-read it, you will agree that it could be interpreted
like that.  Which is why I replied as I did.

> You guys are adamant, but in contradictory ways.

Could we please keep the attitude out of this?  You could imagine, I
think, that reading your complaints might be sometimes annoying no
less than reading my responses.  Let's try to stay focused on the
technical issues, and stay away of ad hominem, okay?

More to the point, Luc and myself don't coordinate our replies, and
respond to different parts of your messages, so there's no reason to
assume that we will offer similar arguments.

> But you make my point: the doc for this function says nothing about
> its file-name argument

You may wish to re-read my message, and then you will see that I did
not say anything about the function's doc string.  I responded to your
assertions and suggestions about the manual.

>            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.

For the record, you said ``the manual'', and never hinted on a
specific one.

But okay, let's turn to the ELisp manual:

In "Relative File Names" we read:

    All the directories in the file system form a tree starting at the root
    directory.  A file name can specify all the directory names starting
    from the root of the tree; then it is called an "absolute" file name.
    Or it can specify the position of the file in the tree relative to a
    default directory; then it is called a "relative" file name.  On Unix
    and GNU/Linux, an absolute file name starts with a slash or a tilde
    (`~'), and a relative one does not.  On MS-DOS and MS-Windows, an
    absolute file name starts with a slash or a backslash, or with a drive
    specification `X:/', where X is the "drive letter".  The rules on VMS
    are complicated.

In "File Name Expansion" we read:

    "Expansion" of a file name means converting a relative file name to an
    absolute one.  Since this is done relative to a default directory, you
    must specify the default directory name as well as the file name to be
    expanded.  Expansion also simplifies file names by eliminating
    redundancies such as `./' and `NAME/../'.

    [...]

     -- Variable: default-directory
	 The value of this buffer-local variable is the default directory
	 for the current buffer.  It should be an absolute directory name;
	 it may start with `~'.  This variable is buffer-local in every
	 buffer.

Could you please state what is unclear in these fragments?

> 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.

So what _is_ the question at hand, wrt the manual(s)?

>     > 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.

  parent reply	other threads:[~2006-01-03 18:11 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 [this message]
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

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=usls5p4fg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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).