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

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

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


From: Stephen Berman
Subject: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window
Date: 30 Mar 2012 00:56:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

On Thu, 29 Mar 2012 20:47:09 +0200 Eli Zaretskii <address@hidden> wrote:

>> From: Stephen Berman <address@hidden>
>> Cc: address@hidden,  address@hidden
>> 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





reply via email to

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