unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "54191@debbugs.gnu.org" <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 18:32:15 +0000	[thread overview]
Message-ID: <SJ0PR10MB54882EA5D4F3222F756F87D7F3019@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <8335k2naxd.fsf@gnu.org>

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

> > > There's no more general problem here.
> >
> > 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.  ("How" meaning what it does,
not "how" meaning the function's implementation.)

It's a problem that we don't tell users this.

> Anyway, that's the implementation.  We aren't 
> talking about the implementation.

??

We're talking about the behavior of a function;
specifically, how it handles a file-name arg
that is a relative or an absolute name.

We're not (I'm not) talking about how the
function is implemented.  We're (I am) talking
about its _behavior_ - what it does.

> > The question of whether a function does that,
> > and more generally how a function handles a
> > relative vs absolute file-name arg, is not
> > nothing.
> 
> 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. But you just love
to poke, don't you, Eli?

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

And you omitted the context of that sentence:

 "Whenever Emacs reads a file name using the
  minibuffer"

That context is irrelevant to this bug.  But
I think you realize that.  This bug is about
documenting the behavior of functions that
accept file-name arguments - calling out what
they do for a relative vs absolute name.

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

But you apparently want to go on and on about
this, even though the bug was closed.  I've
felt obliged to respond to your extraneous,
irrelevant arguments.  I hope you're done with
them now - please consider giving it a rest.
We both deserve that, I think.





  reply	other threads:[~2022-02-28 18:32 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 [this message]
2022-02-28 18:49             ` Eli Zaretskii

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=SJ0PR10MB54882EA5D4F3222F756F87D7F3019@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=54191@debbugs.gnu.org \
    --cc=eliz@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).