From: Tim Cross <theophilusx@gmail.com>
To: "Andreas Röhler" <andreas.roehler@online.de>
Cc: Daniel Colascione <dan.colascione@gmail.com>,
Drew Adams <drew.adams@oracle.com>,
emacs-devel@gnu.org
Subject: Re: more than one prefix argument
Date: Wed, 27 Jul 2011 22:46:01 +1000 [thread overview]
Message-ID: <CAC=50j9jCLthzzmeUi+=shx_1p-SPQpW9tr-1UX09nPTmaoPtw@mail.gmail.com> (raw)
In-Reply-To: <4E2FE6AC.8070706@online.de>
On Wed, Jul 27, 2011 at 8:21 PM, Andreas Röhler
<andreas.roehler@online.de> 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 and
> t at these occasions. Looks like wrongly reffered c-style limitation, which
> 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
next prev parent reply other threads:[~2011-07-27 12:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-26 19:59 more than one prefix argument Andreas Röhler
2011-07-26 20:10 ` Daniel Colascione
2011-07-26 20:36 ` Andreas Röhler
2011-07-26 20:57 ` Drew Adams
2011-07-26 20:36 ` Drew Adams
2011-07-27 6:25 ` Andreas Röhler
2011-07-27 9:25 ` Tim Cross
2011-07-27 9:37 ` Andreas Röhler
2011-07-27 9:48 ` Tim Cross
2011-07-27 10:21 ` Andreas Röhler
2011-07-27 11:21 ` Andreas Schwab
2011-07-27 11:46 ` Andreas Röhler
2011-07-27 12:39 ` Andreas Schwab
2011-07-27 12:51 ` Tim Cross
2011-07-27 12:46 ` Tim Cross [this message]
2011-07-27 15:09 ` Drew Adams
2011-07-27 9:38 ` Tim Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=50j9jCLthzzmeUi+=shx_1p-SPQpW9tr-1UX09nPTmaoPtw@mail.gmail.com' \
--to=theophilusx@gmail.com \
--cc=andreas.roehler@online.de \
--cc=dan.colascione@gmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.