unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: florian@fsavigny.de (Florian v. Savigny)
To: help-gnu-emacs@gnu.org
Subject: Re: Rationale behind conversion of a nil prefix arg to numeric 1
Date: Tue, 06 Sep 2016 15:27:22 +0200	[thread overview]
Message-ID: <87oa41yx8l.fsf@bertrandrussell.Speedport_W_723V_1_40_000> (raw)
In-Reply-To: <afaf96a1-9e5c-957d-1b47-8e5ce6248ac4@easy-emacs.de> (message from Andreas Röhler on Tue, 6 Sep 2016 13:27:39 +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

  (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!

-- 

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld



  reply	other threads:[~2016-09-06 13:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-04 12:23 Rationale behind conversion of a nil prefix arg to numeric 1 Florian v. Savigny
2016-09-04 14:23 ` Eli Zaretskii
2016-09-04 17:11   ` Andreas Röhler
2016-09-04 18:33     ` Eli Zaretskii
2016-09-05  7:16       ` Andreas Röhler
2016-09-05 14:56         ` Eli Zaretskii
2016-09-05 15:22           ` Kaushal Modi
2016-09-05 16:32             ` Drew Adams
2016-09-05 18:41             ` Andreas Röhler
2016-09-05 19:02               ` Eli Zaretskii
2016-09-06  7:10                 ` tomas
2016-09-06  9:45                   ` Florian v. Savigny
2016-09-06 10:27                     ` tomas
2016-09-06 11:27                     ` Andreas Röhler
2016-09-06 13:27                       ` Florian v. Savigny [this message]
2016-09-06 15:22                         ` Drew Adams
2016-09-06 14:20                       ` Kaushal Modi
2016-09-06 16:44                         ` Andreas Röhler
2016-09-06 16:41                           ` Kaushal Modi
2016-09-07 23:11                         ` Charles Millar
2016-09-08 13:10                           ` Kaushal Modi
2016-09-08 14:42                             ` Charles Millar
2016-09-08 15:40                           ` Drew Adams
2016-09-06  7:22                 ` Andreas Röhler
2016-09-05 17:04         ` Drew Adams
2016-09-05 21:39           ` Florian v. Savigny
     [not found]           ` <<877faqvxfp.fsf@bertrandrussell.Speedport_W_723V_1_40_000>
2016-09-05 23:32             ` Drew Adams
2016-09-06  3:45               ` B.V. Raghav
2016-09-04 22:53   ` Florian v. Savigny
     [not found]   ` <<87d1kjjmys.fsf@bertrandrussell.Speedport_W_723V_1_40_000>
2016-09-05  0:52     ` Drew Adams
2016-09-15 12:47 ` Thien-Thi Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87oa41yx8l.fsf@bertrandrussell.Speedport_W_723V_1_40_000 \
    --to=florian@fsavigny.de \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).