all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 54191@debbugs.gnu.org
Subject: bug#54191: [External] : Re: bug#54191: 26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names?
Date: Mon, 28 Feb 2022 20:49:08 +0200	[thread overview]
Message-ID: <83zgmaltcr.fsf@gnu.org> (raw)
In-Reply-To: <SJ0PR10MB54882EA5D4F3222F756F87D7F3019@SJ0PR10MB5488.namprd10.prod.outlook.com> (message from Drew Adams on Mon, 28 Feb 2022 18:32:15 +0000)

> From: Drew Adams <drew.adams@oracle.com>
> CC: "54191@debbugs.gnu.org" <54191@debbugs.gnu.org>
> Date: Mon, 28 Feb 2022 18:32:15 +0000
> 
> > > > > No mention of absolute or relative in that node.
> > > >
> > > > It _shows_ them.
> > >
> > > I don't see any showing of a relative file name.
> > 
> > Exactly.
> 
>  ez> It shows them [absolute & relative file names].
>  da>> I don't see it showing relative names.
>  ez>>> Exactly.
> 
> Wow.
> 
> Showing only absolute names doesn't say what
> happens when a relative name is passed.

It tells you what are remote file names.

> > > FILENAME in `Remote Files'
> > > FILENAME and FILE in `Magic File Names'
> > > FILENAME in `Visiting Functions'
> > > FILENAME in `Subroutines of Visiting'
> > > FILENAME in `Saving Buffers'
> > > FILENAME in `Reading from Files'
> > > FILENAME in `Writing to Files'
> > > FILENAME and FILE in `File Locks'
> > > ...
> > > and so on - lots of places.
> > 
> > These are just references to file names.  How is that a problem?
> 
> As the bug report requests: The doc should say
> how the function handles relative and absolute
> file-name args.

I explained how.  Let me repeat:

                                 Emacs always assumes that any relative
  file name is relative to the default directory, e.g., entering a file
  name without a directory specifies a file in the default directory.

> > Anyway, that's the implementation.  We aren't 
> > talking about the implementation.
> 
> ??
> 
> We're talking about the behavior of a function;

Saying that it calls expand-file-name is not describing the behavior,
it describes the implementation which leads to the behavior.

> specifically, how it handles a file-name arg
> that is a relative or an absolute name.

It handles them like every reasonable person will expect: relative
file names are interpreted relative to the default directory.  You
want this to be told and retold, time and again, with every function
we document?  We say that once, and that should be enough, especially
since the Emacs handling of relative file names is the only reasonable
and natural handling of such file names.

> > From "File Names" in the Emacs user manual:
> > 
> >   Emacs always assumes that any relative file name
> >   is relative to the default directory, e.g., entering a file
> >   name without a directory specifies a file in the default directory.
> > 
> > This is so central to Emacs handling of file names that I'm astonished
> > that someone who uses Emacs and programs for Emacs for so many years
> > doesn't know that.
> 
> You know that I do know that.

You do?  Then why do you keep asking about it as if you don't, as if
you are confused, and as if this is undocumented?

> That text is irrelevant to this bug report.  No
> one said that we don't tell users what relative
> and absolute file names are, or that a relative
> name is by default resolved using the value of
> `default-directory'.

There's nothing else to say about "behavior with absolute and relative
file names", certainly not in general.

> And you omitted the context of that sentence:
> 
>  "Whenever Emacs reads a file name using the
>   minibuffer"

No, it's you who omitted the context.  The full quotation is this:

                     Regardless, Emacs always assumes that any relative
  file name is relative to the default directory, e.g., entering a file
  name without a directory specifies a file in the default directory.

"Regardless", i.e. not just with respect to entering file names in the
minibuffer, but in general.

> It's clear that you don't want to fix this bug.
> Fine; though that's too bad.

There is no bug.  You just keep arguing for the sake of an argument,
although it should be clear to everyone that you have no case.





      reply	other threads:[~2022-02-28 18:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-27 21:30 bug#54191: 26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names? Drew Adams
2022-02-27 22:42 ` Drew Adams
2022-02-28  8:03   ` Michael Albinus
2022-02-28 16:26     ` bug#54191: [External] : " Drew Adams
2022-03-01 11:55       ` Michael Albinus
2022-02-28 13:48   ` Eli Zaretskii
2022-02-28 16:26     ` bug#54191: [External] : " Drew Adams
2022-02-28 16:57       ` Eli Zaretskii
2022-02-28 17:22         ` Drew Adams
2022-02-28  9:33 ` Lars Ingebrigtsen
2022-02-28 16:28   ` bug#54191: [External] : " Drew Adams
2022-02-28 13:46 ` Eli Zaretskii
2022-02-28 16:26   ` bug#54191: [External] : " Drew Adams
2022-02-28 16:54     ` Eli Zaretskii
2022-02-28 17:22       ` Drew Adams
2022-02-28 17:44         ` Eli Zaretskii
2022-02-28 18:32           ` Drew Adams
2022-02-28 18:49             ` Eli Zaretskii [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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zgmaltcr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=54191@debbugs.gnu.org \
    --cc=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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.