GNU bug report logs - #17777
24.3.91; Word motion commands are broken

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 17777 in the body.
You can then email your comments to 17777 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: Juri Linkov <juri <at> jurta.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.91; Word motion commands are broken
Date: Sat, 14 Jun 2014 13:03:10 +0300

For testing I tried to set `visual-order-cursor-movement' to t
and noticed that it breaks the word motion commands in keyboard macros.
Steps to reproduce:

0. emacs -Q
1. (setq visual-order-cursor-movement t)
2. (insert "word word word")
3. C-a C-x ( C-right right C-x ) C-x e e e ...

doesn't move point by words, only by characters.

This affects only arrow keys like `C-right' bound to `right-word'
in bindings.el.  I tested non-arrow keys like `M-f', and they work fine.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 17777-done <at> debbugs.gnu.org
Subject: Re: bug#17777: 24.3.91; Word motion commands are broken
Date: Sat, 14 Jun 2014 14:11:45 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Date: Sat, 14 Jun 2014 13:03:10 +0300
> 
> For testing I tried to set `visual-order-cursor-movement' to t
> and noticed that it breaks the word motion commands in keyboard macros.
> Steps to reproduce:
> 
> 0. emacs -Q
> 1. (setq visual-order-cursor-movement t)
> 2. (insert "word word word")
> 3. C-a C-x ( C-right right C-x ) C-x e e e ...
> 
> doesn't move point by words, only by characters.

Thanks, fixed in emacs-24 revision 117241.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard
 macros and visual-order cursor movement.
Date: Sat, 14 Jun 2014 17:06:28 -0400

>    if (w->window_end_valid
> +      && NILP (Vexecuting_kbd_macro)
>        && !windows_or_buffers_changed
>        && b
>        && !b->clip_changed

NILP (Vexecuting_kbd_macro) seems like a workaround.  Why can't the
glyph matrix be used in this case?  I means which part of the glyph
matrix is wrong in the OP's recipe (since this makes no change to the
buffer)?


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard
 macros and visual-order cursor movement.
Date: Sun, 15 Jun 2014 05:47:00 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 17777 <at> debbugs.gnu.org
> Date: Sat, 14 Jun 2014 17:06:28 -0400
> 
> >    if (w->window_end_valid
> > +      && NILP (Vexecuting_kbd_macro)
> >        && !windows_or_buffers_changed
> >        && b
> >        && !b->clip_changed
> 
> NILP (Vexecuting_kbd_macro) seems like a workaround.

It isn't.

> Why can't the glyph matrix be used in this case?

Because cursor position is not up-to-date in that case.

> I means which part of the glyph matrix is wrong in the OP's recipe
> (since this makes no change to the buffer)?

The cursor position.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard
 macros and visual-order cursor movement.
Date: Sun, 15 Jun 2014 00:14:06 -0400

>> >    if (w->window_end_valid
>> > +      && NILP (Vexecuting_kbd_macro)
>> >        && !windows_or_buffers_changed
>> >        && b
>> >        && !b->clip_changed
>> NILP (Vexecuting_kbd_macro) seems like a workaround.
> It isn't.
>> Why can't the glyph matrix be used in this case?
> Because cursor position is not up-to-date in that case.
>> I means which part of the glyph matrix is wrong in the OP's recipe
>> (since this makes no change to the buffer)?
> The cursor position.

But that can occur even without executing kbd macros, no?
Wouldn't it be better to ignore the cursor position given in the glyph
matrix and use (point) instead?


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard
 macros and visual-order cursor movement.
Date: Sun, 15 Jun 2014 19:12:29 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 17777 <at> debbugs.gnu.org
> Date: Sun, 15 Jun 2014 00:14:06 -0400
> 
> >> >    if (w->window_end_valid
> >> > +      && NILP (Vexecuting_kbd_macro)
> >> >        && !windows_or_buffers_changed
> >> >        && b
> >> >        && !b->clip_changed
> >> NILP (Vexecuting_kbd_macro) seems like a workaround.
> > It isn't.
> >> Why can't the glyph matrix be used in this case?
> > Because cursor position is not up-to-date in that case.
> >> I means which part of the glyph matrix is wrong in the OP's recipe
> >> (since this makes no change to the buffer)?
> > The cursor position.
> 
> But that can occur even without executing kbd macros, no?

Not sure what you mean by that.

> Wouldn't it be better to ignore the cursor position given in the glyph
> matrix and use (point) instead?

For the method that is based on up-to-date glyph matrices, I need to
know the glyph where the cursor is displayed.  The glyph coordinates
of that glyph are stored in the w->cursor structure, and updated by
redisplay.  The problem in the case in point was that redisplay is not
called as long as a macro is running.  So the coordinates from which
move-point-visually starts are incorrect.

I see no easy way of finding the cursor glyph coordinates by starting
from point; a (not so easy) way is the second method used by that
function.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: monnier <at> iro.umontreal.ca
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777
 with	keyboard macros and visual-order cursor movement.
Date: Mon, 16 Jun 2014 22:40:35 +0300

> Date: Sun, 15 Jun 2014 19:12:29 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 17777 <at> debbugs.gnu.org
> 
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: 17777 <at> debbugs.gnu.org
> > Date: Sun, 15 Jun 2014 00:14:06 -0400
> > 
> > >> >    if (w->window_end_valid
> > >> > +      && NILP (Vexecuting_kbd_macro)
> > >> >        && !windows_or_buffers_changed
> > >> >        && b
> > >> >        && !b->clip_changed
> > >> NILP (Vexecuting_kbd_macro) seems like a workaround.
> > > It isn't.
> > >> Why can't the glyph matrix be used in this case?
> > > Because cursor position is not up-to-date in that case.
> > >> I means which part of the glyph matrix is wrong in the OP's recipe
> > >> (since this makes no change to the buffer)?
> > > The cursor position.
> > 
> > But that can occur even without executing kbd macros, no?
> 
> Not sure what you mean by that.

I think I know now what you meant, and I found a better solution for
the problem (r117250 on the emacs-24 branch).  I hope you will like
it.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard
 macros and visual-order cursor movement.
Date: Mon, 16 Jun 2014 17:28:05 -0400

>> But that can occur even without executing kbd macros, no?
> Not sure what you mean by that.

E.g. don't we have the same kind of problem if we use a command like:

   (defun my-wacky-movement ()
     (interactive)
     (dotimes (_ 5)
       (move-point-visually 1)))
or
   (defun my-wacky-movement ()
     (interactive)
     (and (re-search-forward " " nil t)
          (move-point-visually 1)))

If not, why not?

> I see no easy way of finding the cursor glyph coordinates by starting
> from point; a (not so easy) way is the second method used by that
> function.

Then is there a way to check whether point is consistent with the cursor
glyph position (and use this check instead of the
NILP(Vexecuting_kbd_macro) check)?


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777
 with	keyboard macros and visual-order cursor movement.
Date: Mon, 16 Jun 2014 17:50:50 -0400

> I think I know now what you meant, and I found a better solution for
> the problem (r117250 on the emacs-24 branch).  I hope you will like
> it.

Looks good, thanks,


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard
 macros and visual-order cursor movement.
Date: Tue, 17 Jun 2014 05:46:40 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 17777 <at> debbugs.gnu.org
> Date: Mon, 16 Jun 2014 17:28:05 -0400
> 
> >> But that can occur even without executing kbd macros, no?
> > Not sure what you mean by that.
> 
> E.g. don't we have the same kind of problem if we use a command like:
> 
>    (defun my-wacky-movement ()
>      (interactive)
>      (dotimes (_ 5)
>        (move-point-visually 1)))
> or
>    (defun my-wacky-movement ()
>      (interactive)
>      (and (re-search-forward " " nil t)
>           (move-point-visually 1)))

We did, before r117250.

> > I see no easy way of finding the cursor glyph coordinates by starting
> > from point; a (not so easy) way is the second method used by that
> > function.
> 
> Then is there a way to check whether point is consistent with the cursor
> glyph position (and use this check instead of the
> NILP(Vexecuting_kbd_macro) check)?

Indeed, there is.  That's what I did in r117250.

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

From: Juri Linkov <juri <at> jurta.org>
To: 17777 <at> debbugs.gnu.org
Subject: bug#17777: 24.3.91; Word motion commands are broken
Date: Fri, 17 Jul 2015 02:04:00 +0300

[Message part 1 (text/plain, inline)]

reopen 17777
thanks

>> For testing I tried to set `visual-order-cursor-movement' to t
>> and noticed that it breaks the word motion commands in keyboard macros.
>> Steps to reproduce:
>>
>> 0. emacs -Q
>> 1. (setq visual-order-cursor-movement t)
>> 2. (insert "word word word")
>> 3. C-a C-x ( C-right right C-x ) C-x e e e ...
>>
>> doesn't move point by words, only by characters.
>
> Thanks, fixed in emacs-24 revision 117241.

I kept this setting in ~/.emacs, and now noticed it not working
in another specific case:

0. emacs -Q
1. (progn
     (setq visual-order-cursor-movement t)
     (toggle-truncate-lines))
2. Insert a long line of e.g. (foobar) (foobar) (foobar) ...
3. Then try to adjust the window size to put the right window edge
   on the closing paren of one of these repeated strings (you may need
   to try different window widths before you could reproduce the bug)
4. Then put the cursor on the beginning of the test line
5. Now define and repeat the macro consisting of two keys:
   <C-M-right> (forward-sexp) and <right> (right-char)
6. When after repeating the macro with <C-x e> the cursor reaches
   the right window edge, then the cursor jumps to the second next line
   instead of doing the horizontal scrolling.

If it's difficult to reproduce this problem, this screenshot
might help you to see the window configuration where starting
to repeat the macro 9 times from the beginning of the foobars line
jumps to the line with the text “Macro:”

[bug_17777.png (image/png, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 17777 <at> debbugs.gnu.org
Subject: Re: bug#17777: 24.3.91; Word motion commands are broken
Date: Sat, 18 Jul 2015 15:22:49 +0300

> From: Juri Linkov <juri <at> jurta.org>
> Date: Fri, 17 Jul 2015 02:04:00 +0300
> 
> 0. emacs -Q
> 1. (progn
>      (setq visual-order-cursor-movement t)
>      (toggle-truncate-lines))
> 2. Insert a long line of e.g. (foobar) (foobar) (foobar) ...
> 3. Then try to adjust the window size to put the right window edge
>    on the closing paren of one of these repeated strings (you may need
>    to try different window widths before you could reproduce the bug)
> 4. Then put the cursor on the beginning of the test line
> 5. Now define and repeat the macro consisting of two keys:
>    <C-M-right> (forward-sexp) and <right> (right-char)
> 6. When after repeating the macro with <C-x e> the cursor reaches
>    the right window edge, then the cursor jumps to the second next line
>    instead of doing the horizontal scrolling.

I couldn't reproduce this using the recipe you provided.  But here's a
much simpler recipe that is 100% reproducible: In step 2, insert a
single sexp that is longer than the window width, followed by some
text, for example:

  (foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar) foo

Now step 3 is unnecessary, and the problem is clearly visible.

Btw, if your recipe is modified to insert an empty line after the
above sexp, then running the macro goes down by 2 lines, not by one.

I think I fixed this in commit a65e00b, please try.

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

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17777-done <at> debbugs.gnu.org
Subject: Re: bug#17777: 24.3.91; Word motion commands are broken
Date: Sat, 18 Jul 2015 23:30:51 +0300

> Btw, if your recipe is modified to insert an empty line after the
> above sexp, then running the macro goes down by 2 lines, not by one.

Sorry, I meant just 2 lines, not one.

> I think I fixed this in commit a65e00b, please try.

Thank you, I tested and see no more problems, so closing this.

Previous Next

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