bug#34338: 26.1; delete-file return codes and failures

[Stefan Kangas]

Boruch Baum <boruch_baum@gmx.com> writes:

> How is it backwards incompatable? If the prior behavior was undefined,
> no one would have been using it for anything. From their perspective, a
> defined is just another form of undefined behavior, if you get my drift.

Having re-read the entire discussion, I think that we should perhaps
clarify what we're talking about.  Your proposal had three different
parts to it AFAICT:

Boruch Baum <boruch_baum@gmx.com> writes:

> B1) return t on success

Eli said that: "The function's return value is not documented, which is
an indication that it is 'not useful'."

Do you have a use-case in mind here?  Can't the caller just check using
'file-exists-p' if it matters instead?

> B2) raise an error when (not NOERROR) and:
> 
>   B2.1) file doesn't exist
> 
>   B2.2) (and (chmod -w) (not FORCE))
> 
>   B2.3) another form of permission denial is encountered

Eli replied: "In any case, you propose a backward-incompatible change in
behavior, so it won't fly.  We could perhaps do it the other way around:
add a new optional argument ERROR-OUT, which, when non-nil, will cause
the function to signal an error when B2.1 or B2.2 happen (I believe B2.3
already causes an error).  And similarly with FORCE."

I'm not against this part, but again I'm not sure what is the use-case
here.  And what about having the caller use 'file-exists-p' instead?

> B3) return nil when NOERROR and:
> 
>   B2.1) file doesn't exist
> 
>   B2.2)  another form of permission denial is encountered

I guess the inverted version of the above makes sense (return nil unless
ERROR-OUT), iff we add B1 and B2.

> C) maybe log the exact error or reason for nil to *Messages*.

This part was agreed to be left out already, and I agree.

Best regards,
Stefan Kangas