Subject: Re: bug#31243: 26.1; kmacro-insert-counter increments incorrectly
From: Eli Zaretskii <[email-masked]>
To: Allen Li <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 11 May 2018 12:16:14 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Allen Li <[email-masked]>
> Date: Mon, 23 Apr 2018 00:58:00 -0700
> Cc: [email-masked],
> 	bug-gnu-emacs <bug-gnu-emacs-bounces+psainty=[email-masked]>
> 
> On Sun, Apr 22, 2018 at 9:56 PM, Phil Sainty <[email-masked]> wrote:
> > Not a bug?  I believe your expectations are incorrect.
> >
> >> C-u <f3> ;; kmacro-start-macro-or-insert-counter
> >
> >
> > This insert the *previous* macro counter.  Which is sort of "undefined" for
> > the first iteration, but zero in practice.
> 
> Ah, I see.  I guess what I'm looking for is C-u 0 <f3> (or
> alternatively C-u <f3> the second time rather than the first time).
> 
> I don't think the documentaton is very clear, because the meaning of
> "previous" is ambiguous:
> 
> With C-u, inserts previous ‘kmacro-counter’ (but do not modify counter).

Indeed, the doc string could use an improvement, and in particular,
using "previous" was misleading.  I've now clarified the doc strings,
and made a point of using "current value" in all places, instead ofg
sometimes using "previous".

One comment about what's been said by Phil:

> >> C-u <f3> ;; kmacro-start-macro-or-insert-counter
> >
> >
> > This insert the *previous* macro counter.  Which is sort of "undefined" for
> > the first iteration, but zero in practice.

Actually, the value of the counter is documented to be initialized to
zero before defining the macro, so it's non "undefined" at this stage.

Thanks, I'm closing the bug report.