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: naming functions [was: Ibuffer: w and B default to buffer at current line] Date: Sun, 18 Sep 2016 10:55:30 -0700 (PDT) Message-ID: <054178e6-00ee-48ec-8799-3845c79675cd@default> References: <<< >>>> <<<<83intw5our.fsf@gnu.org>> <3dbc0c03-56f9-4b6f-bd3b-258458967665@default> >>> <<<<83zin630i9.fsf@gnu.org>> <024f1fd0-80ee-4780-bebb-c935959851bc@default>> <<83vaxuib1p.fsf@gnu.org>>> <> <<83poo1i8nf.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 1474221369 22753 195.159.176.226 (18 Sep 2016 17:56:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Sep 2016 17:56:09 +0000 (UTC) Cc: jwiegley@gmail.com, emacs-devel@gnu.org, tino.calancha@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 18 19:56:04 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 1blgJp-0004Py-BL for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 19:55:57 +0200 Original-Received: from localhost ([::1]:51060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blgJn-0000ya-FL for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 13:55:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blgJg-0000yJ-MF for emacs-devel@gnu.org; Sun, 18 Sep 2016 13:55:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blgJe-0006qU-1L for emacs-devel@gnu.org; Sun, 18 Sep 2016 13:55:47 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:42975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blgJV-0006lF-LF; Sun, 18 Sep 2016 13:55:38 -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 u8IHtWTh008001 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Sep 2016 17:55:33 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u8IHtWq6018404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Sep 2016 17:55:32 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8IHtV4F012357; Sun, 18 Sep 2016 17:55:31 GMT In-Reply-To: <<83poo1i8nf.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: 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:207572 Archived-At: > > > > Yes, of course. But as I pointed out, the case at=20 > > > > hand has nothing to do with DWIM. > > > > > > I disagree. > > > > And your reason is? A user _explicitly specifies_ > > which to use, of the behaviors the command supports. > > How is that guess-what-I-mean-and-do-it? >=20 > See what John wrote. The issue at hand is broader than what=20 > you interpreted it to be. Please point to something that John said that you think speaks for you here and answers the question: What is your reason for thinking that simply having a prefix arg choose an alternative behavior is DWIM? > > Is `forward-char` a DWIM command, simply because it can > > move different distances depending on a prefix arg? Your answer to that is yes? If so, why? ---- Wrt command (and other function) names (John's point): Name choices are limited. Doc strings are there to clarify things. John: Is `forward-char' a bad name, because with a negative prefix arg it moves backward? Is it a bad name because it is singular and a prefix arg > 1 moves further than one position? Should the name have been `move-char' or `move-chars'? If so, then what about binding forward and backward default behaviors to different keys, `C-f' and `C-b'? I think (hope) you get the point. A function name only goes so far toward indicating what the function does. If a prefix arg to a command chooses alternative behavior, then it would often be cumbersome and _less_ clear to users, to use a name that tries to summarize all of the behaviors. Finally, adding `dwim' to a command name is really just punting - pretty much all of the time. By definition, it says almost nothing about what the command does. In the worst case it says, loud and clear, "I can't give a good name to this command. I can barely describe it in the doc string." Using `dwim' in a command name tells the user only this: This command has multiple behaviors, some of which you might be able to control, and some of which might be determined otherwise by the use context. See the doc string for what this command really does. Consider these vanilla Emacs commands, which comment and uncomment the region: `comment-region', `comment-dwim', `comment-or-uncomment-region', `comment-line'. They all comment & uncomment the region, but in different ways. None of those names is great, and none of those commands is more or less DWIMish than the others. OK, such naming is historical. `comment-region' was first. `comment-or-uncomment-region' was added to provide a slightly different behavior. Its name more clearly points out that it can be used to UNcomment. (It is unfortunate, IMO, that more users do not think to use `comment-region', including for UNcommenting, because it is a great command. Its uncommenting behavior is superior to that of `comment-dwim', `comment-line', and `comment-or-uncomment-region'. But yes, its name does not advertise the fact that it can uncomment.) Presumably, John, between the two names `comment-region' and `comment-or-uncomment-region' you would favor the latter. I would too, and it is much better than `comment-dwim', which says only, "Sorry - see the doc string to find out what this command does." But consider that there are _many possible_ commands that comment or uncomment region text. The above are all in vanilla Emacs, and I and others have come up with still other such commands. (I use my command `comment-region-lines', which is like `comment-region', except that it (un)comments whole lines that are (at least partly) included in the region.) Emacs is made to end up with multiple such commands. They cannot EACH be called `comment-or-uncomment-region' or even `comment-dwim'. And to name each of them in a way that would describe its behavior more clearly and _distinguish it from the others_ would result in long and incomprehensible names. And then, when another such command is defined (in Emacs proper or in a 3rd-party library), some or all of them might (logically) need to be REnamed, to properly distinguish all of the meanings. This might be seen as less of a problem if you ignore the wider Emacs world outside core Emacs development. But it is nevertheless a difficulty _inherent in the nature_ of something like Emacs. Names only go so far, toward conveying behavior/meaning. And naming is historical. And labels such as "dwim' do NOT help to convey the specific meaning of a command. They just punt to the doc string. So while this general principle is a good one: A function's name should describe its behavior, and none of the behavior should be hidden behind a misleading name. In practice, in a context like Emacs, things are more complex. This is particularly the case when it comes to commands. And particularly when there are two commands, bound to keys, that are more or less symmetrical - such as `forward-char' and `backward-char'. Each is, in fact, a command that moves point one or more chars backward or forward. Neither moves only forward or only backward. But we want 2 different commands, for 2 different keys. In Emacs, the command naming policy has generally been this: Name a command for its _default_ behavior, and describe all of the alternative behaviors in the doc string. That works pretty well, in general. Yes, the default behavior does NOT tell the whole story - by definition. But it is often, even generally, the case that a command name _cannot_ usefully tell the whole story. (That does not imply that the command behavior is ill-conceived.) In particular, putting `dwim' in a command name is a poor cop-out. The default behavior should generally be used for the command name, even for a DWIM command. (On the other hand, if it is simple to describe the various behaviors in the name, then that can sometimes be better. `comment-or-uncomment-region' is better than just `comment-region'). Some might think that putting `dwim' in a command name is important for advertising the fact that there _are_ multiple behaviors. I don't buy that argument. It is just another Look-ma-no-hands!, Tu-m'as-vu ! exclamation, akin to NEW!!! IMPROVED!!! SUPER!!!! There might be a temporary effect, for a new command named `*-dwim-*', that it attracts attention and gives the (mistaken) impression that other commands do _not_ have multiple behaviors or do _not_ have behavior that depends on the context. Over time, such a name is seen for what it is: "dwim" in the name is just noise. We should avoid lazily naming commands with `dwim'. It's the equivalent of the Marketing-Speak "smart": smart car, smart phone, smart train, smart tech, smart goal, smart tuition, smart exchange, smart growth, smart manufacturing, smart health, smart grid, smart cloud, smart design, smart card, smart package, smart kit, smart keyboard, smart material, smart TV,... Nothing is duller. Nothing says less that is helpful. DWIM, like WYSIWYG, is a clever acronym. But it doesn't say much, if anything.