GNU bug report logs - #17588
24.3.91; mouse-face glitchy

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Thu, 29 May 2014 18:56:49 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Wed, 28 May 2014 16:15:25 -0400 (EDT)
> 
> > So are you saying that clear_mouse_face is never called with non-nil
> > hlinfo->mouse_face_window?  IOW, if you put a conditional breakpoint
> > in clear_mouse_face, like this:
> >
> >   (gdb) break clear_mouse_face if hlinfo->mouse_face_window != Qnil
> >
> > then this breakpoint never breaks, is that right?
> 
> Yes, it never breaks.
> 
> > If so, I'd like to see which code resets mouse_face_window to nil,
> > after it is set by show_mouse_face.  (We know that it must be set by
> > show_mouse_face because you do see the highlighting when the mouse is
> > above text with mouse-face.)  To this end, set a breakpoint in
> > show_mouse_face, like this:
> >
> >   (gdb) break show_mouse_face if draw == DRAW_MOUSE_FACE
> 
> The watchpoint is triggered in turns as part of the following two
> contexts.  Qnil is 12026738.
> 
>     Hardware watchpoint 12: -location hlinfo->mouse_face_window
> 
>     Old value = 12026738
>     New value = 18193773
>     mouse_face_from_buffer_pos (disp_string=12026738, after_string=12026738,
>         before_string=12026738, end_charpos=<optimized out>, start_charpos=6711,
>         mouse_charpos=6717, hlinfo=<optimized out>, window=18193773) at xdisp.c:28062
>     28062                                       !hlinfo->mouse_face_hidden, -1);

This is where the mouse highlight is turned on.

>     Hardware watchpoint 12: -location hlinfo->mouse_face_window
> 
>     Old value = 18193773
>     New value = 12026738
>     reset_mouse_highlight (hlinfo=0x13960a0) at dispextern.h:2725
>     2725            hlinfo->mouse_face_overlay = Qnil;
>     #0  reset_mouse_highlight (hlinfo=0x13960a0) at dispextern.h:2725
>     #1  x_update_window_end (w=0x1139998, cursor_on_p=<optimized out>,
>         mouse_face_overwritten_p=<optimized out>) at xterm.c:600
>     #2  0x000000000041b17d in update_window (w=w <at> entry=0x1139998,
>         force_p=<optimized out>, force_p <at> entry=true) at dispnew.c:3486

And this seems to be our villain.  Does the patch below help?

=== modified file 'src/xterm.c'
--- src/xterm.c	2014-04-17 09:07:58 +0000
+++ src/xterm.c	2014-05-29 15:54:27 +0000
@@ -597,7 +597,13 @@ x_update_window_end (struct window *w, b
   /* If a row with mouse-face was overwritten, arrange for
      XTframe_up_to_date to redisplay the mouse highlight.  */
   if (mouse_face_overwritten_p)
-    reset_mouse_highlight (MOUSE_HL_INFO (XFRAME (w->frame)));
+    {
+      Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (XFRAME (w->frame));
+
+      hlinfo->mouse_face_beg_row = hlinfo->mouse_face_beg_col = -1;
+      hlinfo->mouse_face_end_row = hlinfo->mouse_face_end_col = -1;
+      hlinfo->mouse_face_window = Qnil;
+    }
 }
 
 

Previous Next

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