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#30285: dired-do-chmod vs. top line of dired Date: Wed, 31 Jan 2018 15:20:22 -0800 (PST) Message-ID: <5dd33d7a-b418-4c60-9891-ec2e21f21fe1@default> References: <87mv0wg80c.fsf@jidanni.org> <87efm8snnr.fsf@gmail.com> <83efm8irac.fsf@gnu.org> <87d11sl08v.fsf@gmail.com> <87fu6lwxxu.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1517440769 7751 195.159.176.226 (31 Jan 2018 23:19:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Jan 2018 23:19:29 +0000 (UTC) Cc: 30285@debbugs.gnu.org, Tino Calancha , jidanni@jidanni.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 01 00:19:24 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 1eh1ep-0000rN-KM for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Feb 2018 00:19:11 +0100 Original-Received: from localhost ([::1]:39261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eh1gp-0007zX-3X for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 Jan 2018 18:21:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eh1gg-0007yj-VI for bug-gnu-emacs@gnu.org; Wed, 31 Jan 2018 18:21:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eh1gc-0003tb-Uc for bug-gnu-emacs@gnu.org; Wed, 31 Jan 2018 18:21:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43755) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eh1gc-0003t9-PA for bug-gnu-emacs@gnu.org; Wed, 31 Jan 2018 18:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eh1gc-0006WW-Fo for bug-gnu-emacs@gnu.org; Wed, 31 Jan 2018 18:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 31 Jan 2018 23:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30285-submit@debbugs.gnu.org id=B30285.151744083925027 (code B ref 30285); Wed, 31 Jan 2018 23:21:02 +0000 Original-Received: (at 30285) by debbugs.gnu.org; 31 Jan 2018 23:20:39 +0000 Original-Received: from localhost ([127.0.0.1]:51652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eh1gF-0006Va-0J for submit@debbugs.gnu.org; Wed, 31 Jan 2018 18:20:39 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:35538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eh1gD-0006VN-5S for 30285@debbugs.gnu.org; Wed, 31 Jan 2018 18:20:37 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0VNGikq137732; Wed, 31 Jan 2018 23:20:30 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=QKoE9a68c4YlT9F3WWD/b1YYo0HcbZLCzOmpOI4Yb2Y=; b=d83VEHTM/5vhuSRBSJI9jvBgyoSfpb8l7y2rL8T37/frNAeu0sJfEdsTnMy8k9rFQh+j Prxdnguv+vhWQ80zba/w+9NVjis1s0n3alD4LhrWguuS0pUEMwUiUsUM1M0RsObBojtX qojf6ntQTIK+x2na4cPJ0t7nrzS105mBkxGZwPq6Wk9DNIGVGlT2UtMIhqvosePIkb8Q fUjuzYG8dlkz1p6RIWPeX9sS3erEPoazryHRMkzuMOS9sZVyDT6ejyF70KB/iM3twT3S 5WrldqsTCgObMd+7RN3rjdAgaMR4KBvEaIy1Bwx84DbbrOs93jsgDnZr05/dPzO7RwS3 dg== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2fucd9kg4u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 Jan 2018 23:20:30 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0VNKS3I031135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 31 Jan 2018 23:20:28 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0VNKNCQ029955; Wed, 31 Jan 2018 23:20:23 GMT In-Reply-To: <87fu6lwxxu.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4639.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8791 signatures=668659 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=869 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310286 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:142755 Archived-At: > > Yes, it makes sense for such commands to do nothing or to show an > > error message when on the "top line of dired", as described in the > > bug report. >=20 > Instead of doing nothing or showing an error message, how about > doing a more useful thing: when on the top line, =E2=80=98dired-do-chmod= =E2=80=99 > could do chmod on all files in the dir. Not a good idea, IMO. Too easy to do accidentally. At the very least it would need to ask for confirmation specially. `m', `d', and `w', which are the keys that you are talking about, to not do anything to the files in question. They affect only the Dired listing or the `kill-ring'. That's quite different from something like `chmod'. And in any case, such shortcut behavior is not needed at all (see next). > This is exactly what other Dired commands already do: e.g. typing =E2=80= =98m=E2=80=99 > on the top line or on any other subdir headerline, they perform > their actions on all files. Which is why what you propose isn't needed. Just `m' then `M'. If someone is going to act on lots of files, s?he had better be aware of that. Best is that they are first marked before acting on them. But yes, it's true that not needing to change marks can be handy. I.e., you have some files marked for a given reason already, and you want to keep those markings. (You could use `* c' to temporarily change marks, but that's a bit roundabout.) That handiness (not losing existing markings) is the reason why in my Dired+ code, for commands that normally act on the marked files (or the N next files, with numeric prefix arg N), you can use multiple plain `C-u' to act on all files, ignoring markings: Just what "all" files means changes with the number of `C-u', as follows: `C-u C-u' - Use all files present, but no directories. `C-u C-u C-u' - Use all files and dirs except `.' and `..'. `C-u C-u C-u C-u' - use all files and dirs, `.' and `..'. (More than four `C-u' act the same as two.) But I don't think that's a good idea in the current context. I'd suggest that we just let someone use `m' (on that non-file line) followed by `M' etc. I think that this bug should be handled by doing what Dired usually does when point is on a non-file line (_anywhere_, not just on a directory header line or its "total..." line) - as I said earlier: just raise a `user-error'. You'll note too that `m' on a non-file line other than the dir header line does _not_ do what you describe. * On the "total..." line it marks the first file line (which is now `..' in Windows but used to be `.'). * On the blank line before an inserted subdir header it does the same thing: it marks the first file line of that subdir listing. * On any other non-file line, such as the blank line at the end of the buffer, it does nothing at all. So the `m' (`dired-mark') behavior is quite variable, even if it can be useful. Note too that the other two commands that act specially on a (sub)dir header line do not do the same thing as `dired-mark'. * `dired-copy-filename-as-kill' does not act similarly at all. It copies the subdir name instead of names of any files in its listing. * `dired-flag-file-deletion' does act somewhat similarly to `dired-mark': it flags all of the files (other than `.' and `..') in the subdir listing - except if the region is active. In the latter case it flags the files in the region. And that need not mean any files in the subdir listing - it could be just files in the previous listing. Or it could be files in the subdir listing plus files in other, subsequent subdir listings. > For example, see the docstring of =E2=80=98dired-mark=E2=80=99: > =E2=80=9CIf on a subdir headerline, mark all its files except `.' > and `..'.=E2=80=9D >=20 > > No, we don't need a function `dired-marked-files-or-file-at-point-p', > > for that or anything else. The `dired-do-*' commands already DTRT > > wrt the marked-files-or-file-at-point. >=20 > I agree that it's better to check the =E2=80=98files=E2=80=99 returned fr= om > =E2=80=98dired-get-marked-files=E2=80=99.