[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: Florian v. Savigny
Subject: Re: Rationale behind conversion of a nil prefix arg to numeric 1
Date: Tue, 06 Sep 2016 15:27:22 +0200

  > 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

      (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

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!


Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld

reply via email to

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