Re: more than one prefix argument

[Tim Cross <theophilusx@gmail.com>]

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