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: [found the culprit] Date: Wed, 14 Nov 2018 11:40:23 -0800 (PST) Message-ID: <2e24a1f8-944a-4f04-aa71-491a670a15f5@default> References: <875zx1xgiq.fsf@mat.ucm.es>> <83lg5w9956.fsf@gnu.org> <87d0r76ewm.fsf_-_@mat.ucm.es>> <87tvkjq2mh.fsf_-_@mat.ucm.es>> <834lcj8y1f.fsf@gnu.org>> <83y39v7gym.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 1542224359 21969 195.159.176.226 (14 Nov 2018 19:39:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Nov 2018 19:39:19 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 14 20:39:15 2018 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 1gN10L-0005aR-TI for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 20:39:14 +0100 Original-Received: from localhost ([::1]:33885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN12S-0004zH-An for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 14:41:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN11n-0004yx-SB for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:40:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gN11e-0000Ff-EY for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:40:41 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:51810) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gN11c-0000CD-9W for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:40:34 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wAEJdXkC071504; Wed, 14 Nov 2018 19:40:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=UF27VCJZWWE0JH7+mTp9TwzidTGTJFRgvVzETvrz3x0=; b=dI1uyJdlSJ5R6NeF/Y4zfq1l+R0JDMAmyVq14qzbFINhEQrgsoi3GxvMvMqq9s/Fl+JU jetLBfb0o1fxZ8y091wOhvxMkO/+cRa/Mm8xp1l1RaWHLwvGPdoaAtiNZCLSo84In2q5 EiaUFMDm1medD4XuJEAPSwKuHXtDwnKo0Uud6WPmPNsbEWz5uGyd0JQtu2gUasb0KBZA HNvrMsG3cj/df67hV9BcB4b4KCTiPGMvFw2Mfbr1KS6mIjdjquRGWr7jcnzIAT8oKmhI h91Gh89tCWvKLgYnYQMZ3S74tOAEA8OSE+QPOvcmb51CF+oHXHIG+LAKM3FAF9j31e9c cw== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2nr7cs5m80-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 19:40:26 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wAEJePLX028740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 19:40:25 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAEJeNtO020962; Wed, 14 Nov 2018 19:40:25 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9077 signatures=668683 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-1810050000 definitions=main-1811140174 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.78 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:231146 Archived-At: > > I just mentioned what it uses, and has used for a > > long time. And it's a general scheme, applied to `dired-do-*' > > commands generally. The conflict is not a minor one, e.g., > > affecting just `Z'. >=20 > FWIW, I don't think it's a good scheme. And I (who use it) think it's a good scheme. ;-) > Better would have more mark-management commands that > you can then combine with any dired command We already have great mark-management commands, including the ability to define multiple sets of files using different marks (not-known-well-enough key `* c'). > without having to fight with conflicting uses of C-u. There's no fight with conflicting uses of `C-u'. I already explained that it fits well with the existing prefix arg use for `dired-do-*'. It only interprets multiple plain `C-u' specially. Do you really think that someone needs to rely on being able to use `C-u C-u C-u' to specify the current file, instead of just `C-u'? That makes no sense to me. > E.g. commands to "push" and "pop" the current set of marked files, See `* c'. I'm guessing that that's the kind of thing you're aiming for. But it's more general than just a stack: direct access to anywhere in the "stack", to change any set of markings to another, anytime. > and a command that you can iterate like your C-u which will first mark > the current file, then the files in the current directory, then ... > A nice advantage to C-u is that these would give you visual feedback > about which files are selected. So you in fact propose a completely different use of `C-u' from what Emacs has always used for `dired-do-*'. Talk about fighting with conflicting uses of `C-u'! That retains nothing of what we have now wrt a prefix arg. Anyway, if that's what you want for vanilla Emacs, go for it. > > 2. How does the above C-u usage "not follow > > Emacs's use of C-u"? >=20 > Emacs usually does not use multiple C-u "Usually does not use" does not mean that using multiple `C-u' does not follow Emacs's use of `C-u'. Not in the sense of some prescribed use, in any case. Emacs usually does not distinguish plain `C-u' from numeric use. It doesn't usually do so because usually - for most commands - there is only one prefix-arg behavior. (Actually zero, for most.) It would be silly to suppose that there were some unwritten "rule" that "Emacs use" is to not use prefix args, just because most commands don't use a prefix arg. Same thing for a command recognizing different kinds of prefix arg: don't confuse frequency of use with prescription of whether or not to use. > and also tries to avoid > distinguishing between "just C-u" and "a numeric > argument". I see no indication that Emacs avoids that. Just because most commands offer only one prefix-arg behavior, and so there is no need to distinguish, that doesn't mean that there is an unwritten convention to avoid such distinction. And if there were such a convention (preferably written), I'd oppose it - but that's just me. I think the existence of the prefix-arg "feature" is a good thing. If it didn't exist it would be good to invent it. Same thing for the various different kinds of prefix arg - I'm thankful for them. (I sometimes even wish there were more.) > There are exceptions to both of those "rules", I don't agree that there any such rules. There are just commands that do not (yet) offer more than one behavior. Lots of them. So what? And I don't think Emacs should have such "rules". On the contrary, I think there are many commands that could benefit from adding alternative behaviors by way of a prefix arg. As opposed, for example, to adding lots of additional key bindings. Give me one command and key binding for a related set of operations, some of which I use much less often, rather than N commands, bound to N keys, with N doc strings that are similar but subtly different ... for the same set of behaviors as that one key with prefix-arg possibilities. Saves keys, puts less-used behaviors on slightly more cumbersome bindings (you have to use a prefix arg for them), groups related behaviors on similar keys, facilitates discoverability and recall... > and I'm to blame for some of those > exceptions, but I think this case is not a good candidate for an > exception because there are too many "sets of files" that the user > might like to specify, so we'll be better served by providing this separa= tely > than trying to cleverly cram some common cases into the narrow C-u. It's OK to disagree. ;-) If I thought there were other, more common sets of files that users typically want to act on with Dired then I'd no doubt use those sets instead. These are the most common sets that I, at least, want to act on - they are all ways of acting on "all" files. Such cases are about as important to me as the case of wanting to act on just the current-line file. Just like that special case (yes, yet another special prefix-arg case that is built into Emacs), it's about being able to act on files while ignoring (and so not needing to change and restore) the current markings. I'll add this, which you might or might not agree might be relevant: you've said in the past that you don't even use Dired, or at least that you don't use it much. (That doesn't in any way invalidate your arguments, either about acting on files in Dired or about the prefix arg in general.)