GNU bug report logs - #23555
24.5; Keyboard macros unexpectedly depend on frame size

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23555 in the body.
You can then email your comments to 23555 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; Keyboard macros unexpectedly depend on frame size
Date: Sun, 15 May 2016 14:10:59 +0200

To reproduce this issue, please first fetch rep.txt from:

    https://www.metalevel.at/ei/rep.txt

and then invoke Emacs as follows:

    $ emacs -Q -g 80x30 rep.txt

The issue depends critically on the frame size. I can reproduce the
issue if the last line that I still see in the buffer (when point is at
the beginning of the buffer) is the line containing "false." in the
definition of declarative_false/0, i.e., line 28 in the file.

We now define a keyboard macro that is supposed to remove the 8 spaces
that indent all code snippets that appear within the 4 <pre> blocks.

With point at the beginning of the buffer, please press C-x ( to start
recording, and then press the following keys:

     C-s <pre RET C-n C-a C-s </pre RET C-p C-b C-x r k C-n

Then finish recording with C-x ).

If the macro is defined as intended, the following commands are
recorded, which you can verify with M-x edit-kbd-macro RET:

        Macro:

        C-s                     ;; isearch-forward
        <pre                    ;; self-insert-command * 4
        RET                     ;; newline
        C-n                     ;; next-line
        C-a                     ;; move-beginning-of-line
        C-s                     ;; isearch-forward
        </pre                   ;; self-insert-command * 5
        RET                     ;; newline
        C-p                     ;; previous-line
        C-b                     ;; backward-char
        C-x r k                 ;; kill-rectangle
        C-n                     ;; next-line

Press C-_ or revert the buffer to undo everything that was done while
recording macro, so that we now start again with the initial content and
point at the beginning of the buffer.

Next, simply execute the macro, repeatedly, with:

    C-x e e e e

After this, you will see that the fourth <pre> block is unexpectedly
changed to:

    <pre>





                ).
    </pre>

whereas the expected result it:

    <pre>
mi2_safe(g(G)) :-
        (   safe_goal(G) ->
            mi_clause(G, Body),
            mi2_safe(Body)
        ;   throw(cannot_execute(G))
        ).
    </pre>


However, if I revert all changes and simply enlarge the frame, or try
the exact same sequence after removing the filler text between lines 33
and 52, or try the macro on the fourth snippet while the <pre> block is
completely in view, everything works exactly as expected.

Thus, implicit scrolling and the frame size may unexpectedly interact
with this keyboard macro.


In GNU Emacs 24.5.1 (x86_64-apple-darwin14.0.0, GTK+ Version 2.24.28)
 of 2015-09-20 on mt-mbpro
Windowing system distributor `The X.Org Foundation', version 11.0.11502000
Configured using:
 `configure --prefix=/opt/local --without-dbus --without-libotf
 --without-m17n-flt --without-gpm --without-gnutls --with-xml2 --infodir
 /opt/local/share/info/emacs --without-xaw3d --without-imagemagick
 --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-xft
 --with-x-toolkit=gtk2 --with-gconf --with-rsvg 'CFLAGS=-pipe -Os -arch
 x86_64' CPPFLAGS=-I/opt/local/include 'LDFLAGS=-L/opt/local/lib
 -Wl,-headerpad_max_install_names -lfreetype -lfontconfig -Wl,-no_pie
 -arch x86_64''

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

Message #8 received at 23555 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 23555 <at> debbugs.gnu.org
Subject: Re: bug#23555: 24.5; Keyboard macros unexpectedly depend on frame size
Date: Mon, 16 May 2016 21:53:53 +0300

> From: Markus Triska <triska <at> metalevel.at>
> Date: Sun, 15 May 2016 14:10:59 +0200
> 
> Next, simply execute the macro, repeatedly, with:
> 
>     C-x e e e e
> 
> After this, you will see that the fourth <pre> block is unexpectedly
> changed to:
> 
>     <pre>
> 
> 
> 
> 
> 
>                 ).
>     </pre>
> 
> whereas the expected result it:
> 
>     <pre>
> mi2_safe(g(G)) :-
>         (   safe_goal(G) ->
>             mi_clause(G, Body),
>             mi2_safe(Body)
>         ;   throw(cannot_execute(G))
>         ).
>     </pre>
> 
> 
> However, if I revert all changes and simply enlarge the frame, or try
> the exact same sequence after removing the filler text between lines 33
> and 52, or try the macro on the fourth snippet while the <pre> block is
> completely in view, everything works exactly as expected.
> 
> Thus, implicit scrolling and the frame size may unexpectedly interact
> with this keyboard macro.

This is related to the C-n behavior when executing macros, the same
problem which causes bug#23551 and #13452.  If you set
line-move-visual to nil in the buffer where you run the macro, the
problem disappears.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.