From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#34338: 26.1; delete-file return codes and failures Date: Wed, 30 Oct 2019 23:52:50 +0100 Message-ID: <875zk5x2v1.fsf@joffe.skangas.se> References: <20190205214737.vswyk7sfmgkliv7v@E15-2016.optimum.net> <87wocmvt5w.fsf@joffe.skangas.se> <20191030222159.rwfn7clgfjh36dze@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="132382"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 34338@debbugs.gnu.org To: Boruch Baum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 30 23:54:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iPwr0-000YJO-UD for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 Oct 2019 23:54:15 +0100 Original-Received: from localhost ([::1]:45202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPwqz-0001Qm-Px for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 Oct 2019 18:54:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45396) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPwqq-0001Qe-Bj for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 18:54:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPwqp-0001JD-9a for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 18:54:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42989) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iPwqo-0001H7-PN for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 18:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iPwqo-0005uI-Ik for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 18:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Oct 2019 22:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34338 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 34338-submit@debbugs.gnu.org id=B34338.157247599122637 (code B ref 34338); Wed, 30 Oct 2019 22:54:02 +0000 Original-Received: (at 34338) by debbugs.gnu.org; 30 Oct 2019 22:53:11 +0000 Original-Received: from localhost ([127.0.0.1]:51810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPwpz-0005t3-2G for submit@debbugs.gnu.org; Wed, 30 Oct 2019 18:53:11 -0400 Original-Received: from giraff.fripost.org ([193.234.15.44]:42414 helo=outgoing.fripost.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPwpw-0005sk-C6 for 34338@debbugs.gnu.org; Wed, 30 Oct 2019 18:53:09 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by outgoing.fripost.org (Postfix) with ESMTP id 7904C187EB06; Wed, 30 Oct 2019 23:53:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=x.fripost.org; h= content-type:content-type:mime-version:user-agent:message-id :in-reply-to:date:date:references:subject:subject:from:from; s= 9df9cdc7e101629b5003b587945afa70; t=1572475982; x=1574290383; bh=jTtt2WlUy7BIwwmrPK+boOfldEAV8lhQBnJSk0QkG1c=; b=FZiUEHhkE26P /3AwwLRryCOsJAu83tQ5imnHEMJ7CJiU5FEsuc4Eq6tXKz1SQY9uW4aatBQzywkM /UmjCf7/rI5ufTWMvLcClAyUGcVKgkqpBkQT1MHPcpRntF/1+IehSEUslrGK18/U DCqkQSBMq2XY+ExRdoNMfcYvqBDjX58Q8afgCExz4CeWTdWnOZIfIM3UIopIWJo4 1LOVmYyAz8MFlXH9l2SGm9sZ1JXLtpxGcj3YNjgGe0W7/eojzHMe0twTWW7IBJnG /+WbjciU06+X6jfe8SJJ2jeIBrTeyHc/KJ3OTHah5iVo25H/qhHCUc4EgBZDMQ/a QZ/9MsVrjg== X-Virus-Scanned: Debian amavisd-new at fripost.org Original-Received: from outgoing.fripost.org ([127.0.0.1]) by localhost (giraff.fripost.org [127.0.0.1]) (amavisd-new, port 10040) with LMTP id ptQtY_PCmfGz; Wed, 30 Oct 2019 23:53:02 +0100 (CET) Original-Received: from smtp.fripost.org (unknown [172.16.0.6]) by outgoing.fripost.org (Postfix) with ESMTP id 5BC20187EB02; Wed, 30 Oct 2019 23:53:02 +0100 (CET) Original-Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by smtp.fripost.org (Postfix) with ESMTPSA id A2BCE59A027A; Wed, 30 Oct 2019 23:53:01 +0100 (CET) Original-Received: from skangas by joffe.skangas.se with local (Exim 4.92) (envelope-from ) id 1iPwpe-0006eC-Qe; Wed, 30 Oct 2019 23:52:50 +0100 In-Reply-To: <20191030222159.rwfn7clgfjh36dze@E15-2016.optimum.net> (Boruch Baum's message of "Wed, 30 Oct 2019 18:22:00 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170481 Archived-At: Boruch Baum 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 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