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

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Mon, 22 Nov 2010 14:54:02 UTC

Severity: normal

Found in version 24.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

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: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 23:41:15 +0300
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Fri, 30 Mar 2012 21:35:27 +0200
> 
> Hm, I have failed to find where its value becomes 1; every time I typed
> `p mouse_face_overwritten_p' while stepping over the code, the value was
> 0.  I also tried `watch mouse_face_overwritten_p' at each update_window
> breakpoint: that found where the value was set to 0, but every other
> watchpoint was deleted unchanged after the program left the containing
> block.

This is consistent with the fact that the glyph matrices of the
original window were freed and reallocated.  They are cleared when
they are allocated.

> (gdb) 
> 385         XFlush (FRAME_X_DISPLAY (f));
> (gdb) 
> 386       UNBLOCK_INPUT;
> 
> When I hit RET at the gdb prompt before UNBLOCK_INPUT, the highlighting
> vanished.

So I think this means that the GTK build, like non-GTK builds, removes
the highlighting.  It's just that, due to peculiarities of how Emacs
works with X window system, the highlighting doesn't actually
disappear from display until some time later, when Emacs flushes
everything it has drawn to X.

Now, how does the mouse highlighting gets restored in the GTK build,
after it was cleared above?  I think the answer to that was pointed
out by Jan, earlier in this thread: the function
xg_update_scrollbar_pos in gtkutil.c.  It does this near its very end:

      x_sync (f);
      SET_FRAME_GARBAGED (f);
      cancel_mouse_face (f);

And if you look at cancel_mouse_face, you will see that it does
exactly what my proposed patch for delete-other-windows-internal would
do!

So could you please see if the above call to cancel_mouse_face is
indeed made, in the GTK build, after mouse highlighting disappears?

Actually, it would be good to put a breakpoint in cancel_mouse_face,
right after you hit the breakpoint in Fdelete_other_windows_internal,
type "continue", and see if that function ever gets called and by what
code.  When I try this on my system, I don't see the breakpoint inside
cancel_mouse_face break at all when I reproduce the recipe with "emacs -q".





This bug report was last modified 13 years and 54 days ago.

Previous Next


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