GNU bug report logs - #7464
24.0.50; mouse highlighting vanishes upon unsplitting window

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window
Date: Sat, 31 Mar 2012 08:56:00 +0300

> Date: 31 Mar 2012 01:09:26 +0200
> From: "Stephen Berman" <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
> 
> But when I set the breakpoint with GTK scrollbars enabled, execution
> stops many times:
> 
> Breakpoint 19, cancel_mouse_face (f=0x87349c8)
>     at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:27545
> 27545     Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
> (gdb) c
> Continuing.
> 
> At each break, a portion of the scroll bar is redisplayed.  For example,
> after typing C-x 2, execution stops and the scroll bar vanishes.  When I
> type c, the upper portion is redisplayed, then execution stops.  Next c,
> the upper scroll bar vanishes but the lower one is redisplayed, then
> execution stops.  Then the upper scroll bar is redisplayed again,
> completing the window splitting, and the execution returns to the
> command loop.  However, throughout this process, as long as the mouse
> pointer remains over the mouse-face propertized text, it remains
> highlighted.  Likewise after Fdelete_other_windows_internal.

Can you show a backtrace in a few instances when the breakpoint inside
cancel_mouse_face breaks?  I think these calls are those that keep the
highlighting from being wiped out in the GTK build.

Previous Next

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