more than one prefix argument

more than one prefix argument

[Andreas Röhler]

Hi,

what about allowing more than one prefix argument
by making interactive codes "p" and "P" sending
truly separated.

Would reserve "p" for numerical args, while "P"
basically should send a kind of exception flag,
branching execution.

Below a use-case for it, yank-repeat should add
newlines if C-u follows the numeric argument.

As both inputs interfere, that's not possible that way
for now.

;; not working now
(defun yank-repeat-newline (arg &optional nl)
   "With numerical ARG, repeat last yank ARG times.
With optional arg NL, also insert newlines. "
   (interactive "p\nP*")
   (let ((nl nl)
         (num arg))
     (dotimes (i num)
       (if nl
           (insert (concat (car kill-ring) "\n"))
         (insert (car kill-ring))))))


Drew presented a solution at help-gnu-emacs@gnu.org:

;;;;;;;;;;;;;;;;;

As Teemu explained, there is only _one_ prefix arg. You can look at 
either its
numeric value or its raw value or both, but there is only ONE prefix arg.

You apparently want to have a prefix arg express both a numeric quantity 
and a
boolean.  If the user uses C-u (or its variants) to specify a (non-nil) 
prefix
arg then, well, the raw value is non-nil.  If the raw value is nil, then the
user did not use C-u (or its variants).

If you want to let the user specify a numeric value, default 1, and also 
specify
whether to add a newline, then one way to do that is to distinguish positive
from negative prefix arg (there's your boolean).

E.g.:

M-x yank...    -> just one, no newline
M-- yank...    -> one, newline
C-u -1 yank... -> one, newline
C-u -2 yank... -> two, newlines
C-u  2 yank... -> two, no newlines

Something like this:

(defun myyank (&optional arg)
   (interactive "p")
   (dotimes (i (abs arg))
     (if (natnump arg)
	(insert (car kill-ring))
       (insert (concat (car kill-ring) "\n")))))

;;;;;;;;;;;;;

However, that solution seems too complicated for a
part of non-programmers, it's not mnemonic, rather
tricky - even not uncommon in Emacs.

Would be glad to have C-u as general branch key.

Thanks all,

Andreas

--
https://launchpad.net/python-mode
https://launchpad.net/s-x-emacs-werkstatt/

Re: more than one prefix argument

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On 7/26/11 12:59 PM, Andreas Röhler wrote:
> Hi,
> 
> what about allowing more than one prefix argument
> by making interactive codes "p" and "P" sending
> truly separated.
> 

We already have more than one kind of prefix argument: see
universal-coding-system-argument for an example.  You can already define as many
kinds of "prefix argument" as you'd like: just define a global flag and a
command to set that flag, and have post-command-hook clear the flag unless (eq
this-command 'my-prefix-setting-function).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: more than one prefix argument

[Andreas Röhler]

Am 26.07.2011 22:10, schrieb Daniel Colascione:
> On 7/26/11 12:59 PM, Andreas Röhler wrote:
>> Hi,
>>
>> what about allowing more than one prefix argument
>> by making interactive codes "p" and "P" sending
>> truly separated.
>>
>
> We already have more than one kind of prefix argument: see
> universal-coding-system-argument for an example.  You can already define as many
> kinds of "prefix argument" as you'd like: just define a global flag and a
> command to set that flag, and have post-command-hook clear the flag unless (eq
> this-command 'my-prefix-setting-function).
>

Hi,

yes I can, thanks for the hints, which will be helpful.

Let may say however that things like

21.12 Prefix Command Argument

tells it, might be easier, more clear implemented IMHO, it reads:


    Here are the possible values of a raw prefix argument:

    * `nil', meaning there is no prefix argument.  Its numeric value is
      1, but numerous commands make a distinction between `nil' and the
      integer 1.

    * An integer, which stands for itself.

    * A list of one element, which is an integer.  This form of prefix
      argument results from one or a succession of `C-u''s with no
      digits.  The numeric value is the integer in the list, but some
      commands make a distinction between such a list and an integer
      alone.

;;;;;;;;;;

well, it's great:

numerous commands make a distinction between `nil' and the
      integer 1.

;;;;;;;;;

Indeed: (prefix-numeric-value nil) -->1
But does this make sense in a lisp-environement?

Booleans treat nil and 1 different:

(when 1 (message "%s" "1"))-->1
(when nil (message "%s" "1"))-->nil

Cheers,

Andreas

RE: more than one prefix argument

[Drew Adams]

> Indeed: (prefix-numeric-value nil) -->1
> But does this make sense in a lisp-environement?

Dunno what that means.  nil is not 1.  But (foo nil) might well be 1.  (length
nil) is 0, but that doesn't mean that nil is zero.

`prefix-numeric-value' is just a function that returns a number (always).  If
its arg is nil then it returns 1.  Nothing more to be said about it, really.

> Booleans treat nil and 1 different:
> (when 1 (message "%s" "1"))-->1
> (when nil (message "%s" "1"))-->nil

Yes.  `prefix-numeric-value' is not a Boolean function.  The numeric value of
the prefix arg is just that: a numeric value.  It is a number, never nil, so it
is useless as a (Lisp) Boolean value: it is always non-nil (true).

(Well, you could decide that some particular number or set of numbers
represented false, and then test that way, but you get the idea: it will not
return `nil'.)

The _raw_ value of a prefix arg can be nil, so you can use that as a Lisp
Boolean value (nil vs non-nil).  The raw value distinguishes presence and
absence: whether or not the user specified a prefix argument when invoking the
command.

It also distinguishes other things, however.  The raw arg is richer than its
reduction to a numeric value.  The raw prefix arg tells you pretty much what the
user did - whether s?he hit `C-u C-u C-u' or `C-u 3 2 9' or `M--' etc.

If you want to let the user distinguish several cases using a prefix arg, then
you want to do it using the raw arg.  You can test whether the arg is a cons or
nil or `-'; you can test its numeric value; etc.  And you can test it in
different ways at the same time: both a cons and numeric value = 16, etc.

RE: more than one prefix argument

[Drew Adams]

> > what about allowing more than one prefix argument
> > by making interactive codes "p" and "P" sending
> > truly separated.
> 
> We already have more than one kind of prefix argument: see
> universal-coding-system-argument for an example.  You can 
> already define as many kinds of "prefix argument" as you'd
> like: just define a global flag and a command to set that
> flag, and have post-command-hook clear the flag unless (eq
> this-command 'my-prefix-setting-function).

I don't think that's what Andreas is asking about.  He's not asking about being
able to define alternative "prefix arg"-like things (to be used separately).  I
think he wants the same user input to somehow distinguish two different things
(?).

At least that's my understanding.  IMO, he is simply confused, and defining
alternative prefix-arg-like things won't help him here.

Put differently, having the user use different prefix-arg-like things is similar
to having the user use a positive vs negative prefix arg.  And that's apparently
not what he wants.

He seems to want the user to use the _same_ behavior (no key difference) to
somehow get two different command behaviors.  Again, that's my guess about what
he's asking.

Re: more than one prefix argument

[Andreas Röhler]

Am 26.07.2011 22:36, schrieb Drew Adams:
>>> what about allowing more than one prefix argument
>>> by making interactive codes "p" and "P" sending
>>> truly separated.
>>
>> We already have more than one kind of prefix argument: see
>> universal-coding-system-argument for an example.  You can
>> already define as many kinds of "prefix argument" as you'd
>> like: just define a global flag and a command to set that
>> flag, and have post-command-hook clear the flag unless (eq
>> this-command 'my-prefix-setting-function).
>
> I don't think that's what Andreas is asking about.  He's not asking about being
> able to define alternative "prefix arg"-like things (to be used separately).  I
> think he wants the same user input to somehow distinguish two different things
> (?).
>
> At least that's my understanding.  IMO, he is simply confused,

Hi Drew,

maybe you are right. Then we must wait. I'll try to sum up the matter 
for the moment:

current use of "p" and "P" might be enhanced. There is an intermix 
between both, doing nearly, but not precisely, the same.

"P" quite often is used for completely different things than sending a 
number.

(if (eq 4 (prefix-numeric-value))

is used as a branch command. That's the interesting about it indeed.

However, that's not clean. It's bad to read, because the fact of "4" has 
no meaning by themselves here. That's obscure programming style.

In general let me stress: I'm living very well with Emacs as it is. Just 
saying: we can live still better.

Cheers and thanks,

Andreas


  and defining
> alternative prefix-arg-like things won't help him here.
>
> Put differently, having the user use different prefix-arg-like things is similar
> to having the user use a positive vs negative prefix arg.  And that's apparently
> not what he wants.
>
> He seems to want the user to use the _same_ behavior (no key difference) to
> somehow get two different command behaviors.  Again, that's my guess about what
> he's asking.
>
>
>

Re: more than one prefix argument

[Tim Cross]

On Wed, Jul 27, 2011 at 4:25 PM, Andreas Röhler
<andreas.roehler@online.de> wrote:
> Am 26.07.2011 22:36, schrieb Drew Adams:
>>>>
>>>> what about allowing more than one prefix argument
>>>> by making interactive codes "p" and "P" sending
>>>> truly separated.
>>>
>>> We already have more than one kind of prefix argument: see
>>> universal-coding-system-argument for an example.  You can
>>> already define as many kinds of "prefix argument" as you'd
>>> like: just define a global flag and a command to set that
>>> flag, and have post-command-hook clear the flag unless (eq
>>> this-command 'my-prefix-setting-function).
>>
>> I don't think that's what Andreas is asking about.  He's not asking about
>> being
>> able to define alternative "prefix arg"-like things (to be used
>> separately).  I
>> think he wants the same user input to somehow distinguish two different
>> things
>> (?).
>>
>> At least that's my understanding.  IMO, he is simply confused,
>
> Hi Drew,
>
> maybe you are right. Then we must wait. I'll try to sum up the matter for
> the moment:
>
> current use of "p" and "P" might be enhanced. There is an intermix between
> both, doing nearly, but not precisely, the same.
>
> "P" quite often is used for completely different things than sending a
> number.
>
> (if (eq 4 (prefix-numeric-value))
>
> is used as a branch command. That's the interesting about it indeed.
>
> However, that's not clean. It's bad to read, because the fact of "4" has no
> meaning by themselves here. That's obscure programming style.
>
> In general let me stress: I'm living very well with Emacs as it is. Just
> saying: we can live still better.
>
> Cheers and thanks,
>
> Andreas
>

While P and p are similar, I'm not sure they are as similar as you
imply. Consider a very simple example. You have a function and you
want it to use a prefix arg and you want the raw form because you want
to distinguish between no prefix arg and C-u 1 or M-1. You then define
a second function, but this time, you want it to default to 1 if no
prefix arg or whatever the value is if one is provided, then the 'p'
numeric version is what you want. In each case, the P and p support
what you need without you having to do additional code. Yes, you could
solve this with just the P version, but then you would have to do more
code to handle the common case of just wanting to process the prefix
arg as a number.

This additional code would likely make the reading of the source even
more difficult than your example issue with the use of '4' in your
example. I would also suggest that if you don't like the literal 4 as
it doesn't make it clear what is going on (why 4?) you could define a
variable, such as

Re: more than one prefix argument

[Andreas Röhler]

Am 27.07.2011 11:25, schrieb Tim Cross:
[ ... ]
> While P and p are similar, I'm not sure they are as similar as you
> imply. Consider a very simple example. You have a function and you
> want it to use a prefix arg and you want the raw form because you want
> to distinguish between no prefix arg and C-u 1 or M-1. You then define
> a second function, but this time, you want it to default to 1 if no
> prefix arg or whatever the value is if one is provided, then the 'p'
> numeric version is what you want. In each case, the P and p support
> what you need

yes, but one of them would be sufficient.

OTOH we have not a handy code for branching.

Do you know case, "p" receiving M- numeric arg must fail, so C-u NUMBER 
through "P" is needed?


  without you having to do additional code. Yes, you could
> solve this with just the P version, but then you would have to do more
> code to handle the common case of just wanting to process the prefix
> arg as a number.
>
> This additional code

Don't suggest additional code but a better use of "P" - no parallel 
implementations. Having "P" as a branch-flag not affected by "p"

  would likely make the reading of the source even
> more difficult than your example issue with the use of '4' in your
> example. I would also suggest that if you don't like the literal 4 as
> it doesn't make it clear what is going on (why 4?) you could define a
> variable, such as
>

Re: more than one prefix argument

[Tim Cross]

On Wed, Jul 27, 2011 at 7:37 PM, Andreas Röhler
<andreas.roehler@online.de> wrote:
> Am 27.07.2011 11:25, schrieb Tim Cross:
> [ ... ]
>>
>> While P and p are similar, I'm not sure they are as similar as you
>> imply. Consider a very simple example. You have a function and you
>> want it to use a prefix arg and you want the raw form because you want
>> to distinguish between no prefix arg and C-u 1 or M-1. You then define
>> a second function, but this time, you want it to default to 1 if no
>> prefix arg or whatever the value is if one is provided, then the 'p'
>> numeric version is what you want. In each case, the P and p support
>> what you need
>
> yes, but one of them would be sufficient.
>
> OTOH we have not a handy code for branching.
>
> Do you know case, "p" receiving M- numeric arg must fail, so C-u NUMBER
> through "P" is needed?
>
>
>  without you having to do additional code. Yes, you could
>>
>> solve this with just the P version, but then you would have to do more
>> code to handle the common case of just wanting to process the prefix
>> arg as a number.
>>
>> This additional code
>
> 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. Essentially, we would need the raw form. 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?

tim

Re: more than one prefix argument

[Andreas Röhler]

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.

> Essentially, we would need the raw form.


why?

We need a number or a boolean.
"p" should send a number, 1 as default.
"P" a boolean, nil as default.


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)

Cheers,

Andreas

> tim
>

Re: more than one prefix argument

[Andreas Schwab]

Andreas Röhler <andreas.roehler@online.de> writes:

> We need a number or a boolean.

You need to distinguish C-u and 4 as well.

> "p" should send a number, 1 as default.
> "P" a boolean, nil as default.

"P" is the raw prefix.  "p" is what prefix-numeric-value returns from
it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: more than one prefix argument

[Andreas Röhler]

Am 27.07.2011 13:21, schrieb Andreas Schwab:
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>> We need a number or a boolean.
>
> You need to distinguish C-u and 4 as well.
>

C-u would send `t'

If the command needs a 4 too possibly, write  "p\nP" than enabling both 
input

>> "p" should send a number, 1 as default.
>> "P" a boolean, nil as default.
>
> "P" is the raw prefix.  "p" is what prefix-numeric-value returns from
> it.

double-wouble

lets have sent at once whats needed.


>
> Andreas.
>

Re: more than one prefix argument

[Andreas Schwab]

Andreas Röhler <andreas.roehler@online.de> writes:

> Am 27.07.2011 13:21, schrieb Andreas Schwab:
>> Andreas Röhler<andreas.roehler@online.de>  writes:
>>
>>> We need a number or a boolean.
>>
>> You need to distinguish C-u and 4 as well.
>>
>
> C-u would send `t'

What about C-u C-u then?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: more than one prefix argument

[Tim Cross]

On Wed, Jul 27, 2011 at 9:46 PM, Andreas Röhler
<andreas.roehler@online.de> wrote:
> Am 27.07.2011 13:21, schrieb Andreas Schwab:
>>
>> Andreas Röhler<andreas.roehler@online.de>  writes:
>>
>>> We need a number or a boolean.
>>
>> You need to distinguish C-u and 4 as well.
>>
>
> C-u would send `t'
>

which means now your possible values are both numeric and non-numeric,
requiring extra tests and increasing code complexity.

> If the command needs a 4 too possibly, write  "p\nP" than enabling both
> input
>

How would you distinguish between that and multiple c-u's as in

C-u C-u C-i C-u M-x command

which ones are p and which ones are P?

>>> "p" should send a number, 1 as default.
>>> "P" a boolean, nil as default.
>>
>> "P" is the raw prefix.  "p" is what prefix-numeric-value returns from
>> it.
>
> double-wouble
>
> lets have sent at once whats needed.
>
>

The shiraz tonight was very nice - I don't know if its you or me, but
I can't follow! Sorry.

Tim

Re: more than one prefix argument

[Tim Cross]

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

RE: more than one prefix argument

[Drew Adams]

> > Essentially, we would need the raw form.
> 
> why?  We need a number or a boolean.
> "p" should send a number, 1 as default.
> "P" a boolean, nil as default.

I answered this, I think.  The raw arg provides a way to distinguish in the code
pretty much whatever the user did.  You can distinguish `C-u C-u' from `C-u 1 6'
and `M-1 6', and so on.

You cannot distinguish every user prefix-arg action using the raw arg (e.g. `C-u
1 6' and `M-1 6' are indistinguishable), but it is still pretty good.  (There
are some ways to get the keys that were pressed in order to distinguish them,
but they don't have to do with the prefix arg per se.)

You might or might not take advantage of this fine-grained distinction in any
given command definition.  But you can if you want.  Your command can let the
user use different prefix-arg actions to get different behaviors for the same
command.

Yes, integers alone would be sufficient to give users an unlimited number of
ways to invoke a command.  You could distinguish the numeric prefix values 1, 2,
3, 4 (or other) instead of distinguishing, say, nil, plain C-u, zero, and
non-zero.

And integers alone obviate needing a separate Boolean distinction.  And there is
not necessarily any _need_ to distinguish user actions such as `M-1 6' vs `C-u
C-u'.

But other prefix-arg combinations can be handier for users to use or easier to
remember.  Vive la difference.  You have choices when writing a command.

If you are confused about "p" and "P" and want to avoid confusion, you can limit
yourself to using one or the other.  For example, always use just "p" and have
your users always distinguish behavior only by number.  Nothing wrong with that
if that's what you prefer.

Re: more than one prefix argument

[Tim Cross]

On Wed, Jul 27, 2011 at 7:25 PM, Tim Cross <theophilusx@gmail.com> wrote:
> On Wed, Jul 27, 2011 at 4:25 PM, Andreas Röhler
> <andreas.roehler@online.de> wrote:
>> Am 26.07.2011 22:36, schrieb Drew Adams:
>>>>>
>>>>> what about allowing more than one prefix argument
>>>>> by making interactive codes "p" and "P" sending
>>>>> truly separated.
>>>>
>>>> We already have more than one kind of prefix argument: see
>>>> universal-coding-system-argument for an example.  You can
>>>> already define as many kinds of "prefix argument" as you'd
>>>> like: just define a global flag and a command to set that
>>>> flag, and have post-command-hook clear the flag unless (eq
>>>> this-command 'my-prefix-setting-function).
>>>
>>> I don't think that's what Andreas is asking about.  He's not asking about
>>> being
>>> able to define alternative "prefix arg"-like things (to be used
>>> separately).  I
>>> think he wants the same user input to somehow distinguish two different
>>> things
>>> (?).
>>>
>>> At least that's my understanding.  IMO, he is simply confused,
>>
>> Hi Drew,
>>
>> maybe you are right. Then we must wait. I'll try to sum up the matter for
>> the moment:
>>
>> current use of "p" and "P" might be enhanced. There is an intermix between
>> both, doing nearly, but not precisely, the same.
>>
>> "P" quite often is used for completely different things than sending a
>> number.
>>
>> (if (eq 4 (prefix-numeric-value))
>>
>> is used as a branch command. That's the interesting about it indeed.
>>
>> However, that's not clean. It's bad to read, because the fact of "4" has no
>> meaning by themselves here. That's obscure programming style.
>>
>> In general let me stress: I'm living very well with Emacs as it is. Just
>> saying: we can live still better.
>>
>> Cheers and thanks,
>>
>> Andreas
>>
>
> While P and p are similar, I'm not sure they are as similar as you
> imply. Consider a very simple example. You have a function and you
> want it to use a prefix arg and you want the raw form because you want
> to distinguish between no prefix arg and C-u 1 or M-1. You then define
> a second function, but this time, you want it to default to 1 if no
> prefix arg or whatever the value is if one is provided, then the 'p'
> numeric version is what you want. In each case, the P and p support
> what you need without you having to do additional code. Yes, you could
> solve this with just the P version, but then you would have to do more
> code to handle the common case of just wanting to process the prefix
> arg as a number.
>
> This additional code would likely make the reading of the source even
> more difficult than your example issue with the use of '4' in your
> example. I would also suggest that if you don't like the literal 4 as
> it doesn't make it clear what is going on (why 4?) you could define a
> variable, such as
>

Oops - hit send before I was ready!

what I was going to say is that using a literal 4 can be seen as
possibly poor style because it does not convey much meaning regarding
code intention. However, I would expect if that was a concern, instead
of a literal 4, you would use a variable which is bound to that value
and which has a name that more accurately expresses meaning/intention.
So, while this may be a valid point, I don't see it as specific to the
us of P or p.

What I don't understand is what you are proposing as an alternative
and why it would be better. Just getting rid of 'p' and keeping 'P'
doesn't seem to buy us anything except we now have to explicitly
convert to numeric values when we want them. We can't not have 'P' as
sometimes we need to distinguish between 1 and nil. Having both seems
a useful convenience.

I don't know if Drew's assessment of what you are asking is correct or
not, but I do think you need to clarify your argument and suspect his
suggestion concerning more thought may be correct.

Tim