Rationale behind conversion of a nil prefix arg to numeric 1

[Florian v. Savigny]

Hi there,

I've written one or two functions whose invocation I modeled on Unix
file permission bits (where a single digit is always unambiguously
either 1, 2 and 4 or some sum of them; thus, possible values are 1, 2,
3 (1 + 2), 4, 5 (1 + 4), 6 (2 + 4) and 7 (1 + 2 + 4)) because I felt
it was quite a nifty way of passing a command zero, one, two or three
"flags" at once via an optional prefix argument. (Apart from the fact
that it's quite easy to forget which number means which flag.)

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?


Thanks for any enlightenment!

Florian




--

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld

[Eli Zaretskii]

> Date: Sun, 04 Sep 2016 14:23:35 +0200
> From: flo...@fsavigny.de (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.

[Andreas Röhler]

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.

[Andreas Röhler]

On 04.09.2016 20:33, Eli Zaretskii wrote:
>> From: Andreas Röhler <andreas...@easy-emacs.de>
>> Date: Sun, 4 Sep 2016 19:11:31 +0200

>>
>>>> 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.

> "p" is documented as the _numeric_ value of the argument. So it
> obviously cannot yield nil.

The ideosyncrasy: it yields the same value for arg = 1 as if no arg were
given:

(defun foo (&optional arg)
(interactive "p")
(message "My ARG: %s" arg)
(message "Value of arg: %s" (prefix-numeric-value arg)))


;; called without ARG
(foo)
==> "My ARG: nil"
==> "Value of arg: 1"

;; called without ARG 1
(foo 1)

==> "My ARG: 1"
==> "Value of arg: 1"


Regardless of its purpose - such coding style should not be encouraged.

It would be easy and consistent to write

(or arg (setq arg 1))

[Eli Zaretskii]

> From: Andreas Röhler <andreas...@easy-emacs.de>
> Date: Mon, 5 Sep 2016 09:16:00 +0200

>
> The ideosyncrasy: it yields the same value for arg = 1 as if no arg were
> given:

Commands that need to distinguish between those should not use "p".

[Drew Adams]

> > Commands that need to distinguish between those should not use "p".
>

> Exactly.
> Just treat the "p" (lowercase p) interactive form as the special case
> where you only need to deal with numeric arguments and the default numeric
> argument is 1.
>
> If you need to deal with numeric, nil and other non-numeric arguments like
> (4), (16), etc, use the "P" (uppercase p) interactive form. The "P"
> interactive form passes the args to the function in their raw, untouched
> form.

What Eli and Kaushal said.

Again, this is a _feature_. You just need to learn what it is about
(and what it is not about). The doc is quite clear - give it a try.

In particular, if your code wants to know WHETHER a prefix argument
was EXPLICITLY provided by the USER, then you need to test the RAW
prefix argument. If you then want to know what the NUMERIC value
is, use `prefix-numeric-value':

(defun foo (arg)
(interactive "P") ; <=== uppercase P: RAW prefix arg
(if (not arg)
(no-prefix-arg-provided---usual/default-case)
(let ((nval (prefix-numeric-value arg)))
(cond ((= 42 nval) (answer-to-everything-it-seems))
((> nval 0) (at-least-its-positive))
((< nval 0) (so-negative!))
(t (nothing-at-all))))))

If you want to check for PARTICULAR non-nil raw prefix values:

(if (not arg)
(no-prefix-arg-provided---usual/default-case)
(cond ((= arg '-) (handle-M--))
((= arg '-42) (handle-M---4-2-or-C-u---4-2)) ; etc.
((= arg '4) (handle-M-4--or-C-u-4))
((and (consp arg) (= 4 (car arg))) (handle-plain-C-u))
((and (consp arg) (= 16 (car arg))) (handle-plain-C-u-C-u))
...))

Note that `C-u' gives `(4)' as the raw prefix arg, and `C-u 4' gives
`4' as the raw prefix arg. And `prefix-numeric-value' gives `4' in
both cases.

Experiment:

(defun foo (arg)
"Show the raw prefix arg and its numeric value."
(interactive "P")
(message "ARG: %S, Numeric value: %S"
arg (prefix-numeric-value arg)))

The case that this thread is about is just this one: `M-x foo'.
(Much ado about nothing.)

[Drew Adams]

> The ideosyncrasy: it yields the same value for arg = 1 as if no arg were
> given

Idiosyncrasy? That's one way to look at it, I suppose.

Similarly: `C-u' and `M-4' have numeric prefix-arg value 4;
and `M--' and `C-u - 1' have numeric value -1. But they have
different raw prefix-arg values. Idiosyncratic? If you like.
Bothersome? Bad? Ugly? Not at all.

There is simply a _mapping_ from raw prefix-arg values to
numeric prefix-arg values. That mapping is realized by
function `prefix-numeric-value'. There's really nothing
mysterious or idiosyncratic about the behavior. It's just
something to learn.

Raw prefix arg != numeric prefix arg. End of story. And
whether or not a user explicitly provides a prefix arg,
there is ALWAYS a numeric prefix-arg value (default = 1).

This is really one of the first things that someone writing
a command learns. It is NOT something that someone who uses
a command needs to learn.

But if a particular command has behavior that is different
for different kinds of prefix arg then of course the command
doc needs to describe the behavior.

> Regardless of its purpose - such coding style should not
> be encouraged.

What does that mean? What style should be discouraged, and why?

Just because a feature exists that allows code to distinguish
various user behaviors wrt using a prefix arg, that does not
mean that commands should NOT make use of that feature. And
it does not mean that they MUST make use of it.

Clearly, the _default_ behavior of a command, i.e., its behavior
with no prefix arg provided by the user, should be the typical
behavior. That does not mean that a command should not offer
alternative behaviors, which make use of a prefix argument,
provided those alternative behaviors are clearly documented.

> It would be easy and consistent to write (or arg (setq arg 1))

What would be the point of writing that?

That's essentially `(prefix-numeric-value arg)', except that
if ARG is non-nil then you won't necessarily get a number;
you'll get a number OR a cons OR the symbol `-'.

Perhaps you were proposing a redesign, where there would be
NO raw prefix arg, and the numeric value would try to do
double-duty, to both be numeric and provide a way to test
whether a prefix arg was actually provided by the user?

There are good reasons why Emacs has a raw prefix arg, if
that is your underlying question. For one thing, it lets
code know how many `C-u's a user used: 0, 1, 2, 3...

And that's handy because `C-u C-u' is quick to type. Just
distinguishing zero, one, and two `C-u's gives a command 3
possible behaviors - no need to compare numeric values etc.

It's really not a big deal. It's a flexible feature and is
easy to learn. Admittedly (like much in Emacs), if you have
not yet learned it, and you try to write a command that
takes advantage of a prefix arg, then you might be surprised
to learn it. Your surprise should be a welcome one, as you
now know what you can do with it.

[Drew Adams]

> > This is really one of the first things that someone writing
> > a command learns.
>

> Oops. I must confess this did not happen in my case.

I should not have been so black-&-white in saying that.

I really meant that only in the context of writing commands that
use a prefix arg, and in particular, commands where not explicitly
providing a prefix arg has a different behavior from providing a
prefix arg of 1.

IOW, it only matters if you in fact care about whether the user
provided a prefix arg. If you are writing a command where the
prefix arg is used only as the number of times to repeat the
behavior then you will likely not be aware of, or see the point
of, a raw prefix argument.

> I have written
> commands in Elisp for about 15 years, and I although I was soon
> familiar with there somehow being a "raw" prefix arg (meaning I often
> read this term in passing), I nevertheless always thought C-u was
> simply a way of passing a command a number. (I did not even know that
> you can also pass prefix commands typing M-..)

I'm sure your experience is not unusual. See above: if you never
write a command that cares whether the user provided a prefix arg
then you are not so likely to have learned this.

> > It's really not a big deal. It's a flexible feature and is
> > easy to learn. Admittedly (like much in Emacs), if you have
> > not yet learned it, and you try to write a command that
> > takes advantage of a prefix arg, then you might be surprised
> > to learn it. Your surprise should be a welcome one, as you
> > now know what you can do with it.
>

> Absolutely, at least now. Your post has been a very enlightening
> lecture indeed, as have the other explanatory posts. (I am wondering
> why I never grasped it from the Elisp Manual, but I guess because you
> have stated the whys and wherefores, it is much easier for me to store
> in memory somewhere.)

It's often the case that the same bit of info really registers
only after we've come into contact with the particular problem
(use case) that it was put there to address.

> Thanks very much to you all!

Thanks for posing the question, as I'm sure you are not the
only one for whom the question and the answer are helpful.

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Sep 06, 2016 at 11:45:28AM +0200, Florian v. Savigny wrote:
>
>
> > Alternatively, for Andreas the axiom "the default value is always 0"
> > holds ;-P
>
> I do sympathise with him, because my question started out supposing
> exactly the same thing. It just seems intuitive that nil translates to
> the number 0, if any, and when things are intuitive, this is (I think)
> generally good.

Definitely. Andreas' viewpoint is in some way understandable.

> It all becomes immediately clear when you understand that the numeric
> prefix arg has a special purpose, i.e. is conceived as a repeat
> counter (and NOT simply a number), but only then. In other words,
> `prefix-arg-as-repeat-counter' might be the kind of name that would be
> more readily understandable (and would even arguably be more accurate)
> than `prefix-numeric-value'.

I.e. "when the action is multiplicative, use the multiplicative neutral
element (i.e. 1) as default, not the additive (ie. 0) ;-)

But I'll shut up now.

regards and thanks for your lenience

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfOmi0ACgkQBcgs9XrR2karDgCfQaGjbKee0Mal3uWFra1zyyZA
NDsAn3N/VAm6Vxzt+ddMBtitINtiXO7k
=sy/y
-----END PGP SIGNATURE-----

[Florian v. Savigny]

> IIUC `prefix-numeric-value' is a more complex thing than providing a
> repeat counter - which it does for lower p.

I thought I had understood that

(interactive
(list
(prefix-numeric-value current-prefix-arg)))

was exactly the same as

(interactive "p")

Or isn't it? Then I am really confused. (But a test I just ran seems
to confirm that it is.)

> But let's go back to the simplest case of lower p in interactive spec:
>
> What is easier to read/grasp
>
> (setq counter (or arg 1)
>
> or
>
> (setq counter (prefix-numeric-value arg))

Or, alternatively,

(defun foo (counter)
(interactive "p")
...
)


(But of course, only if I have understood that correctly.)

But as to your question: Of course your first suggestion is easier to
grasp.

But IIHUC, one would normally do it the way I have just sketched, and
the idea of the "numeric prefix arg" was probably to supply an easy
(i.e. short) way to use the prefix arg as a repeat counter. And if my
example is correct, that solution isn't that bad.

BTW, I have just understood another interesting detail: That there
ALWAYS is a prefix arg, even if the user does not supply one, and you
do not have to say

(defun foo (&optional counter)
(interactive "p")
...
)

in the specific case where your optional arg is the prefix arg. That,
arguably, also adds idiosyncrasy.

> IOW: in favor of avoiding these complex, tricky things. Let's have the
> code as explicit as possible.

I totally agree, but as Eli has pointed out, Elisp was designed the
way it was designed a long while back. I guess prefix args have been
around almost since the very beginnings. Changing something about very
fundamental things like that would mean having to change A LOT OF very
fundamental code, without breaking anything. The question then would
simply be: Who is up for this job?

In other words, even though I like Emacs a lot, I think it is only
fair to call Elisp idiosyncratic in some ways. But if it is worth
fixing these, I think, is simply what Eli might call a question for a
rainy day.

I presume that the things that seem so idiosyncratic or somewhat
obscure about Elisp (e.g. not only prefix args, but also the way lists
are constructed, the reason why there are several kinds of sequences,
obarrays) were not deliberately designed to be hard to understand (or
to make Emacs privy to the initiated only), but that all had a lot to
do with the technical limitations at the time. (Meaning there was
perhaps not even a real alternative.) So now they are there, and
changing them now would have very different consequences than deciding
on a feature when you design a language anew has.

(FWIW, I think this is precisely the reason why Larry Wall decided to
break compatibility between Perl 5 and Perl 6, making Perl 6 simply a
new language. Accidently, one of the design goals of Perl 6 was: being
more intuitive than Perl 5.)

On the other hand, when I read the node "Command Loop -> Prefix
Command Arguments" in the Elisp Manual, I wonder how anyone CANNOT be
confused about prefix args, because this node starts out with the
unfortunate sentence:

Most Emacs commands can use a "prefix argument", a number
specified before the command itself.

If I am not mistaken, this promotes precisely the misunderstanding
that I had fallen prey to.

In contrast, other unintuitive features of Elisp are quite well
explained in the manual. (List construction -- the cons cell stuff --
and sequences are two things I remember understanding quite readily
from reading it, and in both cases it would never have occurred to me
to intuitively assume they worked like that.)

Maybe it would be a good idea if somebody simply rewrote some of the
/documentation/ on prefix args, such that the innocent, naive user
understands the point of the two representations? Because that is
something that can be easily rewritten without breaking any code.

I'll volunteer for the job if somebody checks!

[Drew Adams]

> > IIUC `prefix-numeric-value' is a more complex thing than providing a
> > repeat counter - which it does for lower p.
>
> I thought I had understood that
> (interactive (list (prefix-numeric-value current-prefix-arg)))
> was exactly the same as
> (interactive "p")

It is. You understand correctly.

> Or isn't it? Then I am really confused. (But a test I just ran seems
> to confirm that it is.)

+1 for testing.

> > But let's go back to the simplest case of lower p in interactive spec:
> > What is easier to read/grasp

> > (setq counter (or arg 1)) or (setq counter (prefix-numeric-value arg))

>
> Or, alternatively, (defun foo (counter) (interactive "p") ...)
>

> But IIHUC, one would normally do it the way I have just sketched, and
> the idea of the "numeric prefix arg" was probably to supply an easy
> (i.e. short) way to use the prefix arg as a repeat counter. And if my
> example is correct, that solution isn't that bad.
>
> BTW, I have just understood another interesting detail: That there
> ALWAYS is a prefix arg, even if the user does not supply one, and you
> do not have to say (defun foo (&optional counter) (interactive "p") ... )
> in the specific case where your optional arg is the prefix arg.

Correct. Similarly for "P" (raw prefix arg), in which case the
value is nil if a user provided no prefix arg.

The point of &optional is for Lisp code. With &optional you can
use (foo); without &optional you must use (foo nil) to get the
same effect. (You can also use (foo 1) if "p" is the `interactive'
arg.)

Most functional (or nearly functional) languages do not allow
for an arbitrary number of arguments. Instead, for the same
behavior as &rest, a function just accepts a list argument (in
effect, an explicit list of arguments). Not a big difference,
really. Admittedly, the use of &optional and &rest arguments
can be surprising, and hence perhaps confusing at first.

> That, arguably, also adds idiosyncrasy.

I don't think this has anything to do with a prefix argument.
It's about &optional. If you do not use &optional then the
argument is required. If you use &optional it defaults to nil.
That's all.

> > IOW: in favor of avoiding these complex, tricky things.
> > Let's have the code as explicit as possible.

Whatever that means. Pretty general/vague.

> I totally agree, but as Eli has pointed out, Elisp was designed the
> way it was designed a long while back. I guess prefix args have been
> around almost since the very beginnings. Changing something about very
> fundamental things like that would mean having to change A LOT OF very
> fundamental code, without breaking anything. The question then would
> simply be: Who is up for this job?

I don't think that was Eli's point. I think his point was (and
at least it is my point) that the design is a good one. It is
preferable to anything that's been suggested here and now.

> In other words, even though I like Emacs a lot, I think it is only
> fair to call Elisp idiosyncratic in some ways.

What do you mean by idiosyncratic, here? The fact that Elisp has
some features that didn't know about or might not have dreamed up
yourself?

Emacs is different from other editors and UIs in many ways. Does
that make it idiosyncratic? Sure. "Idiosyncratic" just means
individual, single, particular to the individual. Anything with
original features is individual, a "special snowflake". The same
is true of Elisp - or any Lisp: it is not what many people are
used to in a programming language.

If you think of "idiosyncratic" as "odd", then consider that
your (one's) notion of "odd" has a lot to do with what you are
used to. If you are not used to recursion, anonymous functions,
functional-style, structural macros, etc. then Lisp is a very
odd animal. If you are more used to a language like Lisp, SQL,
or Haskell then Fortran is a very odd animal.

> But if it is worth fixing these, I think, is simply what Eli
> might call a question for a rainy day.

I didn't see Eli suggesting that there was something here that
would benefit from "fixing" or "improving". But perhaps I just
missed that. In any case, I don't see such benefit.

There has been some hand-waving about "idiosyncrasy", but that
doesn't hold much water.

> I presume that the things that seem so idiosyncratic or somewhat
> obscure about Elisp (e.g. not only prefix args, but also the way lists
> are constructed, the reason why there are several kinds of sequences,
> obarrays) were not deliberately designed to be hard to understand (or
> to make Emacs privy to the initiated only), but that all had a lot to
> do with the technical limitations at the time.

No. But it's not clear just what you have in mind. Very few such
things are limited by the specific design/implementation of Elisp.
You will find them (but not prefix args, which have to do with
commands) in other Lisps as well.

> (Meaning there was perhaps not even a real alternative.)

Don't assume so. But again, it's not clear just what you're
referring to.

> So now they are there, and changing them now would have very
> different consequences than deciding on a feature when you
> design a language anew has.

Be specific about which features you are talking about, please.

Sure, Emacs and Emacs Lisp have a fair amount of baggage -
vestigial thingies - for hysterical raisins. But my impression
is that the things that you have mentioned so far, and find odd,
are not among them. They are _not_ just a bunch of vestiges that
users would love to get rid of but which would require a lot of
work to do.

There are such things in the Emacs implementation, no doubt.
But I don't see any such having been brought up in this thread.

Don't fall into the trap of assuming that just because either:

1) Something is new to you, or
2) Something has been around for a long time in Emacs, and is
different from what you see elsewhere,

that that something is just an unfortunate vestige that Emacs
users and developers would love to get rid of if it were easy
to do so.

More likely, it is a fine feature that you might do well to
learn more about. The Emacs prefix argument is a case in point.
Or it might just be a so-so choice that has little positive or
negative consequence - nothing special, nothing awful.

> (FWIW, I think this is precisely the reason why Larry Wall decided to
> break compatibility between Perl 5 and Perl 6, making Perl 6 simply a
> new language. Accidently, one of the design goals of Perl 6 was: being
> more intuitive than Perl 5.)

Getting too vague.

> On the other hand, when I read the node "Command Loop -> Prefix
> Command Arguments" in the Elisp Manual, I wonder how anyone CANNOT be
> confused about prefix args, because this node starts out with the
> unfortunate sentence:
>
> Most Emacs commands can use a "prefix argument", a number
> specified before the command itself.
>
> If I am not mistaken, this promotes precisely the misunderstanding
> that I had fallen prey to.

The presentation in the manual stresses the numeric prefix arg
a bit too much, for my taste. A first reading can give the
impression that that's all there is to it. The Elisp manual
does not have this problem (IMO).

But if you have concrete suggestions for the manuals, consider
offering them via `M-x report-emacs-bug'. Sometimes Emacs Dev
will agree with your suggested change. Sometimes you will learn
that the current text is in fact better than what you thought.
And sometimes you will agree to disagree. ("You win some; you
lose some; and some are rained out.")

> In contrast, other unintuitive features of Elisp

It's not about intuition (ever). It's about something new.
Or sometimes it's about something cumbersome or inconvenient.

> are quite well explained in the manual. (List construction --
> the cons cell stuff -- and sequences are two things I remember
> understanding quite readily from reading it, and in both cases
> it would never have occurred to me to intuitively assume they
> worked like that.)
>
> Maybe it would be a good idea if somebody simply rewrote some of the
> /documentation/ on prefix args, such that the innocent, naive user
> understands the point of the two representations? Because that is
> something that can be easily rewritten without breaking any code.
>
> I'll volunteer for the job if somebody checks!

Please do! `M-x report-emacs-bug'. You can suggest alternative
text to use or any other changes you see fit. You can even
provide doc patches. Suggestions are always welcome. A report
need not propose a solution (alternative text). Just letting
Emacs developers know that you found a particular passage unclear
can help. And if you can say why, so much the better.

[Andreas Röhler]

On 06.09.2016 16:20, Kaushal Modi wrote:
> On Tue, Sep 6, 2016, 7:22 AM Andreas Röhler
> <andreas...@easy-emacs.de <mailto:andreas...@easy-emacs.de>>

> wrote:
>
> But let's go back to the simplest case of lower p in interactive spec:
>
> What is easier to read/grasp
>
> (setq counter (or arg 1)
>

> or
>
> (setq counter (prefix-numeric-value arg))
>

> IOW: in favor of avoiding these complex, tricky things. Let's have the
> code as explicit as possible.
>
>

> Those 2 forms are not 100℅ equivalent. The equivalence goes only as
> far as setting the default value of counter.
>
> If the user used (interactive "p"), counter need to be set to 4
> regardless of whether the user used "C-4" as prefix or "C-u". In the
> former case, arg would be "4", but in the latter case, it would be
> "(4)", I.e. a list, not a number.

Not sure IIUC

(defun whatarg-p (arg)
(interactive "p")
(message "%s" arg))

Called with simply C-u without numeric argument gives me "4"

(4) would be the result with uppercase P

> Your simpler representation would not take care of the C-u case. If
> the counter variable is used where a numeric arg is strictly required,
> you will get an error. Here, prefix-numeric-value returns "4" when arg
> is "(4)".
>
> --
>
> Kaushal Modi
>

[Charles Millar]

On 09/06/2016 10:20 AM, Kaushal Modi wrote:
> On Tue, Sep 6, 2016, 7:22 AM Andreas Röhler <andreas...@easy-emacs.de>

> wrote:
>
>> But let's go back to the simplest case of lower p in interactive spec:
>>
>> What is easier to read/grasp
>>
>> (setq counter (or arg 1)
>>
>> or
>>
>> (setq counter (prefix-numeric-value arg))
>>
>> IOW: in favor of avoiding these complex, tricky things. Let's have the
>> code as explicit as possible.
>>
> Those 2 forms are not 100℅ equivalent. The equivalence goes only as far as
> setting the default value of counter.
>
> If the user used (interactive "p"), counter need to be set to 4 regardless
> of whether the user used "C-4" as prefix or "C-u". In the former case, arg
> would be "4", but in the latter case, it would be "(4)", I.e. a list, not a

> number. Your simpler representation would not take care of the C-u case. If

> the counter variable is used where a numeric arg is strictly required, you
> will get an error. Here, prefix-numeric-value returns "4" when arg is
> "(4)".
>
>> --
>

I have read this thread as well as the other suggested readings. If the
purpose of either p or P is to pass arguments, I do not understand the
rationale of allowing C-u when using the interactive upper case P. As
noted above, It returns an integer as the only element in a list, which
if evaluated returns an error. Is there a use for this? Such as you may
want an error?

Charlie Millar

[Kaushal Modi]

On Wed, Sep 7, 2016 at 10:41 PM Charles Millar <mil...@verizon.net> wrote:

> I have read this thread as well as the other suggested readings.



> If the
> purpose of either p or P is to pass arguments, I do not understand the
> rationale of allowing C-u when using the interactive upper case P.

That's useful if the user wants the function to behave different based on
if the arg is a list or not.

> As
> noted above, It returns an integer as the only element in a list, which
> if evaluated returns an error.

If the arg is a list (C-u), you have to treat it as a list.. e.g. use (car
arg).

> Is there a use for this?

It's up to the user on how they want to treat different arg values.

> Such as you may
> want an error?

Here's a dummy example:

(defun foo (arg)
(interactive "P")

(message (concat "Arg is "
(cond
((null arg)
"nil")
((listp arg)
(format "a list with element %d" (car arg)))
(t
(format "a number %d" arg))))))
(global-set-key (kbd "C-c '") #'foo)''''


After evaluating the above, do

- C-c '
- C-0 C-c ' or M-0 C-c '
- C-1 C-c ' or M-1 C-c '
- ..
- C-u C-c '
- C-4 C-c ' or M-4 C-c '
- C-u C-u C-c '
- C-1 C-6 C-c ' or M-1 M-6 C-c '

If the user wishes, they can make the foo function behave differently for
each of the above bullets.

So it eventually boils down to what the user wants.. do they want the
default arg to be nil or 1, do they want to support C-u and C-4 args in
different manner, etc. Based on that, they can choose to use the "p" or "P"
version of interactive.
--

Kaushal Modi

[Charles Millar]

Thank you, Kaushal!

I suspect that the following has been said many times on this and other
lists - "An example, as is a picture, is worth a 1000 words."

Charlie Millar

[Thien-Thi Nguyen]

() flo...@fsavigny.de (Florian v. Savigny)
() Sun, 04 Sep 2016 14:23:35 +0200

but I am still wondering about the

rationale of representing nil as the number one.

When there is no question, the question is nil.
Emacs gives you a (singular) hand, anyway -- what a pal! :-D

--
Thien-Thi Nguyen -----------------------------------------------
(defun responsep (type via)
(case type
(technical (eq 'mailing-list via))
...)) 748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502