unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Christopher Schmidt <ch@ristopher.com>
Cc: 17588@debbugs.gnu.org
Subject: bug#17588: 24.3.91; mouse-face glitchy
Date: Wed, 28 May 2014 21:39:45 +0300	[thread overview]
Message-ID: <83zji1hhn2.fsf@gnu.org> (raw)
In-Reply-To: <87sinu2ilw@ristopher.com>

> From: Christopher Schmidt <ch@ristopher.com>
> Date: Wed, 28 May 2014 08:27:57 -0400 (EDT)
> 
> (gdb) bt
> #0  clear_mouse_face (hlinfo=hlinfo@entry=0x1394780)
>     at xdisp.c:27495
> #1  0x0000000000457fef in note_mouse_highlight (
>     f=f@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@entry=0x1129898, 
>     event=event@entry=0x7fffffffda70) at xterm.c:3887
> #3  0x00000000004bcb09 in handle_one_xevent (
>     dpyinfo=dpyinfo@entry=0x13946e0, 
>     event=event@entry=0x7fffffffda70, 
>     finish=finish@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@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.





  reply	other threads:[~2014-05-28 18:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25 19:04 bug#17588: 24.3.91; mouse-face glitchy Christopher Schmidt
2014-05-25 19:25 ` Eli Zaretskii
2014-05-25 20:04   ` Christopher Schmidt
2014-05-26  2:38     ` Eli Zaretskii
2014-05-26  8:35       ` Christopher Schmidt
2014-05-26 15:37         ` Eli Zaretskii
2014-05-26 20:17           ` Christopher Schmidt
2014-05-27  2:40             ` Eli Zaretskii
2014-05-27  7:21               ` Christopher Schmidt
2014-05-27 16:04                 ` Eli Zaretskii
2014-05-27 17:09                   ` Michael Heerdegen
2014-05-28 12:27                   ` Christopher Schmidt
2014-05-28 18:39                     ` Eli Zaretskii [this message]
2014-05-28 20:15                       ` Christopher Schmidt
2014-05-29 15:56                         ` Eli Zaretskii
2014-05-29 16:14                           ` Christopher Schmidt
2014-05-29 16:49                             ` Eli Zaretskii
2014-05-29 16:51                             ` Eli Zaretskii
2014-05-26 20:45       ` Michael Heerdegen
2014-05-26 21:17         ` Michael Heerdegen
2014-05-27  2:42           ` Eli Zaretskii
2014-05-27 13:09   ` martin rudalics
2014-05-27 15:33     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zji1hhn2.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=17588@debbugs.gnu.org \
    --cc=ch@ristopher.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).