bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window

[Stephen Berman]

On Thu, 29 Mar 2012 20:47:09 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: cyd@gnu.org,  7464@debbugs.gnu.org
>> Date: Thu, 29 Mar 2012 09:57:53 +0200
>> 
>> openSUSE's 23.3 has GTK scroll bars, while I built 23.4 like I build 24,
>> i.e., without toolkit scroll bars.  So I rebuilt 23.4 with GTK scroll
>> bars, did the bug recipe and sure enough, now the mouse highlighting
>> remained, i.e., no bug.  Then I disabled the scroll bars in that build,
>> tested again, and got the bug again.  Then I rebuilt Emacs 24 with GTK
>> scroll bars, and now did not see the bug with them enabled but did see
>> it with them disabled.  So the answers to my questions above appear to
>> involve the presence vs. absence of GTK scroll bars.  (I guess Chong
>> Yidong also builds Emacs 24 with GTK scroll bars and tested the recipe
>> with them enabled, so that's why he did not observe the bug.)
>
> Unfortunately, I know almost nothing about how GTK in general and GTK
> scroll bars in particular are integrated into Emacs, and what, if
> anything, they change in how the Emacs display engine works.
>
>> After these tests, I ran both Emacs 24 builds (i.e., with and without
>> GTK scroll bars) under gdb, and in both cases, the value of
>> (w->current_matrix->rows+1)->mouse_face_p is 0 both at the breakpoint
>> and after the call to free_window_matrices (and of course after
>> adjust_glyphs).  I also ran 23.4 under gdb, with the same result:
>> (w->current_matrix->rows+1)->mouse_face_p is already 0 before
>> adjust_glyphs.  Do you have any idea why, or any further debugging
>> suggestions?

In the meantime I also built Emacs 24 --with-x-toolkit=athena, and this
shows the bug just like the non-toolkit-scrollbar and scrollbarless GTK
builds.  I ran the Athena build under gdb and carried out the
instructions from your previous post, and here too,
(w->current_matrix->rows+1)->mouse_face_p is 0 at the breakpoint.

[...]
> Perhaps you could step through these functions and see what happens
> there with and without GTK scroll bars.  To do so, put a breakpoint
> inside Fdelete_other_windows_internal, do the recipe, and when the
> breakpoint breaks, put a breakpoint in redisplay_internal and
> continue.  When the breakpoint in redisplay_internal breaks, put a
> breakpoint in update_window, and step through the loop which updates
> the screen lines:
>
>       /* Update the rest of the lines.  */
>       for (; row < end && (force_p || !input_pending); ++row)
>
> This loop calls update_window_line:
>
>           changed_p |= update_window_line (w, vpos,
>                                            &mouse_face_overwritten_p);

I got this far, but...

> Does the mouse_face_overwritten_p flag return being set when the line
> with highlight is updated?

...I don't understand what I should do to answer this question.  Here's
what I tried (the Emacs window was still displaying mouse highlighting):

(gdb) 
3655                changed_p |= update_window_line (w, vpos,
(gdb) s
update_window_line (w=0x88a9290, vpos=2, mouse_face_overwritten_p=0xbfffd17c)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:4009
4009      struct glyph_row *current_row = MATRIX_ROW (w->current_matrix, vpos);
(gdb) n
4010      struct glyph_row *desired_row = MATRIX_ROW (w->desired_matrix, vpos);
(gdb) p w->current_matrix
$8 = (struct glyph_matrix *) 0x89f2e58
(gdb) p w->current_matrix->rows
$9 = (struct glyph_row *) 0x8aa18a0
(gdb) p (w->current_matrix->rows+1)->mouse_face_p
$10 = 0
(gdb) p mouse_face_overwritten_p
$11 = (int *) 0xbfffd17c

I guess this isn't the answer you're looking for.  If you can continue
to indulge me with precise gdb instructions, I'll be happy to try again.

Steve Berman