GNU bug report logs - #10461
emacs is not a macro-editor

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 10461 in the body.
You can then email your comments to 10461 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: andre.desnoyers <at> upmc.fr
To: bug-gnu-emacs <at> gnu.org
Subject: emacs is not a macro-editor
Date: Mon, 09 Jan 2012 07:25:15 +0100

Take un medium file : 4000 lines
Set a match for a search
build the macro
C-a			;; move-beginning-of-line
2*C-k			;; kill-line
C-x C-x			;; exchange-point-and-mark
C-y			;; yank
2*C-s			;; isearch-forward
C-a			;; move-beginning-of-line

this macro normally groups all lines who contain the match.

If two matches are more distant  than about 50 lines the second match  
is not found, but the macro can be repeated !

this bug exists in 22- versions and last 23-version on Mac.

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

From: Glenn Morris <rgm <at> gnu.org>
To: andre.desnoyers <at> upmc.fr
Cc: 10461 <at> debbugs.gnu.org
Subject: Re: bug#10461: emacs is not a macro-editor
Date: Tue, 10 Jan 2012 12:38:34 -0500

andre.desnoyers <at> upmc.fr wrote:

> If two matches are more distant  than about 50 lines the second match
> is not found, but the macro can be repeated !

It seems to work when I tried it.
Can you give a complete example? Attach a (perhaps compressed) example
file, and show exactly what you typed, starting from `emacs -Q', and
what happened.

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

From: andre.desnoyers <at> upmc.fr
To: Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#10461: emacs is not a macro-editor
Date: Thu, 12 Jan 2012 19:46:10 +0100

I think this effect exists on Mac OS with Intel proc. In the past  
version on Fedora Scientific Linux) my macro work on the very big  
files (> 40Mo). It is possible there are conflict with my sartup. I  
see the cursor points in bad line, then it will be a bad section àf  
file which show in window (why?).

So, i prepare a test with your guide line.
   Thank Andrew

> andre.desnoyers <at> upmc.fr wrote:
>
>> If two matches are more distant  than about 50 lines the second match
>> is not found, but the macro can be repeated !
>
> It seems to work when I tried it.
> Can you give a complete example? Attach a (perhaps compressed) example
> file, and show exactly what you typed, starting from `emacs -Q', and
> what happened.
>

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

From: andre.desnoyers <at> upmc.fr
To: Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#10461: emacs is not a macro-editor
Date: Fri, 03 Feb 2012 02:05:54 +0100

I have forgotten that :
in my problem, file is build with very long lines (frequently 500  
bytes) on Mac Intosh. There are very important difference between  
logical lines (in file) and physical lines (in window).
the X-windows has not good position after execution my macro when two  
consecutive matches are very distant and require a refresh of the  
screen.

Quoting Glenn Morris <rgm <at> gnu.org>:

> andre.desnoyers <at> upmc.fr wrote:
>
>> If two matches are more distant  than about 50 lines the second match
>> is not found, but the macro can be repeated !
>
> It seems to work when I tried it.
> Can you give a complete example? Attach a (perhaps compressed) example
> file, and show exactly what you typed, starting from `emacs -Q', and
> what happened.
>

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

From: Glenn Morris <rgm <at> gnu.org>
To: 10461 <at> debbugs.gnu.org
Cc: andre.desnoyers <at> upmc.fr
Subject: Re: bug#10461: emacs is not a macro-editor
Date: Fri, 03 Feb 2012 17:34:01 -0500

(Please keep 10461 <at> debbugs cc'd)

andre.desnoyers <at> upmc.fr wrote:

> I have forgotten that :
> in my problem, file is build with very long lines (frequently 500
> bytes) on Mac Intosh. There are very important difference between
> logical lines (in file) and physical lines (in window).
> the X-windows has not good position after execution my macro when two
> consecutive matches are very distant and require a refresh of the
> screen.

Then I imagine this is the same issue as
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7046

ie visual-line-mode can affect the way macros behave.

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

From: Alan Third <alan <at> idiocy.org>
To: Gord Wait <gordwait <at> lighthauslogic.com>
Cc: "'7046 <at> debbugs.gnu.org'" <7046 <at> debbugs.gnu.org>, 10461 <at> debbugs.gnu.org
Subject: Re: bug#7046: More info
Date: Mon, 30 Dec 2019 14:05:03 +0000

Johan Bockgård <bojohan <at> gnu.org> writes:

> Gord Wait <gordwait <at> lighthauslogic.com> writes:
>
>> It seems to be dependent on how many repeats I select. If I auto
>> repeat say 10 lines worth, It seems to be ok. If I auto repeat the
>> macro 1000 times, then it starts to skip every line at some point..
>
> next-line can move to the wrong column when point gets below the end of
> the window.
>
> The problem is in line-move-visual (i.e it only exists if the variable
> line-move-visual is non-nil),
>
>     ;; Otherwise, we should reset `temporary-goal-column'.
>     (let ((posn (posn-at-point)))
>       (cond
>        ;; Handle the `overflow-newline-into-fringe' case:
>        ((eq (nth 1 posn) 'right-fringe)
>         (setq temporary-goal-column (cons (- (window-width) 1) hscroll)))
>        ((car (posn-x-y posn))
>         (setq temporary-goal-column
>               (cons (/ (float (car (posn-x-y posn)))
>                        (frame-char-width)) hscroll)))))
>
> If the position is not visible in the window, posn-at-point returns nil
> and temporary-goal-column is not updated as it should.

I can't replicate this on Emacs 27 and it's been over 7 years since the
last bug report. Can anyone confirm whether it's still a problem?
-- 
Alan Third

Message #27 received at 10461-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: gordwait <at> lighthauslogic.com, 7046-done <at> debbugs.gnu.org,
 10461-done <at> debbugs.gnu.org
Subject: Re: bug#7046: More info
Date: Mon, 30 Dec 2019 17:36:34 +0200

> From: Alan Third <alan <at> idiocy.org>
> Date: Mon, 30 Dec 2019 14:05:03 +0000
> Cc: "'7046 <at> debbugs.gnu.org'" <7046 <at> debbugs.gnu.org>, 10461 <at> debbugs.gnu.org
> 
> > The problem is in line-move-visual (i.e it only exists if the variable
> > line-move-visual is non-nil),
> >
> >     ;; Otherwise, we should reset `temporary-goal-column'.
> >     (let ((posn (posn-at-point)))
> >       (cond
> >        ;; Handle the `overflow-newline-into-fringe' case:
> >        ((eq (nth 1 posn) 'right-fringe)
> >         (setq temporary-goal-column (cons (- (window-width) 1) hscroll)))
> >        ((car (posn-x-y posn))
> >         (setq temporary-goal-column
> >               (cons (/ (float (car (posn-x-y posn)))
> >                        (frame-char-width)) hscroll)))))
> >
> > If the position is not visible in the window, posn-at-point returns nil
> > and temporary-goal-column is not updated as it should.
> 
> I can't replicate this on Emacs 27 and it's been over 7 years since the
> last bug report. Can anyone confirm whether it's still a problem?

This has been fixed several releases back, so I'm closing it.

Previous Next

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