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

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 27 Feb 2022 22:22:01 UTC

Severity: normal

Found in version 26.3

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: bug#54191: [External] : Re: bug#54191: 26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names?
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".  Users should be able to find out what
the behavior is in each case: relative or absolute.

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

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

But the doc string, yes - it clearly calls out
the different behavior for a relative file name.
And that's exactly what I added in my second msg.

But that's NOT the case for other functions
(in this & other nodes of the manual, and in
doc strings).

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




This bug report was last modified 3 years and 79 days ago.

Previous Next


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