From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Dired: Improve symmetry in mark/unmark commands bound to keys Date: Sat, 24 Sep 2016 16:49:49 -0700 (PDT) Message-ID: <956c08c7-abd8-4cf5-aa70-bcd85f8f3499@default> References: <877fa12iyq.fsf@linux-m68k.org> <83h995ay04.fsf@gnu.org> <87y42h13pi.fsf@linux-m68k.org> <83fuopax4g.fsf@gnu.org> <87twd512pk.fsf@linux-m68k.org> 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 1474761050 5541 195.159.176.226 (24 Sep 2016 23:50:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Sep 2016 23:50:50 +0000 (UTC) Cc: tino.calancha@gmail.com, emacs-devel@gnu.org To: Andreas Schwab , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 25 01:50:46 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bnwiR-0000SI-5Q for ged-emacs-devel@m.gmane.org; Sun, 25 Sep 2016 01:50:43 +0200 Original-Received: from localhost ([::1]:35943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnwiP-00087M-F5 for ged-emacs-devel@m.gmane.org; Sat, 24 Sep 2016 19:50:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnwhl-00087C-HU for emacs-devel@gnu.org; Sat, 24 Sep 2016 19:50:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnwhk-00059M-Al for emacs-devel@gnu.org; Sat, 24 Sep 2016 19:50:01 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:19530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnwhg-00058J-2z; Sat, 24 Sep 2016 19:49:56 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8ONnraO007860 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2016 23:49:54 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u8ONnr4W029235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2016 23:49:53 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u8ONno1a003819; Sat, 24 Sep 2016 23:49:51 GMT In-Reply-To: <87twd512pk.fsf@linux-m68k.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207769 Archived-At: > The prefix was obviously never > intented to be used with this command. The only intented use of the > second argument was the its caller, dired-flag-extension. That is easy > to prove, because before commit 736b582 it wasn't even documented in the > doc string. Yes. More importantly, we can do what we think is best. What do we really need? 1. We need for `dired-flag-extension' to work. With the current implementation that means calling `dired-mark-extension' with a `D' mark. 2. We need a command for changing the mark character that is used for the currently marked files. We have that: `* c' (`dired-change-marks'). 3. We need a command to mark files that have a given extension. We have that: `* .' (`dired-mark-extension'). 4. We need a command to unmark files that have a given extension. We do NOT have this. 5. Do we need a command that marks files that have a given extension and prompts you for which mark character to use? This is currently provided by `* .' with a prefix arg. I agree with Tino and Andreas that #5 is not needed. It has never been used, AFAICT. #2 suffices for getting whatever marks you want. I agree with them also that we do not need a new, separate command for #4, and that we should let `* .' also unmark, with a prefix arg. Two possibilities, if we want that behavior for `* .': a. Redefine `dired-mark-extension' to do that. In this case, the implementation of #1 needs to change (provide a helper). b. Define a new command. Call it `dired-mark-or-unmark-extension'. For (b): The other commands for which a prefix arg unmarks rather than marks do NOT have "-or-unmark" in the name. Should they, to distinguish them from those that only mark or only unmark? For example, should `dired-mark-files-regexp' be called `dired-mark-or-unmark-files-regexp'? That brings us back to the question of thread "Ibuffer: w and B default to buffer at current line". I think we should name the commands after only the _default_ behavior, i.e., what happens if you do not use a prefix arg. So I'd argue for just making `dired-mark-extension' unmark with a prefix arg (and providing a different helper function for `dired-flag-extension') - unless someone can point out how using a prefix arg to specify the mark character is actually useful for `* .'. On the other hand, there are some commands that only mark or unmark, and for which either (a) the opposite behavior is not useful or (b) the prefix arg is used for something else, and two different keys might be provided for marking and unmarking. For example, `* m' just marks, and `* u' just unmarks. Such exceptions also include `* ?' (`dired-unmark-all-files') and `* !' (`dired-unmark-all-marks'). Other than such exceptions, should commands that currently only mark or unmark, and for which both operations are useful, also do double-duty, via a prefix arg? For example, should `* s' unmark all with a prefix arg (one of Tino's proposals)? =20 Most commands that unmark also unflag - they remove all marks, including `D' (deletion flag). The doc strings make this clear - except the doc string of `dired-unmark'. Shouldn't that doc string also make this clear? There is maybe a little room for some minor cleanup and making the command set a bit more consistent. On the other hand, all things are not equal, and forcing consistency where it is not appropriate is not the answer either. There is no imperative to paint with a broad brush. In most cases there are good reasons for the current command behavior, I think.