[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18545: 24.4.50: Bug - forward-line inside with-selected-window

From: Eli Zaretskii
Subject: bug#18545: 24.4.50: Bug - forward-line inside with-selected-window
Date: Sat, 27 Sep 2014 11:53:09 +0300

> Date: Sat, 27 Sep 2014 09:35:22 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
>  > Can you tell me how to reproduce this?  I don't see this in the recipe
>  > you described in your bug report.
> I can reproduce something similar here but it hardly makes sense to
> share my recipe.  The bug manifests itself such that after an implicit
> `forward-line' the cursor appears stuck in a partially visible line at
> the bottom of a window.  That window has a sibling on the right.  On
> Windows these siblings must be in the lower half of a split frame.  On
> Gtk no vertical splitting is needed.  The cursor continues to move by
> one line when keeping the down key (which implicitly runs `forward-line'
> here) pressed for some three seconds and gets stuck again immediately.

Do you see the line number in the mode line of that window increasing,
after the cursor gets stuck, each time forward-line is run in that

> Some additional particularities:
> (1) The bug is not reproducible with Emacs 24-4, only with current
>      trunk.

That's strange, since the code to which you pointed is present in both

I'd like to hear from the OP (address@hidden) whether the bug
observed with Helm is reproducible in the latest pretest 24.3.93 or in
the emacs-24 branch.

> The bug might be related to your changes from 2014-07-09.

I guess you meant 2014-07-04?  There are no changes in all of xdisp.c
from 2014-07-09 or from a day before or after that (to account for
possible local time differences).  A bzr revno would be useful.

> (gdb) p new_vpos
> $1 = 426
> (gdb) p w->cursor.y
> $2 = 432
> (gdb)
> In this particular case the display should be scrolled since otherwise
> point ends up on the partially visible line.  But the test
>         if (new_vpos >= w->cursor.y)
> fails to trigger that.

I cannot test a fix unless I have a way to reproduce the problem.
Since you can reproduce it, could you propose a solution?  One simple
solution would be to add this:

      if (!cursor_row_fully_visible_p (w, 0, 0))
           w->cursor.vpos = -1;
           clear_glyph_matrix (w->desired_matrix);
           goto try_to_scroll;

after the call to set_cursor_from_row on line 16322.

If this doesn't work, please see why.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]