[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rationale behind conversion of a nil prefix arg to numeric 1

From: Andreas Röhler
Subject: Re: Rationale behind conversion of a nil prefix arg to numeric 1
Date: Sun, 4 Sep 2016 19:11:31 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.2.0

On 04.09.2016 16:23, Eli Zaretskii wrote:
Date: Sun, 04 Sep 2016 14:23:35 +0200
From: (Florian v. Savigny)

Naively, I used the numeric conversion of the prefix arg, i.e.

    (interactive "p")

which passes the prefix arg converted to a number. However, if I call
the function with no prefix argument, which is, expectedly, nil in raw
form, it converts this to the number 1. (This is what
`prefix-numeric-value' does, as explained in the docstring.)

While I understand that this is how it is done, I am quite puzzled
about the logic behind this. It would seem intuitive to me to convert
nil to either the number 0 or, again, nil, but never to the number
1. And practically, converting nil to 1 has the consequence that
calling the command with no prefix arg:

    M-x command

is exactly the same as calling it with a prefix arg of 1:

    C-u 1 M-x command

because the prefix arg converted to a number is 1 in both cases, which
reduces the number of possibilities of calling the command by one.

I can circumvent this (and get the behaviour that I would expect) by
writing the function with

    (if current-prefix-arg (prefix-numeric-value current-prefix-arg))

in an explicit interactive list, but I am still wondering about the
rationale of representing nil as the number one. Does this make sense,
or is it useful, in some way?
Yes.  Most commands use the argument as a repeat count, so having it
default to one makes perfect sense.

There a difference between "p" sending 1 and nil - which is the result from non-interactive use.
If a function needs a repeat count, it should provide some.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]