From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Rationale behind conversion of a nil prefix arg to numeric 1 Date: Mon, 5 Sep 2016 10:04:34 -0700 (PDT) Message-ID: <56fae654-627a-41bd-8bdb-55418ed2e93f@default> References: <87y437c0qg.fsf@bertrandrussell.Speedport_W_723V_1_40_000> <83oa43d9r8.fsf@gnu.org> <06d4a7f1-f116-fb5c-9bd2-c4d1f98934c9@easy-emacs.de> <83k2ercy5u.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 1473095144 12511 195.159.176.226 (5 Sep 2016 17:05:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Sep 2016 17:05:44 +0000 (UTC) To: =?utf-8?B?QW5kcmVhcyBSw7ZobGVy?= , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Sep 05 19:05:40 2016 Return-path: Envelope-to: geh-help-gnu-emacs@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 1bgxKw-00024Y-AO for geh-help-gnu-emacs@m.gmane.org; Mon, 05 Sep 2016 19:05:34 +0200 Original-Received: from localhost ([::1]:55898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgxKu-0000ks-7S for geh-help-gnu-emacs@m.gmane.org; Mon, 05 Sep 2016 13:05:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgxKA-0000kZ-0V for help-gnu-emacs@gnu.org; Mon, 05 Sep 2016 13:04:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgxK5-0002QX-Ol for help-gnu-emacs@gnu.org; Mon, 05 Sep 2016 13:04:44 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgxK5-0002QN-Gm for help-gnu-emacs@gnu.org; Mon, 05 Sep 2016 13:04:41 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u85H4aGl010008 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2016 17:04:38 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u85H4YRe023681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2016 17:04:36 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u85H4YMd018555; Mon, 5 Sep 2016 17:04:34 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: 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: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:111270 Archived-At: > The ideosyncrasy: it yields the same value for arg =3D 1 as if no arg wer= e > given Idiosyncrasy? That's one way to look at it, I suppose. Similarly: `C-u' and `M-4' have numeric prefix-arg value 4; and `M--' and `C-u - 1' have numeric value -1. But they have different raw prefix-arg values. Idiosyncratic? If you like. Bothersome? Bad? Ugly? Not at all. There is simply a _mapping_ from raw prefix-arg values to numeric prefix-arg values. That mapping is realized by function `prefix-numeric-value'. There's really nothing mysterious or idiosyncratic about the behavior. It's just something to learn. Raw prefix arg !=3D numeric prefix arg. End of story. And whether or not a user explicitly provides a prefix arg, there is ALWAYS a numeric prefix-arg value (default =3D 1). This is really one of the first things that someone writing a command learns. It is NOT something that someone who uses a command needs to learn. But if a particular command has behavior that is different for different kinds of prefix arg then of course the command doc needs to describe the behavior. > Regardless of its purpose - such coding style should not > be encouraged. What does that mean? What style should be discouraged, and why? Just because a feature exists that allows code to distinguish various user behaviors wrt using a prefix arg, that does not mean that commands should NOT make use of that feature. And it does not mean that they MUST make use of it. Clearly, the _default_ behavior of a command, i.e., its behavior with no prefix arg provided by the user, should be the typical behavior. That does not mean that a command should not offer alternative behaviors, which make use of a prefix argument, provided those alternative behaviors are clearly documented. > It would be easy and consistent to write (or arg (setq arg 1)) What would be the point of writing that? That's essentially `(prefix-numeric-value arg)', except that if ARG is non-nil then you won't necessarily get a number; you'll get a number OR a cons OR the symbol `-'. Perhaps you were proposing a redesign, where there would be NO raw prefix arg, and the numeric value would try to do double-duty, to both be numeric and provide a way to test whether a prefix arg was actually provided by the user? There are good reasons why Emacs has a raw prefix arg, if that is your underlying question. For one thing, it lets code know how many `C-u's a user used: 0, 1, 2, 3... And that's handy because `C-u C-u' is quick to type. Just distinguishing zero, one, and two `C-u's gives a command 3 possible behaviors - no need to compare numeric values etc. It's really not a big deal. It's a flexible feature and is easy to learn. Admittedly (like much in Emacs), if you have not yet learned it, and you try to write a command that takes advantage of a prefix arg, then you might be surprised to learn it. Your surprise should be a welcome one, as you now know what you can do with it.