From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30938: 27.0; `dired-do-create-files' etc.: do NOT always raise error if no files Date: Sat, 31 Mar 2018 19:50:14 +0300 Message-ID: <83370g8a0p.fsf@gnu.org> References: <<<<<7ea429b5-b12e-4639-9d77-11db71504d9c@default> <87605g7xpj.fsf@mail.linkov.net> <70149736-0c90-4059-91d0-155144bf4abd@default> <87o9j6k5qx.fsf@mail.linkov.net>>>>> <<<<<8111e8b0-a7fb-4de4-9371-fd69c74c46e5@default>>>>> <<<<<83lgeac7xs.fsf@gnu.org>>>>> <<<>>> <<<<83k1tt8ttp.fsf@gnu.org>>>> <<>> <<<83in9d8s4b.fsf@gnu.org>>> <<9b80ae9e-06e3-4217-89b1-eb8a3b0c93b8@default>> <<838ta88vfz.fsf@gnu.org>> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1522514959 26963 195.159.176.226 (31 Mar 2018 16:49:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Mar 2018 16:49:19 +0000 (UTC) Cc: 30938@debbugs.gnu.org, juri@linkov.net To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 31 18:49:14 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f2Jgi-0006iL-OU for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Mar 2018 18:49:08 +0200 Original-Received: from localhost ([::1]:36646 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2Jik-0000In-KC for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Mar 2018 12:51:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2Jic-0000Hw-Oz for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:51:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f2JiY-0005dd-QR for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:51:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53506) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f2JiY-0005dQ-Mc for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f2JiY-0006Iv-FW for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Mar 2018 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30938 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30938-submit@debbugs.gnu.org id=B30938.152251502624186 (code B ref 30938); Sat, 31 Mar 2018 16:51:02 +0000 Original-Received: (at 30938) by debbugs.gnu.org; 31 Mar 2018 16:50:26 +0000 Original-Received: from localhost ([127.0.0.1]:33170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f2Jhy-0006I1-1k for submit@debbugs.gnu.org; Sat, 31 Mar 2018 12:50:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f2Jhw-0006Hn-7p for 30938@debbugs.gnu.org; Sat, 31 Mar 2018 12:50:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f2Jhn-0004gI-0b for 30938@debbugs.gnu.org; Sat, 31 Mar 2018 12:50:18 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2Jhm-0004g2-ST; Sat, 31 Mar 2018 12:50:14 -0400 Original-Received: from [176.228.60.248] (port=2850 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f2Jhm-0005J3-CI; Sat, 31 Mar 2018 12:50:14 -0400 In-reply-to: (message from Drew Adams on Sat, 31 Mar 2018 09:10:41 -0700 (PDT)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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: 208.118.235.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:144764 Archived-At: > Date: Sat, 31 Mar 2018 09:10:41 -0700 (PDT) > From: Drew Adams > Cc: juri@linkov.net, 30938@debbugs.gnu.org > > > First, dired-get-marked-files _can_ be invoked when no files are > > marked, without risking a user-error: it has the ARG argument for > > that. So if your hypothetical command needs for some reason to work > > when no files are marked, it can, at least in principle. Why your > > dired[p]-insert-subdirs didn't go that way, or at least didn't pass nil > > as ERROR, I don't understand (and I'm not sure it's related to the > > issue at hand). > > Don't confuse a command that invokes `dired-get-marked-files' > with a command that invokes a command that invokes > `dired-get-marked-files'. Their behaviors can differ (and > in the general case they do), including wrt interactive and > non-interactive use. Summary: I'm not convinced. Some details below. > `diredp-insert-subdirs' inserts the subdir of the current > line, if no subdirs are marked. If none are marked and it > is called from a non-subdir line then it _should_ raise an > error interactively (and it does). > > Should it also do so non-interactively? Why should it > decide that? Why not let its caller do that? When > called non-interactively it cannot (and need not) know > what is the right way to handle that case. AFAIU, you have all the tools to make it do that, by judicious use of the ARG and ERROR arguments. > Imaginary command `insert-marked-subdirs-and-do-stuff' > should _not_ raise an error, and its invocation of > `diredp-insert-subdirs' should be a _no-op_, in the > same situation where invoking `diredp-insert-subdirs' > interactively would raise an error. If diredp-insert-subdirs is designed to support that, its interface should allow that. Commands that aren't designed to support that have no obligations to allow calling them like that. IOW freedom of applications to invoke commands and functions outside their intended domain is not unlimited, and asking for it to be unlimited, or insisting that the limits be made wider, no matter the costs, is IMO unreasonable. > Being able to do that is for the benefit of reusing a > command that calls `dired-get-marked-files' in different > ways. Such reuses have their limitations. One of them is when no files are marked and there's no "current file". Those commands signal an error because they cannot fulfill their contract; silently doing nothing in this case is against that contract. > While it is typically a user error if nothing is marked > and point is not on any file line, it is not necessarily > an error when neither of those is the case - even for an > interactive case. Signaling an error is a widely accepted way of telling the caller "you asked me to do something; I didn't, and here's why". If worse comes to worst, the caller can always catch the error and recover from it. > To me, the solution is simple: let a command that invokes > `d-g-m-f' pass non-nil ERROR when the command is called > interactively. That solution causes unreasonable complication on a dozen of commands for no good reason, so I don't see why we should do that.