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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: 17588 <at> debbugs.gnu.org
Subject: bug#17588: 24.3.91; mouse-face glitchy
Date: Wed, 28 May 2014 21:39:45 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Wed, 28 May 2014 08:27:57 -0400 (EDT)
> 
> (gdb) bt
> #0  clear_mouse_face (hlinfo=hlinfo <at> entry=0x1394780)
>     at xdisp.c:27495
> #1  0x0000000000457fef in note_mouse_highlight (
>     f=f <at> entry=0x1129898, x=494, y=378) at xdisp.c:28812
                           ^^^^^
Does this large value of x make sense?  AFAIU, you are in the lower
window showing the buffer rms2, and you move the mouse above the text
in that window.  The text lines in that buffer are very short, so I
wonder how come you get such a large value of the x coordinate.

> #2  0x00000000004b4b86 in note_mouse_movement (
>     frame=frame <at> entry=0x1129898, 
>     event=event <at> entry=0x7fffffffda70) at xterm.c:3887
> #3  0x00000000004bcb09 in handle_one_xevent (
>     dpyinfo=dpyinfo <at> entry=0x13946e0, 
>     event=event <at> entry=0x7fffffffda70, 
>     finish=finish <at> entry=0xb071e0, hold_quit=0x7fffffffdc90)
>     at xterm.c:6644
> #4  0x00000000004be320 in event_handler_gdk (
>     gxev=0x7fffffffda70, ev=<optimized out>, 
>     data=<optimized out>) at xterm.c:5720
> [...]
> (gdb) bt
> #0  clear_mouse_face (hlinfo=hlinfo <at> entry=0x1394780)
>     at xdisp.c:27495
> #1  0x0000000000457fef in note_mouse_highlight (f=0x1129898, 
>     x=62, y=468) at xdisp.c:28812
> #2  0x00000000004b4af1 in XTframe_up_to_date (f=<optimized out>)
>     at xterm.c:628

OK, so clear_mouse_face calls also come from event_handler_gdk and
from XTframe_up_to_date.

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?  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

When this breaks, put a watchpoint on the mouse_face_window field,
like this:

  (gdb) watch -location hlinfo->mouse_face_window
  (gdb) commands
    > bt
    > continue
    > end
  (gdb)

Then disable or delete the breakpoint in show_mouse_face, and let
Emacs run with the "continue" command.  You should see the watchpoint
trigger when a new line of text is highlighted as result of moving the
mouse, in which case mouse_face_window will get a non-nil value.  And
you should also see the watchpoint trigger in some other place, where
mouse_face_window will be reset to nil (whose value in your case seems
to be 12026738).  This code that resets mouse_face_window to nil is
the one we are looking for.

Another piece of interesting information is whether this code from
note_mouse_highlight:

  /* Which window is that in?  */
  window = window_from_coordinates (f, x, y, &part, 1);

ever returns a value of 'window' that is not nil?  It would be
interesting to see the values of x and y at this point when you move
the mouse from one line of text to another, and
window_from_coordinates returns nil.

Thanks.

Previous Next

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