From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams 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 09:10:41 -0700 (PDT) Message-ID: 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>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522512972 13363 195.159.176.226 (31 Mar 2018 16:16:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Mar 2018 16:16:12 +0000 (UTC) Cc: 30938@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 31 18:16:08 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 1f2JAl-0003M5-Q6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Mar 2018 18:16:08 +0200 Original-Received: from localhost ([::1]:34305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2JCp-0005ZX-1J for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Mar 2018 12:18:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2JCg-0005Yh-R8 for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:18:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f2JCc-000072-1p for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:18:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53501) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f2JCb-00006r-Tg for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:18:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f2JCb-0005YY-O7 for bug-gnu-emacs@gnu.org; Sat, 31 Mar 2018 12:18:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Mar 2018 16:18:01 +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.152251304821317 (code B ref 30938); Sat, 31 Mar 2018 16:18:01 +0000 Original-Received: (at 30938) by debbugs.gnu.org; 31 Mar 2018 16:17:28 +0000 Original-Received: from localhost ([127.0.0.1]:33165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f2JC4-0005Xl-7o for submit@debbugs.gnu.org; Sat, 31 Mar 2018 12:17:28 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:41356) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f2JC2-0005XZ-Nw for 30938@debbugs.gnu.org; Sat, 31 Mar 2018 12:17:27 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2VGGwt5193611; Sat, 31 Mar 2018 16:17:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=bvlsEvcDzXfYV/0bdS2KuCq+NpnOO0lfW+05d2Se2+I=; b=P5JYYN8jJ+LSsrxxwG1LrtGleyQanWa9/JEp3tA7vy9rVSxJ8DdoFCMNIXax170yKp5K mzuMvwELr0I1ZgkjKISuh4YvPrRCYUEb1MoE/M59JnINZVDEcdPBmI6IKjuou8rlzjpo 5ikfXTs2PdoECFl24bhKvMCxTxrMbbfEtym0exovU5Nm+s/rqVHUqbqUgYaGAnDQYYQ8 ffNUXnCwkav5nlm7ee+mRDf0d5SNkFCFg9KMUle7smpDT4L8getiYavKmC55iOIlKHPF euKYtmG1LlBmB2y44CSJsuIlKuli/AtqD9eNJe6XGPcy6r1iwFXr+UiOkjl4Yf17nY5p NQ== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2h2dqa80p8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 31 Mar 2018 16:17:18 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2VGAhFV024120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 31 Mar 2018 16:10:43 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2VGAgKd015349; Sat, 31 Mar 2018 16:10:43 GMT In-Reply-To: <<838ta88vfz.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4666.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8849 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803310168 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:144763 Archived-At: > > A non-interactive use case for an arbitrary command that > > calls ` dired-get-marked-files' does not necessarily > > have `user-error' as the right behavior for an empty set > > of marked files. That's all I'm saying. >=20 > I'm sorry, but you lost me. Let me try explaining this from my POV. >=20 > 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. `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. 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. Code can tell `dired-get-marked-files' directly whether it should raise an error if there are no files gathered. What's missing is for callers of `dired-get-marked-files' to tell it that conditionally, based on whether they are called interactively. Being able to do that is for the benefit of reusing a command that calls `dired-get-marked-files' in different ways. It is not needed for the benefit of a command that calls `dired-get-marked-files' directly, as that choice is already under its control. > It is true that dired-aux.el commands that call dired-get-marked-files > all pass nil as ARG (and t as ERROR), but what would be the semantics > of, say, dired-do-isearch-regexp when no files are marked? That > command, and all the others which call dired-get-marked-files in the > same manner, is to do something on "all marked files", as their doc > string clearly says. >=20 > So why do we need to allow these commands to be invoked when no files > are marked, and expect them not to signal a user-error? For the benefit of a function that might call them and not want to raise that error. The interactive case for a command that calls `dired-get-marked-files' is completely known by that command. The context of a non-interactive use of the same command is not known to it. Its code should not prejudice the behavior intended by its caller. In the example of `insert-marked-subdirs-and-do-stuff', its call to `diredp-insert-subdirs' is _not_ its main purpose, and it is fine if there are no marked subdirs and thus none get inserted. For `i-m-s-a-d-s' to do its overall job, the call to `d-i-s' needs to tolerate no subdirs being marked and inserted, by being benign - a no-op. Although no marked subdirs (and point not on a subdir) _is_ a user error for interactively called `d-i-s', it is _not_ an error for interactively (or not) `i-m-s-a-d-s'. > IOW, even if dired-do-isearch-regexp and its ilk are invoked > non-interactively, they are invoked as result of some command up the > call-stack, so the invocation does come from the user.=20 The invocation of `d-d-i-r' comes ultimately from the user, as does the invocation of pretty much everything in Emacs. But the intention and purpose of `d-d-i-r' can be different - including wrt what no markings of particular files might mean - from the intention and purpose of an upstream command that directly or indirectly invokes `d-d-i-r'. There is no reason to assume that interactive and non-interactive use of a given command should have the same behavior wrt the new `dired-get-marked-files' arg ERROR. Such hardcoding provides no benefit and can get in the way. > And since > dired-do-isearch-regexp etc. are documented to act on marked files, it > sounds appropriate to signal an error when no files are marked. It is appropriate for _them_, i.e., when invoked interactively. It is not necessarily appropriate for something that calls them. > A feature which wants to allow users to get away silently in this case > can always check whether any files are marked and avoid calling > dired-do-isearch-regexp etc. if none are. It shouldn't have to. You are essentially suggesting that it too should invoke `dired-get-marked-files'. That shouldn't be necessary (not to mention that it can be costly). > That is why I asked for real-time use-cases where this gets in the > way: your argument sounds like a general philosophical issue to me: Call it what you like. Your argument hasn't even been presented so far, AFAICT. What are supporting reasons for a claim that we should _not_ distinguish interactive from non-interactive use for such commands and pass this along to `d-g-m-f'? > you claim that it's "completely inappropriate" for a utility function > to signal an error on theoretical grounds, while in reality I still > don't see any practical problem that cannot be easily resolved. If > your diredp-insert-subdirs is an example of a problem, then as I said > above, I don't understand why you couldn't just omit the last optional > argument to dired-get-marked-files, and be done. (And since ERROR was > _added_ in Emacs 27, your original code should have been already > future-proof against such changes anyway.) See above. The addition of optional arg ERROR was a _good_ thing. No, no code could have taken care of this before, without it. Typically, point is on a file line, and when no files are marked the command acts (purposefully) on the file of the current line. It is only rarely that point is in a buffer position where the new error kicks in. Another, more common, case where the error can kick in is (as for the case of `diredp-insert-subdirs') when a FILTER passed to `dired-get-marked-files' results in an empty file list. 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. The individual command needs to decide whether that is an error case. Similarly, for a command B that _invokes_ such a command A. It is up to B to decide whether to raise an error. If A systematically causes `d-g-m-f' to raise an error in a context where an error makes sense for A, that can conflict with what makes sense for B. 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 just gives the command (and its author) more choice. No reason to assume that its interactive use is the same as its non-interactive use, including wrt its use of `dired-get-marked-files'.