bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Stefan Monnier]

>    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

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 17777@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.

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Stefan Monnier]

>> >    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

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 17777@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.

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Eli Zaretskii]

> Date: Sun, 15 Jun 2014 19:12:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 17777@debbugs.gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: 17777@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.

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Stefan Monnier]

> 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

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Stefan Monnier]

>> 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

bug#17777: [Emacs-diffs] emacs-24 r117241: Fix bug #17777 with keyboard macros and visual-order cursor movement.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 17777@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.