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

[Drew Adams <drew.adams@oracle.com>]

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