GNU bug report logs - #54191
26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names?

Previous Next

Full log

Message #46 received at 54191 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "54191 <at> debbugs.gnu.org" <54191 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#54191: 26.3; (elisp) `Magic File Names'
 FILENAME parameters: absolute names?
Date: Mon, 28 Feb 2022 17:22:11 +0000

> They handle any kind of file names.

The question is how they handle them - how they
handle relative vs absolute names.

> > Users should be able to find out what
> > the behavior is in each case: relative or absolute.
> 
> The behavior is the same: each function does its documented job and
> returns the advertised value.

It no doubt does what's documented.  But if
what's documented is incomplete, then so will
be your understanding of what the function does.

> > > What each function _does_ with each kind of file name
> > > is a different matter.
> >
> > Yes, and that's exactly what I wrote about.  The
> > behavior for each kind of file name should be
> > declared.  That's the point of the bug report.
> 
> Then there's no bug, because this particular function's behavior is
> documented.

In the doc string.  Not in the manual.

And (for the Nth time), this bug report isn't
about "this particular function".  I couldn't
be clearer about that. 
> 
> > > In the specific case of file-remote-p this is described
> > > both in the doc string and in the manual.
> >
> > No, not the manual, I think (unless it was added
> > recently).
> 
> Yes, in the manual as well.

Where?  As one reader, I don't see that.

And again, this bug report is _not_ about
`file-remote-p'.

> > That's what the bug report is about: doing just
> > what you said: describe what the function does
> > with each kind of file name.
> 
> We already did.

I disagree.  I wouldn't have filed the bug
report if that were the case. 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.