all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* file-exists-p on empty string
@ 2019-02-27 12:29 Evgeny Zajcev
  2019-02-27 14:15 ` Michael Albinus
                   ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Evgeny Zajcev @ 2019-02-27 12:29 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

It was quite surprising for me that

  (file-exists-p "")
  ==> t

I thought that `file-exists-p` resembles stat, such as

  $ stat ""
  No such file or directory

This is because `file-exists-p` uses `expand-file-name`, which returns
current directory for empty string

Would not it be more correct for `file-exists-p` to return `nil` for empty
string, and if someone wants current directory he will use "." as filename?

Thanks

-- 
lg

[-- Attachment #2: Type: text/html, Size: 796 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 12:29 file-exists-p on empty string Evgeny Zajcev
@ 2019-02-27 14:15 ` Michael Albinus
  2019-02-27 15:29   ` Troy Hinckley
  2019-02-27 15:43   ` Robert Pluim
  2019-02-27 15:53 ` Stefan Monnier
  2019-02-27 16:09 ` Eli Zaretskii
  2 siblings, 2 replies; 34+ messages in thread
From: Michael Albinus @ 2019-02-27 14:15 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: emacs-devel

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

Hi Evgeny,

> It was quite surprising for me that
>
>   (file-exists-p "")
>   ==> t
>
> I thought that `file-exists-p` resembles stat, such as
>   
>   $ stat ""
>   No such file or directory
>
> This is because `file-exists-p` uses `expand-file-name`, which returns
> current directory for empty string
>
> Would not it be more correct for `file-exists-p` to return `nil` for
> empty string, and if someone wants current directory he will use "."
> as filename?

I believe the current behavior is correct. file-exists-p calls
expand-file-name, and (expand-file-name "") returns always
default-directory.

> Thanks

Best regards, Michael.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 14:15 ` Michael Albinus
@ 2019-02-27 15:29   ` Troy Hinckley
  2019-02-27 15:43   ` Robert Pluim
  1 sibling, 0 replies; 34+ messages in thread
From: Troy Hinckley @ 2019-02-27 15:29 UTC (permalink / raw)
  To: Michael Albinus; +Cc: Evgeny Zajcev, emacs-devel

I agree with Evgeny. A user would not normally expect (file-exists-p “”) to return t. At least I wouldn’t. 

- Troy Hinckley

> On Feb 27, 2019, at 7:15 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
> 
> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
> 
> Hi Evgeny,
> 
>> It was quite surprising for me that
>> 
>>  (file-exists-p "")
>>  ==> t
>> 
>> I thought that `file-exists-p` resembles stat, such as
>> 
>>  $ stat ""
>>  No such file or directory
>> 
>> This is because `file-exists-p` uses `expand-file-name`, which returns
>> current directory for empty string
>> 
>> Would not it be more correct for `file-exists-p` to return `nil` for
>> empty string, and if someone wants current directory he will use "."
>> as filename?
> 
> I believe the current behavior is correct. file-exists-p calls
> expand-file-name, and (expand-file-name "") returns always
> default-directory.
> 
>> Thanks
> 
> Best regards, Michael.
> 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 14:15 ` Michael Albinus
  2019-02-27 15:29   ` Troy Hinckley
@ 2019-02-27 15:43   ` Robert Pluim
  2019-02-27 16:01     ` Michael Albinus
                       ` (3 more replies)
  1 sibling, 4 replies; 34+ messages in thread
From: Robert Pluim @ 2019-02-27 15:43 UTC (permalink / raw)
  To: Michael Albinus; +Cc: Evgeny Zajcev, emacs-devel

Michael Albinus <michael.albinus@gmx.de> writes:

> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>
> Hi Evgeny,
>
>> It was quite surprising for me that
>>
>>   (file-exists-p "")
>>   ==> t
>>
>> I thought that `file-exists-p` resembles stat, such as
>>   
>>   $ stat ""
>>   No such file or directory
>>
>> This is because `file-exists-p` uses `expand-file-name`, which returns
>> current directory for empty string
>>
>> Would not it be more correct for `file-exists-p` to return `nil` for
>> empty string, and if someone wants current directory he will use "."
>> as filename?
>
> I believe the current behavior is correct. file-exists-p calls
> expand-file-name, and (expand-file-name "") returns always
> default-directory.

Thatʼs not described in the doc-string though, so itʼs surprising
behaviour.

Robert



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 12:29 file-exists-p on empty string Evgeny Zajcev
  2019-02-27 14:15 ` Michael Albinus
@ 2019-02-27 15:53 ` Stefan Monnier
  2019-02-27 16:00   ` Robert Pluim
  2019-02-27 16:09 ` Eli Zaretskii
  2 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2019-02-27 15:53 UTC (permalink / raw)
  To: emacs-devel

>   (file-exists-p "")
>   ==> t

Elisp doesn't handle file names quite like POSIX, indeed.

I don't think we can change the above behavior without introducing other
odd behaviors.  E.g. currently (file-name-nondirectory "/a/b/") return "",
which is consistent with the above behavior.


        Stefan




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 15:53 ` Stefan Monnier
@ 2019-02-27 16:00   ` Robert Pluim
  2019-02-27 16:15     ` Stefan Monnier
  0 siblings, 1 reply; 34+ messages in thread
From: Robert Pluim @ 2019-02-27 16:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>   (file-exists-p "")
>>   ==> t
>
> Elisp doesn't handle file names quite like POSIX, indeed.
>
> I don't think we can change the above behavior without introducing other
> odd behaviors.  E.g. currently (file-name-nondirectory "/a/b/") return "",
> which is consistent with the above behavior.

? file-name-nodirectory doesnʼt use expand-file-name anywhere, and we
can fix file-exists-p without changing expand-file-name, so I donʼt
follow you here.

Robert



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 15:43   ` Robert Pluim
@ 2019-02-27 16:01     ` Michael Albinus
  2019-02-27 16:55       ` Eli Zaretskii
  2019-02-27 16:11     ` Eli Zaretskii
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 34+ messages in thread
From: Michael Albinus @ 2019-02-27 16:01 UTC (permalink / raw)
  To: emacs-devel

Robert Pluim <rpluim@gmail.com> writes:

>> I believe the current behavior is correct. file-exists-p calls
>> expand-file-name, and (expand-file-name "") returns always
>> default-directory.
>
> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.

Agreed, shall be documented at least. But I'm pretty sure there's code
in the wild which depends on this behavior. Maybe not explicitly, but
via calling file-exists-p with an empty string, which has been computed somehow.

I would expect this for example for Tramp. Do we want to change such
basic behavior?

Btw, several other basic file name operations behave similar. Try
(file-attributes "") or (file-readable-p "") or (file-directory-p "") .

> Robert

Best regards, Michael.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 12:29 file-exists-p on empty string Evgeny Zajcev
  2019-02-27 14:15 ` Michael Albinus
  2019-02-27 15:53 ` Stefan Monnier
@ 2019-02-27 16:09 ` Eli Zaretskii
  2019-02-27 18:42   ` lg.zevlg
  2 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2019-02-27 16:09 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: emacs-devel

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Wed, 27 Feb 2019 15:29:53 +0300
> 
> It was quite surprising for me that
> 
>   (file-exists-p "")
>   ==> t

  http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00528.html

Nothing is new under the sun...



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 15:43   ` Robert Pluim
  2019-02-27 16:01     ` Michael Albinus
@ 2019-02-27 16:11     ` Eli Zaretskii
  2019-02-27 16:16       ` Robert Pluim
  2019-02-27 16:30     ` Andreas Schwab
  2019-02-27 19:40     ` lg.zevlg
  3 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2019-02-27 16:11 UTC (permalink / raw)
  To: Robert Pluim; +Cc: emacs-devel

> From: Robert Pluim <rpluim@gmail.com>
> Date: Wed, 27 Feb 2019 16:43:29 +0100
> Cc: Evgeny Zajcev <lg.zevlg@gmail.com>, emacs-devel <emacs-devel@gnu.org>
> 
> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.

It's a corner use case that comes up once in 10 years, so I'm not sure
we should care enough about it to describe it in the doc string.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 16:00   ` Robert Pluim
@ 2019-02-27 16:15     ` Stefan Monnier
  0 siblings, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2019-02-27 16:15 UTC (permalink / raw)
  To: emacs-devel

>> I don't think we can change the above behavior without introducing other
>> odd behaviors.  E.g. currently (file-name-nondirectory "/a/b/") return "",
>> which is consistent with the above behavior.
>
> ? file-name-nondirectory doesnʼt use expand-file-name anywhere, and we
> can fix file-exists-p without changing expand-file-name, so I donʼt
> follow you here.

It considers "" as the name of the directory, just like `file-exists-p`
and `expand-file-name` (and pretty much all other operations that take
a file name).

This is really not specific to `file-exists-p`: it's a general design of
Elisp's handling of file names.

If we consider "" as an invalid file name, then I think
(file-name-nondirectory "/a/b/") should be changed to return ".", and
I'd be surprised if it's the only change we'd need to do.


        Stefan



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 16:11     ` Eli Zaretskii
@ 2019-02-27 16:16       ` Robert Pluim
  0 siblings, 0 replies; 34+ messages in thread
From: Robert Pluim @ 2019-02-27 16:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Wed, 27 Feb 2019 16:43:29 +0100
>> Cc: Evgeny Zajcev <lg.zevlg@gmail.com>, emacs-devel <emacs-devel@gnu.org>
>> 
>> Thatʼs not described in the doc-string though, so itʼs surprising
>> behaviour.
>
> It's a corner use case that comes up once in 10 years, so I'm not sure
> we should care enough about it to describe it in the doc string.

I was advocating for changing the behaviour, then we donʼt need to
describe it (but hysterical raisins and backwards compatibility and
all that.....)

Robert



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 15:43   ` Robert Pluim
  2019-02-27 16:01     ` Michael Albinus
  2019-02-27 16:11     ` Eli Zaretskii
@ 2019-02-27 16:30     ` Andreas Schwab
  2019-02-27 19:40     ` lg.zevlg
  3 siblings, 0 replies; 34+ messages in thread
From: Andreas Schwab @ 2019-02-27 16:30 UTC (permalink / raw)
  To: emacs-devel

On Feb 27 2019, Robert Pluim <rpluim@gmail.com> wrote:

> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.

It's described in the manual, see (elisp) Files.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 16:01     ` Michael Albinus
@ 2019-02-27 16:55       ` Eli Zaretskii
  2019-02-27 18:09         ` Michael Albinus
  0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2019-02-27 16:55 UTC (permalink / raw)
  To: Michael Albinus; +Cc: emacs-devel

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Wed, 27 Feb 2019 17:01:29 +0100
> 
> Btw, several other basic file name operations behave similar. Try
> (file-attributes "") or (file-readable-p "") or (file-directory-p "") .

All of them call expand-file-name internally, no?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 16:55       ` Eli Zaretskii
@ 2019-02-27 18:09         ` Michael Albinus
  0 siblings, 0 replies; 34+ messages in thread
From: Michael Albinus @ 2019-02-27 18:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Date: Wed, 27 Feb 2019 17:01:29 +0100
>> 
>> Btw, several other basic file name operations behave similar. Try
>> (file-attributes "") or (file-readable-p "") or (file-directory-p "") .
>
> All of them call expand-file-name internally, no?

Yes for file-attributes and file-readable-p. For file-directory-p I
don't see it immediately, but I guess so.

Best regards, Michael.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 16:09 ` Eli Zaretskii
@ 2019-02-27 18:42   ` lg.zevlg
  2019-02-27 18:46     ` Eli Zaretskii
  0 siblings, 1 reply; 34+ messages in thread
From: lg.zevlg @ 2019-02-27 18:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel


>> From: Evgeny Zajcev <lg.zevlg@gmail.com>
>> Date: Wed, 27 Feb 2019 15:29:53 +0300
>> 
>> It was quite surprising for me that
>> 
>>  (file-exists-p "")
>>  ==> t
> 
>  http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00528.html

Ah! I’m sorry, I searched for it, google answered nothing 

I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the moment, but its kind of ugly


—
lg


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 18:42   ` lg.zevlg
@ 2019-02-27 18:46     ` Eli Zaretskii
  2019-02-27 19:04       ` lg.zevlg
  0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2019-02-27 18:46 UTC (permalink / raw)
  To: lg.zevlg; +Cc: emacs-devel

> From: lg.zevlg@gmail.com
> Date: Wed, 27 Feb 2019 21:42:46 +0300
> Cc: emacs-devel@gnu.org
> 
> I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the moment, but its kind of ugly

Why do you need to reject empty strings?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 18:46     ` Eli Zaretskii
@ 2019-02-27 19:04       ` lg.zevlg
  2019-02-27 19:16         ` Eli Zaretskii
  2019-02-27 19:30         ` Stefan Monnier
  0 siblings, 2 replies; 34+ messages in thread
From: lg.zevlg @ 2019-02-27 19:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

27 февр. 2019 г., в 21:46, Eli Zaretskii <eliz@gnu.org> написал(а):

>> From: lg.zevlg@gmail.com
>> Date: Wed, 27 Feb 2019 21:42:46 +0300
>> Cc: emacs-devel@gnu.org
>> 
>> I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the moment, but its kind of ugly
> Why do you need to reject empty strings?

Filenames are generated externally, and the tool uses empty string notion for no-file semantic

—
lg


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 19:04       ` lg.zevlg
@ 2019-02-27 19:16         ` Eli Zaretskii
  2019-02-27 19:29           ` lg.zevlg
  2019-02-27 19:30         ` Stefan Monnier
  1 sibling, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2019-02-27 19:16 UTC (permalink / raw)
  To: lg.zevlg; +Cc: emacs-devel

> From: lg.zevlg@gmail.com
> Date: Wed, 27 Feb 2019 22:04:15 +0300
> Cc: emacs-devel@gnu.org
> 
> > Why do you need to reject empty strings?
> 
> Filenames are generated externally, and the tool uses empty string notion for no-file semantic

Isn't that un-Emacsy?  Why not nil?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 19:16         ` Eli Zaretskii
@ 2019-02-27 19:29           ` lg.zevlg
  0 siblings, 0 replies; 34+ messages in thread
From: lg.zevlg @ 2019-02-27 19:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

27 февр. 2019 г., в 22:16, Eli Zaretskii <eliz@gnu.org> написал(а):

>> From: lg.zevlg@gmail.com
>> Date: Wed, 27 Feb 2019 22:04:15 +0300
>> Cc: emacs-devel@gnu.org
>> 
>>> Why do you need to reject empty strings?
>> 
>> Filenames are generated externally, and the tool uses empty string notion for no-file semantic
> 
> Isn't that un-Emacsy?  Why not nil?

That thing is out of my control, however `nil` is something specific and need to be handled in special way, strings are universal

Another exmaple is just a text file with filenames on each line, where empty lines occurs, you also need to check for empty string filenames

—
lg


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 19:04       ` lg.zevlg
  2019-02-27 19:16         ` Eli Zaretskii
@ 2019-02-27 19:30         ` Stefan Monnier
  1 sibling, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2019-02-27 19:30 UTC (permalink / raw)
  To: emacs-devel

>>> I use `(and (not (string-empty-p fn)) (file-exists-p fn))` at the
>>> moment, but its kind of ugly
>> Why do you need to reject empty strings?
> Filenames are generated externally, and the tool uses empty string
> notion for no-file semantic

So the (not (string-empty-p fn)) test just reflects the tool's semantics
and is not an artifact of some suboptimal behavior of file-exists-p.


        Stefan




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 15:43   ` Robert Pluim
                       ` (2 preceding siblings ...)
  2019-02-27 16:30     ` Andreas Schwab
@ 2019-02-27 19:40     ` lg.zevlg
  3 siblings, 0 replies; 34+ messages in thread
From: lg.zevlg @ 2019-02-27 19:40 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Michael Albinus, emacs-devel


> 27 февр. 2019 г., в 18:43, Robert Pluim <rpluim@gmail.com> написал(а):
> 
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
>> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>> 
>> Hi Evgeny,
>> 
>>> It was quite surprising for me that
>>> 
>>>  (file-exists-p "")
>>>  ==> t
>>> 
>>> I thought that `file-exists-p` resembles stat, such as
>>> 
>>>  $ stat ""
>>>  No such file or directory
>>> 
>>> This is because `file-exists-p` uses `expand-file-name`, which returns
>>> current directory for empty string
>>> 
>>> Would not it be more correct for `file-exists-p` to return `nil` for
>>> empty string, and if someone wants current directory he will use "."
>>> as filename?
>> 
>> I believe the current behavior is correct. file-exists-p calls
>> expand-file-name, and (expand-file-name "") returns always
>> default-directory.
> 
> Thatʼs not described in the doc-string though, so itʼs surprising
> behaviour.
> 

Yeah, exactly, I’m ok with the current behaviour if it was described in doc-string!

—
lg


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
@ 2019-02-27 20:07 lg.zevlg
  2019-02-27 21:18 ` Stefan Monnier
  0 siblings, 1 reply; 34+ messages in thread
From: lg.zevlg @ 2019-02-27 20:07 UTC (permalink / raw)
  To: monnier; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]


> So the (not (string-empty-p fn)) test just reflects the tool's semantics and is not an artifact of some suboptimal behavior of file-exists-p.
I gree, but there is not a line about empty strings in doc-string.  It is great that this is mentioned in documentation, but anyway behaviour was quite unexpected

--
lg

[-- Attachment #2: Type: text/html, Size: 858 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 20:07 lg.zevlg
@ 2019-02-27 21:18 ` Stefan Monnier
  2019-02-27 22:01   ` Drew Adams
  2019-03-06  9:51   ` Michael Albinus
  0 siblings, 2 replies; 34+ messages in thread
From: Stefan Monnier @ 2019-02-27 21:18 UTC (permalink / raw)
  To: emacs-devel

>> So the (not (string-empty-p fn)) test just reflects the tool's semantics
>> and is not an artifact of some suboptimal behavior of file-exists-p.
> I gree, but there is not a line about empty strings in doc-string.
> It is great that this is mentioned in documentation, but anyway
> behaviour was quite unexpected

The problem is that docstrings describe the behavior of a specific
function, so they usually don't mention the more general aspects that
affect all functions of a given subsystem, such as here the general
treatment of the empty string when used as a file name.

Otherwise, every file-name-manipulating function would have to repeat
this information in its docstring.


        Stefan




^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: file-exists-p on empty string
  2019-02-27 21:18 ` Stefan Monnier
@ 2019-02-27 22:01   ` Drew Adams
  2019-02-28  3:24     ` Stefan Monnier
  2019-03-06  9:51   ` Michael Albinus
  1 sibling, 1 reply; 34+ messages in thread
From: Drew Adams @ 2019-02-27 22:01 UTC (permalink / raw)
  To: Stefan Monnier, emacs-devel

> > I gree, but there is not a line about empty strings in doc-string.
> > It is great that this is mentioned in documentation, but anyway
> > behaviour was quite unexpected
> 
> The problem is that docstrings describe the behavior of a specific
> function, so they usually don't mention the more general aspects that
> affect all functions of a given subsystem, such as here the general
> treatment of the empty string when used as a file name.
> 
> Otherwise, every file-name-manipulating function would have to repeat
> this information in its docstring.

Every such function _should_ have this info in
its doc string.  There's no reason not to.

In terms of the _implementation_ this might be
a "general aspect that affects all functions of
a given subsystem".  But in terms of the doc for
a given such function this is not (only) a
general subsystem aspect - it is part of the
individual function's definition & description.

Even if this weren't such a gotcha, the doc for
the function should describe the return value,
including for any particular input cases.

A user might well start with `C-h f', and not
with some reading of the general-subsystem doc
(assuming there is such doc).  Such info is
pretty important to understanding the particular
function.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
@ 2019-02-27 22:09 lg.zevlg
  2019-02-27 22:23 ` Drew Adams
  0 siblings, 1 reply; 34+ messages in thread
From: lg.zevlg @ 2019-02-27 22:09 UTC (permalink / raw)
  To: monnier; +Cc: emacs-devel

> The problem is that docstrings describe the behavior of a specific function, so they usually don't mention the more general aspects that affect all functions of a given subsystem, such as here the general treatment of the empty string when used as a file name. Otherwise, every file-name-manipulating function would have to repeat this information in its docstring.

So, maybe FILENAME argument at least could be renamed to NAME to give at least some hint that this is not a filename, but just a name hint which will be expanded and canonised to real filename?

--
lg


^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: file-exists-p on empty string
  2019-02-27 22:09 lg.zevlg
@ 2019-02-27 22:23 ` Drew Adams
  2019-02-27 22:41   ` Evgeny Zajcev
  0 siblings, 1 reply; 34+ messages in thread
From: Drew Adams @ 2019-02-27 22:23 UTC (permalink / raw)
  To: lg.zevlg, monnier; +Cc: emacs-devel

> > The problem is that docstrings describe the behavior of a specific
> function, so they usually don't mention the more general aspects that
> affect all functions of a given subsystem, such as here the general
> treatment of the empty string when used as a file name. Otherwise,
> every file-name-manipulating function would have to repeat this
> information in its docstring.
> 
> So, maybe FILENAME argument at least could be renamed to NAME to give
> at least some hint that this is not a filename, but just a name hint
> which will be expanded and canonised to real filename?

That's not good enough.  It might make sense
to you now, now that you know something about
how the input is interpreted as a file name.

The parameter name FILENAME is more appropriate
than NAME.  But the doc string should say more
about it.  You can't rely on just the parameter
name to convey all of the meaning that you're
(now) reading into it.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 22:23 ` Drew Adams
@ 2019-02-27 22:41   ` Evgeny Zajcev
  2019-02-27 23:23     ` Drew Adams
  2019-02-28  1:16     ` Stefan Monnier
  0 siblings, 2 replies; 34+ messages in thread
From: Evgeny Zajcev @ 2019-02-27 22:41 UTC (permalink / raw)
  To: Drew Adams; +Cc: monnier, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

чт, 28 февр. 2019 г. в 01:24, Drew Adams <drew.adams@oracle.com>:

> > > The problem is that docstrings describe the behavior of a specific
> > function, so they usually don't mention the more general aspects that
> > affect all functions of a given subsystem, such as here the general
> > treatment of the empty string when used as a file name. Otherwise,
> > every file-name-manipulating function would have to repeat this
> > information in its docstring.
> >
> > So, maybe FILENAME argument at least could be renamed to NAME to give
> > at least some hint that this is not a filename, but just a name hint
> > which will be expanded and canonised to real filename?
>
> That's not good enough.  It might make sense
> to you now, now that you know something about
> how the input is interpreted as a file name.
>
> The parameter name FILENAME is more appropriate
> than NAME.  But the doc string should say more
> about it.  You can't rely on just the parameter
> name to convey all of the meaning that you're
> (now) reading into it.
>

But what to do with `file-name-directory` function, which returns `nil` to
empty string, while `file-exists-p` returns `t', and both of them gets
FILENAME as argument ?

-- 
lg

[-- Attachment #2: Type: text/html, Size: 1784 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: file-exists-p on empty string
  2019-02-27 22:41   ` Evgeny Zajcev
@ 2019-02-27 23:23     ` Drew Adams
  2019-02-28  0:08       ` Evgeny Zajcev
  2019-02-28  1:16     ` Stefan Monnier
  1 sibling, 1 reply; 34+ messages in thread
From: Drew Adams @ 2019-02-27 23:23 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: monnier, emacs-devel

> > > > The problem is that docstrings describe the behavior of a specific
> > > > function, so they usually don't mention the more general aspects that
> > > > affect all functions of a given subsystem, such as here the general
> > > > treatment of the empty string when used as a file name. Otherwise,
> > > > every file-name-manipulating function would have to repeat this
> > >
> > > 
> > > So, maybe FILENAME argument at least could be renamed to NAME to give
> > > at least some hint that this is not a filename, but just a name hint
> > > which will be expanded and canonised to real filename?
> >
> > That's not good enough.  It might make sense
> > to you now, now that you know something about
> > how the input is interpreted as a file name.
> >
> > The parameter name FILENAME is more appropriate
> > than NAME.  But the doc string should say more
> > about it.  You can't rely on just the parameter
> > name to convey all of the meaning that you're
> > (now) reading into it.
>
> But what to do with `file-name-directory` function,
> which returns `nil` to empty string, while
> `file-exists-p` returns `t', and both of them gets
> FILENAME as argument ?

The doc string of each should describe its parameters
and return values.  Formal parameter names are a help,
nothing more.  Sometimes a parameter name is clear
enough that it can be used inline in a sentence in
such a way that the sentence clarifies its meaning
or its name clarifies the sentence.  Sometimes not.

If a parameter name is truly misleading then it should
be changed.  I don't think that's the case here (for
either of the functions you mention).  But others
might have different opinions.

The point is that the doc string should describe the
function: its behavior, its inputs, its return value,
and its side effects.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 23:23     ` Drew Adams
@ 2019-02-28  0:08       ` Evgeny Zajcev
  0 siblings, 0 replies; 34+ messages in thread
From: Evgeny Zajcev @ 2019-02-28  0:08 UTC (permalink / raw)
  To: Drew Adams; +Cc: monnier, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

чт, 28 февр. 2019 г. в 02:23, Drew Adams <drew.adams@oracle.com>:

> > > > > The problem is that docstrings describe the behavior of a specific
> > > > > function, so they usually don't mention the more general aspects
> that
> > > > > affect all functions of a given subsystem, such as here the general
> > > > > treatment of the empty string when used as a file name. Otherwise,
> > > > > every file-name-manipulating function would have to repeat this
> > > >
> > > >
> > > > So, maybe FILENAME argument at least could be renamed to NAME to give
> > > > at least some hint that this is not a filename, but just a name hint
> > > > which will be expanded and canonised to real filename?
> > >
> > > That's not good enough.  It might make sense
> > > to you now, now that you know something about
> > > how the input is interpreted as a file name.
> > >
> > > The parameter name FILENAME is more appropriate
> > > than NAME.  But the doc string should say more
> > > about it.  You can't rely on just the parameter
> > > name to convey all of the meaning that you're
> > > (now) reading into it.
> >
> > But what to do with `file-name-directory` function,
> > which returns `nil` to empty string, while
> > `file-exists-p` returns `t', and both of them gets
> > FILENAME as argument ?
>
> The doc string of each should describe its parameters
> and return values.  Formal parameter names are a help,
> nothing more.  Sometimes a parameter name is clear
> enough that it can be used inline in a sentence in
> such a way that the sentence clarifies its meaning
> or its name clarifies the sentence.  Sometimes not.
>
> If a parameter name is truly misleading then it should
> be changed.  I don't think that's the case here (for
> either of the functions you mention).  But others
> might have different opinions.
>
> The point is that the doc string should describe the
> function: its behavior, its inputs, its return value,
> and its side effects.
>

Totally, that is why "Emacs is an extensible self-documenting editor"


-- 
lg

[-- Attachment #2: Type: text/html, Size: 2825 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 22:41   ` Evgeny Zajcev
  2019-02-27 23:23     ` Drew Adams
@ 2019-02-28  1:16     ` Stefan Monnier
  1 sibling, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2019-02-28  1:16 UTC (permalink / raw)
  To: emacs-devel

> But what to do with `file-name-directory` function, which returns `nil` to
> empty string,

It also returns `nil` for "a" or ".".
That's just its way to say "there is no directory part in this file name".
So it seems completely consistent with file-exists-p returning t for "".


        Stefan




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 22:01   ` Drew Adams
@ 2019-02-28  3:24     ` Stefan Monnier
  0 siblings, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2019-02-28  3:24 UTC (permalink / raw)
  To: Drew Adams; +Cc: emacs-devel

> Every such function _should_ have this info in
> its doc string.  There's no reason not to.
> In terms of the _implementation_ this might be
> a "general aspect that affects all functions of
> a given subsystem".  But in terms of the doc for
> a given such function this is not (only) a
> general subsystem aspect - it is part of the
> individual function's definition & description.

By the same reasoning, file-exists-p should explain that filenames are
represented as strings, and that if a file-name is not absolute it will
be interpreted according to default-directory, and that it is subject to
file-name-handlers-alist, and `file-attributes` should additionally
explain how &optional arguments are passed, ...

So, yes, there is a reason not to: it's because duplicating such info in
every docstrings is madness.  Maybe a more sane way to provide a similar
information would be to make "filename" (in the docstring) into
a hyperlink to the Elisp refman that describes how file names work
(including things like "", file-name-handlers-alist, and default-directory).


        Stefan



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-02-27 21:18 ` Stefan Monnier
  2019-02-27 22:01   ` Drew Adams
@ 2019-03-06  9:51   ` Michael Albinus
  2019-03-08  6:11     ` Stefan Monnier
  1 sibling, 1 reply; 34+ messages in thread
From: Michael Albinus @ 2019-03-06  9:51 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> So the (not (string-empty-p fn)) test just reflects the tool's semantics
>>> and is not an artifact of some suboptimal behavior of file-exists-p.
>> I gree, but there is not a line about empty strings in doc-string.
>> It is great that this is mentioned in documentation, but anyway
>> behaviour was quite unexpected
>
> The problem is that docstrings describe the behavior of a specific
> function, so they usually don't mention the more general aspects that
> affect all functions of a given subsystem, such as here the general
> treatment of the empty string when used as a file name.
>
> Otherwise, every file-name-manipulating function would have to repeat
> this information in its docstring.

What about the appended patch? It does not touch the docstrings, but it
explains the situation more verbose in the Lisp manual.

>         Stefan

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff, Size: 1601 bytes --]

*** /tmp/ediffq2yDYg	2019-03-06 10:49:17.961600214 +0100
--- /home/albinus/src/emacs-26/doc/lispref/files.texi	2019-03-06 10:39:51.804376822 +0100
***************
*** 16,22 ****
  names.  A file name is a string.  Most of these functions expand file
  name arguments using the function @code{expand-file-name}, so that
  @file{~} is handled correctly, as are relative file names (including
! @file{../}).  @xref{File Name Expansion}.
  
    In addition, certain @dfn{magic} file names are handled specially.
  For example, when a remote file name is specified, Emacs accesses the
--- 16,22 ----
  names.  A file name is a string.  Most of these functions expand file
  name arguments using the function @code{expand-file-name}, so that
  @file{~} is handled correctly, as are relative file names (including
! @file{../} and the empty string).  @xref{File Name Expansion}.
  
    In addition, certain @dfn{magic} file names are handled specially.
  For example, when a remote file name is specified, Emacs accesses the
***************
*** 2409,2414 ****
--- 2409,2425 ----
  superroot above the root directory @file{/}.  On other filesystems,
  @file{/../} is interpreted exactly the same as @file{/}.
  
+ Expanding @file{.} or the empty string returns the default directory:
+ 
+ @example
+ @group
+ (expand-file-name "." "/usr/spool/")
+      @result{} "/usr/spool"
+ (expand-file-name "" "/usr/spool/")
+      @result{} "/usr/spool"
+ @end group
+ @end example
+ 
  Note that @code{expand-file-name} does @emph{not} expand environment
  variables; only @code{substitute-in-file-name} does that:
  

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-03-06  9:51   ` Michael Albinus
@ 2019-03-08  6:11     ` Stefan Monnier
  2019-03-09  8:48       ` Michael Albinus
  0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2019-03-08  6:11 UTC (permalink / raw)
  To: emacs-devel

> What about the appended patch? It does not touch the docstrings, but it
> explains the situation more verbose in the Lisp manual.

Fine by me.  Maybe we should add a node that talks specifically about
the way Emacs treats file names differently from the host system.


        Stefan




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: file-exists-p on empty string
  2019-03-08  6:11     ` Stefan Monnier
@ 2019-03-09  8:48       ` Michael Albinus
  0 siblings, 0 replies; 34+ messages in thread
From: Michael Albinus @ 2019-03-09  8:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What about the appended patch? It does not touch the docstrings, but it
>> explains the situation more verbose in the Lisp manual.
>
> Fine by me.

Thanks. I've pushed this to the emacs-26 branch.

>         Stefan

Best regards, Michael.



^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2019-03-09  8:48 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-27 12:29 file-exists-p on empty string Evgeny Zajcev
2019-02-27 14:15 ` Michael Albinus
2019-02-27 15:29   ` Troy Hinckley
2019-02-27 15:43   ` Robert Pluim
2019-02-27 16:01     ` Michael Albinus
2019-02-27 16:55       ` Eli Zaretskii
2019-02-27 18:09         ` Michael Albinus
2019-02-27 16:11     ` Eli Zaretskii
2019-02-27 16:16       ` Robert Pluim
2019-02-27 16:30     ` Andreas Schwab
2019-02-27 19:40     ` lg.zevlg
2019-02-27 15:53 ` Stefan Monnier
2019-02-27 16:00   ` Robert Pluim
2019-02-27 16:15     ` Stefan Monnier
2019-02-27 16:09 ` Eli Zaretskii
2019-02-27 18:42   ` lg.zevlg
2019-02-27 18:46     ` Eli Zaretskii
2019-02-27 19:04       ` lg.zevlg
2019-02-27 19:16         ` Eli Zaretskii
2019-02-27 19:29           ` lg.zevlg
2019-02-27 19:30         ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2019-02-27 20:07 lg.zevlg
2019-02-27 21:18 ` Stefan Monnier
2019-02-27 22:01   ` Drew Adams
2019-02-28  3:24     ` Stefan Monnier
2019-03-06  9:51   ` Michael Albinus
2019-03-08  6:11     ` Stefan Monnier
2019-03-09  8:48       ` Michael Albinus
2019-02-27 22:09 lg.zevlg
2019-02-27 22:23 ` Drew Adams
2019-02-27 22:41   ` Evgeny Zajcev
2019-02-27 23:23     ` Drew Adams
2019-02-28  0:08       ` Evgeny Zajcev
2019-02-28  1:16     ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.