GNU bug report logs -
#13452
24.1; Macro Playback Fails When Buffer Scrolls
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#13452: 24.5; Keyboard macros unexpectedly depend on frame size
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 23555 <at> debbugs.gnu.org.
--
13452: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13452
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> Date: Mon, 16 May 2016 20:30:29 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 23551 <at> debbugs.gnu.org
>
> > Date: Mon, 16 May 2016 16:30:32 +0000
> > From: abbott <at> dima.unige.it
> > Cc: Abbott John <abbott <at> dima.unige.it>
> >
> > Open the attached file in Emacs, and move point to the first position.
> > Define a keyboard macro: (I want to put each line inside double-quotes)
> > " ;; self-insert-command
> > C-e ;; move-end-of-line
> > " ;; self-insert-command
> > C-a ;; message-beginning-of-line
> > <down> ;; next-line
> >
> > Now ask Emacs to repeat this macro 49 times.
> > The result is wrong: at around line 35, the first double-quote
> > is no longer at the start of the line; then on successive lines
> > the position of the first inserted double-quote walks to the right.
>
> Thanks.
>
> This is a duplicate of the (old, but unsolved) bug #13452. The
> problem is not in beginning-of-line, it's in next-line: when the
> window needs to scroll as result of next-line, point ends up in
> columns 1, 2, 3, ... (i.e. gains one column per line moved down),
> instead of sticking to column zero.
>
> To work around, set line-move-visual to nil before running the macro
> (or as part of the macro), then the problem goes away.
>
> I'll try to debug this one of these days.
Should be fixed now, please test the latest Emacs master branch.
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 8 years and 321 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.