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: naming functions [was: Ibuffer: w and B default to buffer at current line] Date: Sun, 18 Sep 2016 16:24:12 -0700 (PDT) Message-ID: 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>> <054178e6-00ee-48ec-8799-3845c79675cd@default> 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 1474241087 3422 195.159.176.226 (18 Sep 2016 23:24:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Sep 2016 23:24:47 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, tino.calancha@gmail.com To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 19 01:24:40 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 1bllRv-0008Nm-2z for ged-emacs-devel@m.gmane.org; Mon, 19 Sep 2016 01:24:39 +0200 Original-Received: from localhost ([::1]:51854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bllRt-0006Jl-Gf for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 19:24:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bllRj-0006JV-45 for emacs-devel@gnu.org; Sun, 18 Sep 2016 19:24:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bllRh-0008PJ-Bn for emacs-devel@gnu.org; Sun, 18 Sep 2016 19:24:26 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bllRd-0008NW-30; Sun, 18 Sep 2016 19:24:21 -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 u8INOFCq018217 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Sep 2016 23:24:15 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 u8INOEDO019332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Sep 2016 23:24:15 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8INOEU8013545; Sun, 18 Sep 2016 23:24:14 GMT In-Reply-To: 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:207593 Archived-At: > > 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? >=20 > > 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'? >=20 > > 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. >=20 > The only point I'm seeing here is that we've been imprecise > with our function names in the past. No, that is not the point. I tried to make clear that in this example `forward-char' is a good name, not a bad name. It is _not_ a bad name just because it is singular and a prefix arg > 1 moves further than one position. It is _not_ a bad name just because a negative prefix arg reverses its direction from forward to backward. It is a _good_ name because it describes the _default_ behavior well: move forward one character. And the doc string, not the function name, has the job of describing the full behavior. It is not often that a command that has multiple possible behaviors can reasonably have all of those behaviors reflected well in the command name. When it can, great. But what if it cannot? Even the simple command `forward-char' (few are simpler) has multiple behaviors. Some might even call it "dwim" because of this (I wouldn't). Even this simple command raises interesting questions that speak to points that you raised about the behavior and name of a function (command in this case). It doesn't get much simpler than this, and yet the issues for design policy discussed here so far are all present in this case. > That is not a valid argument for how we should assess > patches in the future. No, of course not. But no one suggested it is. No one has made the argument you seem to keep opposing, that _just because_ something misguided was done in the past, it should be done again. > Yes, `forward-char' is misleading. `move-point' might > have been a better choice. You see, that's exactly _not_ the point I was making. (And not because `move-point' doesn't mention the unit of the move: char, or buffer position (vs word, sexp, etc.).) Please see this question, which you did not address, and which gets to the point: > > If [you think that `forward-char' should have been > > called `move-point'], then what about binding forward > > and backward default behaviors to different keys, > > `C-f' and `C-b'? If we want the convenience of two different key bindings, one moving forward by default and the other backward by default, AND if we want the convenience of binding those keys to named commands (and not, e.g. for backward, (lambda (n) (interactive "p") (move-point (- n)))), then what to call those two commands? It's a serious question. `move-point-1' & `move-point-2'? Nah, those aren't great. What would you call them, if you could start over? And if you want the names here to try to reflect what these two commands actually can do, summarizing all of the behaviors, then those names will be, I think, > > cumbersome and _less_ clear to users What would you propose for those two different command names, if not `forward-char' and `backward-char'? `move-point' won't work for both. Would you go for something like this? `move-forward-1-char-but-maybe-more-and-maybe-backward' `move-backward-1-char-but-maybe-more-and-maybe-forward' Again, nah; those aren't great. But it's a serious question, starting from the aim of wanting names that don't mislead by suggesting there is only one direction and only one distance of movement. If the command names are to reflect more than the default case, what should they be in this (simple) case? Emacs policy/convention/tradition/history/habit has generally been to name commands after their _default_ behaviors: * singular: `char', not `chars' - even though a prefix arg can result in moving a different distance * one with `forward' in the name and one with `backward' - even though a negative prefix arg reverses the direction That's a simple approach. It's the best I've come across. But I truly would like to hear of something better, for Emacs. > What I will do, however, is reject the belief that because > it happened in the past, this makes it OK to extend > existing functions like this for the sake of expediency. Again, that's good, but I don't think anyone has made such an argument. > I hope we can agree on the essential point here: don't > pollute the behavior of functions because it's easy to > do so. With just a bit of extra work, we can avoid > unnecessarily increasing our technical debt. AFAICT, no one has disagreed with that - but good. Agreed. That, however, does not address the interesting issues you raised, about function naming and about when/whether/how a function can have multiple, alternative behaviors. I'm comfortable with what Emacs has generally done in the past in this regard, but we can certainly put it in question, if you feel strongly about it. Maybe there is a better approach? What would be the effect of a one-behavior-per-function policy and a function-name-reflects-full-behavior policy? What would those mean, for instance, for simple commands such as `forward-char' and `backward-char'? Yes, I know that you acknowledged that commands, as opposed to non-interactive functions, _can_ have multiple behaviors. But my impression is that you still would like to see a command name reflect the full behavior. I would too, when feasible, but I think that is _not_ the usual case. As for what behaviors should be combined in the same command, I'm happy to see that you've said essentially the same thing I said: The behaviors need to somehow belong together - a command should not be a hodge-podge of unrelated behaviors. People can disagree about what specific behaviors belong together, but hopefully we can at least agree on the general idea of them being related in some useful way. (There will always be lumpers and splitters, etc.)