From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: more than one prefix argument Date: Wed, 27 Jul 2011 22:46:01 +1000 Message-ID: References: <4E2F1C8C.9010802@easy-emacs.de> <4E2F1F1C.2040100@gmail.com> <850340AFD6324E979275501249A9240C@us.oracle.com> <4E2FAF6D.2050905@online.de> <4E2FDC71.5070305@online.de> <4E2FE6AC.8070706@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1311770773 16765 80.91.229.12 (27 Jul 2011 12:46:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2011 12:46:13 +0000 (UTC) Cc: Daniel Colascione , Drew Adams , emacs-devel@gnu.org To: =?ISO-8859-1?Q?Andreas_R=F6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 27 14:46:09 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qm3V0-0004ug-I9 for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 14:46:06 +0200 Original-Received: from localhost ([::1]:46201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm3Uz-0003fD-OF for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 08:46:05 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm3Ux-0003f8-Qi for emacs-devel@gnu.org; Wed, 27 Jul 2011 08:46:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qm3Uw-0003Ia-JS for emacs-devel@gnu.org; Wed, 27 Jul 2011 08:46:03 -0400 Original-Received: from mail-yi0-f41.google.com ([209.85.218.41]:39549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm3Uw-0003IU-FZ for emacs-devel@gnu.org; Wed, 27 Jul 2011 08:46:02 -0400 Original-Received: by yia13 with SMTP id 13so1181729yia.0 for ; Wed, 27 Jul 2011 05:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MPzDakWFN2t5WlarcunZUsvJNlhyOZBGkt8qRn8TVQI=; b=Y1LxBLnqmCtDtMJalvGUByBRoEt5axmWHrCMjcbehZKAfjZXNYFSK1LOaLR6N4Pihe Za8+iKSBbDRGHFoXLWH6z0i4785jUGRqyRCLYLEKxzDgoB8LiENcAymDhbvFw+qNgrW5 nXBs+DuyI//gVbstquTuOmjOB6XXX/3oEKdg4= Original-Received: by 10.42.59.74 with SMTP id l10mr22507ich.62.1311770761699; Wed, 27 Jul 2011 05:46:01 -0700 (PDT) Original-Received: by 10.231.37.76 with HTTP; Wed, 27 Jul 2011 05:46:01 -0700 (PDT) In-Reply-To: <4E2FE6AC.8070706@online.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.218.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142385 Archived-At: On Wed, Jul 27, 2011 at 8:21 PM, Andreas R=F6hler wrote: > Am 27.07.2011 11:48, schrieb Tim Cross: > [ ... ] >>> >>> Don't suggest additional code but a better use of "P" - no parallel >>> implementations. Having "P" as a branch-flag not affected by "p" >>> >> >> Sorry, just not quite following your argument. >> >> If we were to get rid of one, it would have to be the numeric version >> (i.e. p) rather than P as sometimes you need to be able to distinguish >> between nil and 1. > > Could you give a case for that? IMHO we have to distinguish between nil a= nd > t at these occasions. Looks like wrongly reffered c-style limitation, whi= ch > we gladly don't have business with. > Well, its common for a boolean test to be between nil and a non-nil value - t is not necessary. You can only get nil with P - with 'p' you get 1 for both nil, C-u 1 and M-:, which is not ideal. With P you get nil for no prefix of any form and a non-nil value for any prefix. I don't think it is too hard to imagine a circumstance where you might have a command which has a default behavior with a nil prefix arg and some other behavior, determined by the value of the argument. Maybe it inserts no tab for a nil argument and n tabs if their is a prefix argument depending on the value of the prefix? >> Essentially, we would need the raw form. > > > why? Because its the only firm that will give a real nil value for no prefix argument. > > We need a number or a boolean. > "p" should send a number, 1 as default. > "P" a boolean, nil as default. > > That distinction seems very arbitrary and does not fit with other concepts. For example, a boolean test in an if statement has nil or the empty list as false and all other values as true. Your suggestion seems to imply we would treat 1 as nil, which seems potentially confusing and inconsistent. > This means >> >> that whenever you need to process the prefix argument as a number you >> will need to test and convert it to distinguish nil and extract the >> value from the list - this would be additional code ini your function. >> >> I don't understand what you mean by having a handy code for branching. >> Can you give an example of how this code would work and how a command >> using this code would be called? >> > > How do you switch an alternative now? > Quite often that is done with an negative or positive numeric value. > (abbrev-mode -1) > (abbrev-mode 1) > > Bad style IMHO, C-like obfuscating the code. > > much better would be > > (abbrev-mode nil) > (abbrev-mode t) > or (abbrev-ode nil) and (abbrev-mote 1), but so what? It seems to me that you can currently code it how you like. You can use 'P'' and treat nil as false and non-nil as true or you can use 'p' and treat 1 as false and non-1 as true (though I don't like it). So, currently, you can use it how you as the programmer prefer. I still don't see how or even what exactly your proposal does to improve the problems you see and find it difficult to even recognise there is a problem. For arguments sake, assume we keep -p' as it is and we change the semantics of 'P' to what you think it should be. What would be those semantics and how would it improve what we currently have? How would you deal with situations where nil means default behavior and non-nil means modified behavior where the modified behavior depends on the value of the argument i.e. nil and 1 need to be distinguished from each other. Tim