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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 06 Feb 2019 18:19:10 +0200

> Date: Tue, 5 Feb 2019 16:47:37 -0500
> From: Boruch Baum <[email-masked]>
> 
> Currently:
> 
> A1) When delete-file successfully deletes a file, the function returns
>     nil, not t.
> 
> A2) When the file does not exist, the function returns the same
>     value - nil.
> 
> A3) When the file has been chmod'ed -w, the function performs the
>     operation, with no regard to any option to emulate or not emulate 'rm
>     -f', and also returns the identical value - nil.
> 
> A4) When either the file's containing folder is chmod'ed -x, or the file
>     is chattr'ed +i, the function crashes.

The function's return value is not documented, which is an indication
that it is "not useful".  You will see in the code that it always
either returns nil or signals an error.

> I'd like to suggest:
> 
>   delete-file FILE &optional NOERROR FORCE

As Michael points out, there's one optional argument already, and we
need to preserve it.

> 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

!ERROR and either of the following, or all of them?

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.

IOW, since omitting optional arguments is the same as passing nil for
them, we cannot add new arguments that change behavior if they are
nil, certainly not in a function that is not only command, but also an
important primitive used all over the place in Emacs.

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

Not sure what you mean by "exact error or reason", I believe we
already log the reason.

Finally, did you think how to allow users set or reset these new knobs
when invoking delete-file interactively?  I think these options are
mainly for interactive use, and in that case we should have some
convenient way of setting them interactively.

Thanks.