bug#31243: 26.1; kmacro-insert-counter increments incorrectly

bug#31243: 26.1; kmacro-insert-counter increments incorrectly

[Allen Li]

1. emacs -Q
2. Record a macro like so (starting with <f3> and ending with <f4>):

C-u <f3> ;; kmacro-start-macro-or-insert-counter
SPC ;; self-insert-command
<f3> ;; kmacro-start-macro-or-insert-counter
RET ;; newline

3. Press <f4> multiple times.

Expected:

0 0
1 1
2 2
3 3
4 4
5 5
6 6

Got:

0 0
0 1
1 2
2 3
3 4
4 5
5 6
6 7


In GNU Emacs 26.1 (build 3, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2018-04-20 built on cielnosurge
Repository revision: 5de608f3edb54b4f8d9774e159d0fa99484d3ac8
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Defining kbd macro...
New macro counter value: 1 (1)
Keyboard macro defined

Configured using:
 'configure --with-x-toolkit=lucid --with-xft --with-modules
 PKG_CONFIG_PATH=/usr/lib/imagemagick6/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
LUCID X11 MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils kmacro elec-pair
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 95511 7642)
 (symbols 48 20449 1)
 (miscs 40 47 143)
 (strings 32 29187 1472)
 (string-bytes 1 757235)
 (vectors 16 14106)
 (vector-slots 8 493018 7522)
 (floats 8 52 158)
 (intervals 56 248 0)
 (buffers 992 11))

bug#31243: [PATCH] Fix kmacro-insert-counter inserting the wrong counter

[Allen Li]

[-- Attachment #1: Type: text/plain, Size: 34 bytes --]

The fix is trivial so I fixed it.

[-- Attachment #2: 0001-Fix-kmacro-insert-counter-inserting-the-wrong-counte.patch --]
[-- Type: text/x-patch, Size: 908 bytes --]

From 1259f8b32562e36d264ca530f97ac63d8d41409f Mon Sep 17 00:00:00 2001
From: Allen Li <darkfeline@felesatra.moe>
Date: Sun, 22 Apr 2018 19:36:55 -0700
Subject: [PATCH] Fix kmacro-insert-counter inserting the wrong counter

* lisp/kmacro.el (kmacro-insert-counter): Fix counter used.
---
 lisp/kmacro.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/kmacro.el b/lisp/kmacro.el
index 8855fa5c31..375a5e7f7d 100644
--- a/lisp/kmacro.el
+++ b/lisp/kmacro.el
@@ -262,7 +262,7 @@ kmacro-insert-counter
       (setq kmacro-counter kmacro-initial-counter-value
 	    kmacro-initial-counter-value nil))
   (if (and arg (listp arg))
-      (insert (format kmacro-counter-format kmacro-last-counter))
+      (insert (format kmacro-counter-format kmacro-counter))
     (insert (format kmacro-counter-format kmacro-counter))
     (kmacro-add-counter (prefix-numeric-value arg))))
 
-- 
2.17.0

bug#31243: 26.1; kmacro-insert-counter increments incorrectly

[Phil Sainty]

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.

=> 0

> <f3> ;; kmacro-start-macro-or-insert-counter

Insert the current macro counter (which is also zero, because inserting 
the previous counter does not touch the current counter).

=> 0

Then the counter is incremented -- so the current counter is set to 1, 
and the previous counter is set to 0.

Hence when you trigger the next iteration, you insert 0 and 1; etc...

bug#31243: 26.1; kmacro-insert-counter increments incorrectly

[Allen Li]

On Sun, Apr 22, 2018 at 9:56 PM, Phil Sainty <psainty@orcon.net.nz> 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).

I interpreted this to mean "Insert the counter that was
used last time" (which is redundant since there's only one counter),
rather than "Insert the value of the counter before the last time the
counter was changed".  The fact that the previous value of the counter
is saved is mentioned nowhere except implicitly implied by this single
word in the documentation.

I think the The Keyboard Macro Counter page should have a standalone
paragraph explaining this, such as:

Whenever the value of `kmacro-counter' is modified (by
`kmacro-insert-counter', `kmacro-set-counter' or
`kmacro-add-counter'), the previous value of the counter is saved in
`kmacro-last-counter'.  This value can be inserted by C-u <f3> or C-u
C-x C-k C-i.

And a similar addendum in the docstrings.

>
> => 0
>
>> <f3> ;; kmacro-start-macro-or-insert-counter
>
>
> Insert the current macro counter (which is also zero, because inserting the
> previous counter does not touch the current counter).
>
> => 0
>
> Then the counter is incremented -- so the current counter is set to 1, and
> the previous counter is set to 0.
>
> Hence when you trigger the next iteration, you insert 0 and 1; etc...
>
>

bug#31243: 26.1; kmacro-insert-counter increments incorrectly

[Eli Zaretskii]

> From: Allen Li <darkfeline@felesatra.moe>
> Date: Mon, 23 Apr 2018 00:58:00 -0700
> Cc: 31243@debbugs.gnu.org,
> 	bug-gnu-emacs <bug-gnu-emacs-bounces+psainty=orcon.net.nz@gnu.org>
> 
> On Sun, Apr 22, 2018 at 9:56 PM, Phil Sainty <psainty@orcon.net.nz> 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.