[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54191: [External] : Re: bug#54191: 26.3; (elisp) `Magic File Names'
From: |
Drew Adams |
Subject: |
bug#54191: [External] : Re: bug#54191: 26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names? |
Date: |
Mon, 28 Feb 2022 17:22:09 +0000 |
> > > Did you follow the cross-reference? Because there you'd find the
> > > answer to your question, loud and clear.
> >
> > I don't think it does. No mention of absolute or
> > relative in that node.
>
> It _shows_ them.
I don't see any showing of a relative file name.
Can you point to one there?
> > And it's not just about `file-remote-p'. The
> > problem is more general, as reported. And the
> > general problem involves doc strings and manual.
>
> 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.
Similarly, doc strings of functions that
accept file-name args. It's _not_ obvious
what the behavior is.
And yes, some functions do automatically
apply `expand-file-name' to a FILE(NAME) arg.
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.
- bug#54191: [External] : Re: bug#54191: 26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names?, (continued)
bug#54191: 26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names?, Lars Ingebrigtsen, 2022/02/28
bug#54191: 26.3; (elisp) `Magic File Names' FILENAME parameters: absolute names?, Eli Zaretskii, 2022/02/28