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

From: Boruch Baum <[email-masked]>
Date: Fri, 1 Nov 2019 05:34:23 -0400

On 2019-10-31 16:32, Eli Zaretskii wrote:
> The current implementation basically is a moral equivalent of "rm -f".
> It also is biased towards interactive usage, where the return value is
> not very important.
>
> Does it answer your question?

Not satisfactorily.

Applying the notion of '_moral_ equivalence' to a programming command
option strikes me as alien, but as an exercise, the only _moral_
standard that I've come up with for "rm -f" is an immoral standard of
inconsiderateness. What I mean is that someone at some time put some
sort of block on deleting a file, and you're saying that emacs as its
*default* action is to inconsiderately try to do its best to ignore any
such block. As an issue in _morality_, it sounds quite inconsiderate and
thus presumably undesirable if one's decision-basis is some form of
morality.

Independent of morality, it's also inconsistent with the default
behavior of comparable programming contexts, and thus violates POLA
(principle of least astonishment). For example, compare the default
action of the written command delete-file with your own expressed basis
... the shell command rm, run interactively from the command line.

A better comparison basis would be other forms of lisp. Rabbi Google
tells me that both common-lisp and scheme signal an error on failure.
The only other lisp I have handy to try is another GNU lisp, guile
2.0.13, which also does not signal an error on a file marked 'chmod -w'.
Outside of lisp, python behaves similarly. So that's several POLA points
in emacs' favor.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0