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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lompik <at> voila.fr, 18545 <at> debbugs.gnu.org
Subject: Re: bug#18545: 24.4.50: Bug - forward-line inside with-selected-window
Date: Sat, 27 Sep 2014 14:22:08 +0300

> Date: Sat, 27 Sep 2014 12:01:47 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lompik <at> voila.fr, 18545 <at> debbugs.gnu.org
> 
>  > 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.

AFAIU, this means the window is not being redrawn on each
forward-line; not even its mode line is updated.  You should be able
to confirm this if you turn on trace-redisplay (assuming you've built
with GLYPH_DEBUG, a.k.a. "--enable-checking=glyphs") -- you will not
see the window announced in the trace.  (Btw, turning off
blink-cursor-mode removes a lot of clutter from the redisplay trace,
so I suggest to do that in these experiments.)

If you add to the function that calls forward-line a message showing
point, do you see the value of point move on each forward-line even
though the window is not redrawn?

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

Actually, I'm not so sure those are strange: rare situations with
pixel dimensions might be only exposed by such techniques.

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

What is last_visible_y in that window?  To see that, step into
try_window called on line 16235, wait until it calls start_display,
and look at it.last_visible_y.

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

Yes, just print it:

 (gdb) p MATRIX_ROW_PARTIALLY_VISIBLE_P (w, row)

If this doesn't work, perhaps you didn't build with -g3, or your
compiler is buggy.

Thanks.

Previous Next

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