bug-gnu-emacs
[Top][All Lists]
Advanced

[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: martin rudalics
Subject: bug#18545: 24.4.50: Bug - forward-line inside with-selected-window
Date: Sat, 27 Sep 2014 12:01:47 +0200

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

It gets updated normally until and including when the cursor is at the
partially visible line.  After that it gets updated with every
stuttering step, that is, when after three seconds the display actually
scrolls.  So FWIW the line number is congruent wrt to what I see on the
screen.

>> (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
> branches.

The remaining aspects like the need for a maximized frame and the fact
that the changes must be in my .emacs are much more strange.

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

I took the dates from trunk's ChangeLog.  On the release they appear as
of 2014-07-04.  More precisely I meant this change:

        * xdisp.c (redisplay_window): If redisplay of a window ends up
        with point in a partially visible line at end of the window, make
        sure the amended position of point actually has smaller Y
        coordinate; if not, give up and scroll the display.  (Bug#17905)

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

I can trigger the problem instantaneously here, so I can do anything you
propose.  OTOH sharing my recipe could be a very tedious endeavour.

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

It fails to do anything because running cursor_row_fully_visible_p
returns at

  if (!MATRIX_ROW_PARTIALLY_VISIBLE_P (w, row))
    return 1;

and this one apparently fails to detect that the row is partially visible
because of

(gdb) p row->height
$5 = 16
(gdb) p row->visible_height
$6 = 16

Any ideas?  BTW is there a way to print the value returned by a macro in
gdb?

martin





reply via email to

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