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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 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 18:57:15 +0200

> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "54191 <at> debbugs.gnu.org" <54191 <at> debbugs.gnu.org>
> Date: Mon, 28 Feb 2022 16:26:24 +0000
> 
> > > Users shouldn't have to search the Elisp code base
> > > to try to figure out whether they might need to
> > > apply `expand-file-name' to a file name before
> > > passing it to some function.
> > 
> > It goes without saying that _every_ file-related function in Emacs
> > accepts _any_ kind of file names: absolute, relative, you name it.
> 
> No, it doesn't go without saying.
> 
> More importantly, I didn't say "accept", I said
> "expect".

These functions don't "expect" anything.  They handle any kind of file
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.

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

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

Previous Next

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