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: Ibuffer: w and B default to buffer at current line Date: Fri, 16 Sep 2016 07:53:23 -0700 (PDT) Message-ID: <3dbc0c03-56f9-4b6f-bd3b-258458967665@default> References: < > <<83intw5our.fsf@gnu.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 1474037707 28858 195.159.176.226 (16 Sep 2016 14:55:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Sep 2016 14:55:07 +0000 (UTC) Cc: tino.calancha@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii , John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 16 16:55:03 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 1bkuXN-0004jn-Dw for ged-emacs-devel@m.gmane.org; Fri, 16 Sep 2016 16:54:45 +0200 Original-Received: from localhost ([::1]:41879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkuXL-0005Fi-Lo for ged-emacs-devel@m.gmane.org; Fri, 16 Sep 2016 10:54:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkuWH-0005Bv-Ny for emacs-devel@gnu.org; Fri, 16 Sep 2016 10:53:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkuWF-0005iu-9K for emacs-devel@gnu.org; Fri, 16 Sep 2016 10:53:36 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:24476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkuWA-0005fY-AE; Fri, 16 Sep 2016 10:53:30 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8GErPAx016417 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2016 14:53:25 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u8GErOqD016033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2016 14:53:25 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8GErOM4002702; Fri, 16 Sep 2016 14:53:24 GMT In-Reply-To: <<83intw5our.fsf@gnu.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: userv0021.oracle.com [156.151.31.71] 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:207466 Archived-At: > > > If you compare the first patch with `dired-get-marked-files' (d-g-m-f= ) > > > you might change your mind: (d-g-m-f) returns a list with the file at > > > point when there are no marked files. The first patch follow similar= =20 > > > idea. > > > > I understand dired may also be taking this bad approach, but that's not > > a good reason to continue the practice. >=20 > But it isn't just Dired. Having the marked items default to the > current one is a very frequent idiom in Emacs modes that present lists > of actionable items. It is also consistent with what GUI file > managers out there do. >=20 > > Functions should do what they say, and not have lots of alternative > > functionality baked into them because it's a convenient hack today. >=20 > There's a clash here between this goal, and the goal of being > DWIMish. 1. Distinguish (a) behavior for users from (b) its implementation. I started to reply in a similar vein to Eli. On rereading John's mail I saw that he tried to separate what the behavior is for users from how the behavior is implemented, and his argument seems to be only about the latter (although it was not made as clearly as it might have been, IMO). IOW, I don't think John is arguing against the UI design of letting a key such as `C' or `F' in Dired have different behaviors depending on the use of a prefix arg. I think his only argument is about how that (good, not bad) behavior is implemented. He argues that there should be a separate function for acting on only the current line's file and not the marked files. And as I mentioned, it is often the case that there _is_ such a separate function. And it is often a command. But it is typically not bound to a key - it is used only for a menu-item binding, since the general `C', `F', etc. key does double-duty. There is generally no need to bind a key sequence to such a this-file command. Put differently, there already _is_ a key sequence that gives you that behavior: a prefix arg (`M-1') followed by the multiple-files key: act on only one file - this one. So I think this is some (not much) ado about nothing. The UI is a sound and useful one. And the implementation is also not bad - it generally does not conflict with John's request for single-purpose functions. Specific single-file functions are not always needed in Dired, but when they are needed (e.g., for a menu item), they exist. And a utility function that accepts args that control variant behaviors is also not necessarily a bad thing, IMO. No one would argue that `mapc' is bad because it is parameterized by a function argument that determines the outcome/behavior. No one would outlaw it because it violates a single-function-per-behavior principle. Likewise, no one would propose removing `if' because it allows for different behaviors. The devil is in the details. That's my critique of John's comments - too general/vague. To discuss whether there is really a problem in this case, the complaint should be specific, about the actual code, not just couched in general software-engineering terms. The talk of "bad approach" and "monkey-patching" was misplaced, I think. There is a sermon there, but I don't think there is a sinner to be preached to - only fellow choir members. I think that John spoke in too-general terms, with some hand-waving. Even if we single-purpose functions, so they satisfy John's "principled way", there can be an advantage, for interactive use, in combining them in _commands_ that can have multiple, alternative behaviors. I think John acknowledges this and even said much the same thing. And providing different behaviors in the same command is not just a holdover from "prior art". It is an important possibility/feature that the basic design of Emacs offers (and yes, that it has used in commands provided by default, from Day One). That does not mean that just any old throwing together of behaviors in a single command is a great idea. It means that some commands that provide for multiple behaviors can be good things, not bad. IOW, one size/principle does not fit all use cases. What justifies something like the prefix-arg behavior of Dired commands for marked files is not the fact that it is "prior art". No one argued that. That neither justifies nor invalidates it. What justifies it is the judgment that the behavior is helpful for users. That's where the argument about what behavior to provide needs to take place: in the realm of behavior for users. Not just in the realm of code organization for easy and sound maintenance. There are cleaner & dirtier ways, and easier & harder to maintain ways, to implement a given behavior. The question about the _usefulness for users_ of such Dired (or Ibuffer) commands is the question to address first. Questions of implementation choice should follow that question, not vice versa. I think (and hope) that John does not feel very different about this. 2. As for DWIM, which Eli mentions: This is not about DWIM. I distinguish (a) the ability for users to obtain different, alternative behaviors from a given command from (b) DWIM commands. The former gives the user full control. A DWIM command is some programmer's idea of what would be the right behavior within a given context. It is the command (code), not the user, that is in control. The behavior choice is essentially made at coding time. It is not made by the user, at runtime. That does not mean that DWIM is always stupid, bad, or misguided. It means only that it is something different from a user choosing to provide a given prefix arg, to get a particular member of a command's set of behaviors. In general, I'm strongly in favor of commands providing multiple behaviors, which a user can choose from. What is important is that (a) the behaviors somehow belong together in the same command, (b) the default behavior is the common one, and (c) the doc makes clear what the behaviors are and how to obtain them. To me, Dired's `dired-do-*' commands (`C', `F', etc.) are well designed. The alternative behaviors collected in the same command belong together; the commonly used behavior is the default; and the doc about them is clear enough.