bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Boruch Baum
Subject: bug#34338: 26.1; delete-file return codes and failures
Date: Fri, 1 Nov 2019 05:34:23 -0400
User-agent: NeoMutt/20180716

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]