* bug#17588: 24.3.91; mouse-face glitchy @ 2014-05-25 19:04 Christopher Schmidt 2014-05-25 19:25 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Christopher Schmidt @ 2014-05-25 19:04 UTC (permalink / raw) To: 17588 [-- Attachment #1: Type: text/plain, Size: 1032 bytes --] emacs -q M-: (run-at-time nil 0.01 (lambda () (with-current-buffer (get-buffer-create "rms") (with-silent-modifications (dotimes (_ 10) (insert (if (= (random 2) 1) "gpl" "fsf") "\n"))) (when (> (- (point-max) (point-min)) 100) (delete-region (point-min) (+ (point-min) 100)))))) RET C-x 2 C-x 3 C-x b rms RET C-x o C-x b rms2 RET C-x o C-x b rms2 RET M-: (dotimes (i 1000) (insert (propertize (format "%3d%3d%3d" i i i) 'mouse-face 'highlight) "\n")) RET # Move your mouse pointer around within the rms2 windows and the # modeline of the rms window. I see two glitches with regard to mouse-face highlighting. Either there is no highlighting at all or the font does not switch back to the regular one after leaving the connected highlight region. [-- Attachment #2: bug.png --] [-- Type: image/png, Size: 15588 bytes --] [-- Attachment #3: Type: text/plain, Size: 964 bytes --] This recipe is not exactly reliable. It usually takes up to 20 seconds of mouse movement to trigger the issue here. Some scrolling helps. I realise my recipe puts a lot of pressure on the display engine. When reducing the timer's REPEAT value, the issue does not vanish but is harder to reproduce. My real use-case, which provokes this issue after a few minutes, is a process filter which updates the buffer of a window exactly once a second. When applying this recipe to 24.3 on the same system using the same libraries for building the binary, there are some glitches. Most notably the mouse face of mode-line-buffer-identification is not reset reliably. Yet 24.3.91 is a lot worse than 24.3. IMO this is a regression. In GNU Emacs 24.3.91.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) Repository revision: 117154 eliz@gnu.org-20140525141846-w6719v7ajcd3tbkk Windowing system distributor `The X.Org Foundation', version 11.0.11204000 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 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-27 13:09 ` martin rudalics 0 siblings, 2 replies; 23+ messages in thread From: Eli Zaretskii @ 2014-05-25 19:25 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > From: Christopher Schmidt <ch@ristopher.com> > Date: Sun, 25 May 2014 15:04:18 -0400 (EDT) > > emacs -q > M-: (run-at-time nil 0.01 > (lambda () > (with-current-buffer (get-buffer-create "rms") > (with-silent-modifications > (dotimes (_ 10) > (insert (if (= (random 2) 1) "gpl" "fsf") "\n"))) > (when (> (- (point-max) (point-min)) 100) > (delete-region (point-min) (+ (point-min) 100)))))) RET > C-x 2 > C-x 3 > C-x b rms RET > C-x o > C-x b rms2 RET > C-x o > C-x b rms2 RET > M-: (dotimes (i 1000) > (insert (propertize (format "%3d%3d%3d" i i i) > 'mouse-face 'highlight) > "\n")) RET > # Move your mouse pointer around within the rms2 windows and the > # modeline of the rms window. > > I see two glitches with regard to mouse-face highlighting. Either there > is no highlighting at all or the font does not switch back to the > regular one after leaving the connected highlight region. > > This recipe is not exactly reliable. It usually takes up to 20 seconds > of mouse movement to trigger the issue here. Some scrolling helps. > > I realise my recipe puts a lot of pressure on the display engine. When > reducing the timer's REPEAT value, the issue does not vanish but is > harder to reproduce. My real use-case, which provokes this issue after > a few minutes, is a process filter which updates the buffer of a window > exactly once a second. > > When applying this recipe to 24.3 on the same system using the same > libraries for building the binary, there are some glitches. Most > notably the mouse face of mode-line-buffer-identification is not reset > reliably. Yet 24.3.91 is a lot worse than 24.3. IMO this is a > regression. I see no problems with this recipe on my system. Maybe my machine is faster than yours. In general, each redisplay requires removing the mouse-highlight and then re-applying it, so if Emacs cannot keep up, you might see annoyingly visible flickering or even such extreme effects as you describe. There's nothing new here. May I ask what is the real-life situation where you need to refresh the display at such high frequency? ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-25 19:25 ` Eli Zaretskii @ 2014-05-25 20:04 ` Christopher Schmidt 2014-05-26 2:38 ` Eli Zaretskii 2014-05-27 13:09 ` martin rudalics 1 sibling, 1 reply; 23+ messages in thread From: Christopher Schmidt @ 2014-05-25 20:04 UTC (permalink / raw) To: 17588 Eli Zaretskii <eliz@gnu.org> writes: > In general, each redisplay requires removing the mouse-highlight and > then re-applying it, so if Emacs cannot keep up, you might see > annoyingly visible flickering or even such extreme effects as you > describe. There's nothing new here. There is no flickering. The artefacts are permanent. It can work just fine. Something triggers the issue. After triggering, scrolling or resizing windows of the affected frame usually make the artefacts disappear again and highlighting works just fine. The window configuration of my recipe is important, too. Using just one rms2 window makes it impossible to reproduce this issue here. > From: Christopher Schmidt <ch@ristopher.com> > Date: Sun, 25 May 2014 15:04:18 -0400 (EDT) [...] >> My real use-case, which provokes this issue after a few minutes, is a >> process filter which updates the buffer of a window exactly once a >> second. [...] > May I ask what is the real-life situation where you need to refresh > the display at such high frequency? I do not think updating a window once a second is unreasonable. I have never seen this issue with 24.3. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-25 20:04 ` Christopher Schmidt @ 2014-05-26 2:38 ` Eli Zaretskii 2014-05-26 8:35 ` Christopher Schmidt 2014-05-26 20:45 ` Michael Heerdegen 0 siblings, 2 replies; 23+ messages in thread From: Eli Zaretskii @ 2014-05-26 2:38 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > From: Christopher Schmidt <ch@ristopher.com> > Date: Sun, 25 May 2014 16:04:43 -0400 (EDT) > > Eli Zaretskii <eliz@gnu.org> writes: > > In general, each redisplay requires removing the mouse-highlight and > > then re-applying it, so if Emacs cannot keep up, you might see > > annoyingly visible flickering or even such extreme effects as you > > describe. There's nothing new here. > > There is no flickering. The artefacts are permanent. > > It can work just fine. Something triggers the issue. After triggering, > scrolling or resizing windows of the affected frame usually make the > artefacts disappear again and highlighting works just fine. > > The window configuration of my recipe is important, too. Using just one > rms2 window makes it impossible to reproduce this issue here. > > > From: Christopher Schmidt <ch@ristopher.com> > > Date: Sun, 25 May 2014 15:04:18 -0400 (EDT) > [...] > >> My real use-case, which provokes this issue after a few minutes, is a > >> process filter which updates the buffer of a window exactly once a > >> second. > [...] > > May I ask what is the real-life situation where you need to refresh > > the display at such high frequency? > > I do not think updating a window once a second is unreasonable. I have > never seen this issue with 24.3. Well, I don't see any issues now, either. Perhaps some other factor is at work here. How was your Emacs built? (The information collected by 'report-emacs-bug' was not present in your report.) Also, can you try running this on some other machine, perhaps a faster one? ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 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:45 ` Michael Heerdegen 1 sibling, 1 reply; 23+ messages in thread From: Christopher Schmidt @ 2014-05-26 8:35 UTC (permalink / raw) To: 17588 Eli Zaretskii <eliz@gnu.org> writes: > How was your Emacs built? (The information collected by > 'report-emacs-bug' was not present in your report.) No explicit configuration options were used. I used a recent build of the emacs-24 branch for this report. AFAICT bug reports via M-x report-emacs-bug RET in emacs-24 do not expose configuration features beyond what is in system-configuration-options. Using the trunk, where I can reproduce this issue with my recipe as well, I get Configured features: XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY LIBSELINUX LIBXML2 FREETYPE XFT ZLIB This is what configure says: Configured for `x86_64-unknown-linux-gnu'. Where should the build process find the source code? . What compiler should emacs be built with? gcc -std=gnu99 -g3 -O2 Should Emacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should Emacs use a relocating allocator for buffers? no Should Emacs use mmap(2) for buffer allocation? no What window system should Emacs use? x11 What toolkit should Emacs use? GTK2 Where do we find X Windows header files? Standard dirs Where do we find X Windows libraries? Standard dirs Does Emacs use -lXaw3d? no Does Emacs use -lXpm? yes Does Emacs use -ljpeg? yes Does Emacs use -ltiff? yes Does Emacs use a gif library? yes -lgif Does Emacs use a png library? yes -lpng12 -lz -lm Does Emacs use -lrsvg-2? no Does Emacs use imagemagick? no Does Emacs support sound? yes Does Emacs use -lgpm? no Does Emacs use -ldbus? yes Does Emacs use -lgconf? no Does Emacs use GSettings? yes Does Emacs use a file notification library? yes -lgio (gfile) Does Emacs use access control lists? no Does Emacs use -lselinux? yes Does Emacs use -lgnutls? no Does Emacs use -lxml2? yes Does Emacs use -lfreetype? yes Does Emacs use -lm17n-flt? no Does Emacs use -lotf? no Does Emacs use -lxft? yes Does Emacs directly use zlib? yes Does Emacs use toolkit scroll bars? yes My environment specs can be found in the initial message: In GNU Emacs 24.3.91.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) Repository revision: 117154 eliz@gnu.org-20140525141846-w6719v7ajcd3tbkk Windowing system distributor `The X.Org Foundation', version 11.0.11204000 This is a Debian GNU/Linux "wheezy" system. This issue can be reproduced with GTK+ 3, too. > Also, can you try running this on some other machine, perhaps a faster > one? I do not have access to any other machine with a window system at the moment. This one: $ grep "model name" /proc/cpuinfo | uniq model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-26 8:35 ` Christopher Schmidt @ 2014-05-26 15:37 ` Eli Zaretskii 2014-05-26 20:17 ` Christopher Schmidt 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2014-05-26 15:37 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > From: Christopher Schmidt <ch@ristopher.com> > Date: Mon, 26 May 2014 04:35:18 -0400 (EDT) > > Eli Zaretskii <eliz@gnu.org> writes: > > How was your Emacs built? (The information collected by > > 'report-emacs-bug' was not present in your report.) > > No explicit configuration options were used. > > I used a recent build of the emacs-24 branch for this report. AFAICT > bug reports via M-x report-emacs-bug RET in emacs-24 do not expose > configuration features beyond what is in system-configuration-options. Sorry, I didn't see the telltale "Configured with:" heading, and assumed that you elided that part. That heading is present in the branch version as well. > I do not have access to any other machine with a window system at the > moment. > > This one: > > $ grep "model name" /proc/cpuinfo | uniq > model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz This is even slightly better than mine (Core i7-2600 CPU @ 3.40). And on top of that, your build is optimized, so should be roughly twice faster than what I'm running. IOW, this is hardly about CPU power, at least not as far as Emacs's application thread is concerned. It is also probably X specific. Can you see how much of your CPU resources are busy when you run the recipe? When I run it here, I see about 12% to 25% of a single execution unit occupied by Emacs. Do you see something different, and do you see some other process (e.g., the X server) pegging the CPU, perhaps? Another thought is to see whether the function that paints and clears the mouse highlight is called when it should be. You could add some printf to note_mouse_highlight, where it calls show_mouse_face and clear_mouse_face, and see if the corresponding print-outs are visible when they should be. E.g., if you move the mouse pointer from one line of text with mouse face to another, you should see a call that clears mouse face on the previous line and shows it on the current one. Thanks. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-26 15:37 ` Eli Zaretskii @ 2014-05-26 20:17 ` Christopher Schmidt 2014-05-27 2:40 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Christopher Schmidt @ 2014-05-26 20:17 UTC (permalink / raw) To: 17588 Eli Zaretskii <eliz@gnu.org> writes: > Another thought is to see whether the function that paints and clears > the mouse highlight is called when it should be. You could add some > printf to note_mouse_highlight, where it calls show_mouse_face and > clear_mouse_face, and see if the corresponding print-outs are visible > when they should be. E.g., if you move the mouse pointer from one > line of text with mouse face to another, you should see a call that > clears mouse face on the previous line and shows it on the current > one. It does not look like there are calls missing. Whenever the faulty behaviour is present, in clear_mouse_face NILP (hlinfo->mouse_face_window) is always true and therefore the highlighting is not cleared. clear_mouse_face w/ bug: (gdb) p *hlinfo {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 37, mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0, mouse_face_window = 12026738, mouse_face_face_id = 34, mouse_face_overlay = 12026738, mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = -1, mouse_face_mouse_y = -1, mouse_face_past_end = false, mouse_face_defer = false, mouse_face_hidden = false} (gdb) p NILP (hlinfo->mouse_face_window) true clear_mouse_face w/o bug: (gdb) p *hlinfo {mouse_face_beg_row = 8, mouse_face_beg_col = 0, mouse_face_beg_x = 0, mouse_face_end_row = 8, mouse_face_end_col = 9, mouse_face_end_x = 81, mouse_face_window = 18061725, mouse_face_face_id = 25, mouse_face_overlay = 12026738, mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = 394, mouse_face_mouse_y = 393, mouse_face_past_end = false, mouse_face_defer = false, mouse_face_hidden = false} (gdb) p NILP (hlinfo->mouse_face_window) false ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-26 20:17 ` Christopher Schmidt @ 2014-05-27 2:40 ` Eli Zaretskii 2014-05-27 7:21 ` Christopher Schmidt 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2014-05-27 2:40 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > From: Christopher Schmidt <ch@ristopher.com> > Date: Mon, 26 May 2014 16:17:11 -0400 (EDT) > > It does not look like there are calls missing. > > Whenever the faulty behaviour is present, in clear_mouse_face > NILP (hlinfo->mouse_face_window) is always true and therefore the > highlighting is not cleared. Which faulty behavior: the one when there's no highlighting at all, or the one when it's present, but not cleared when the mouse pointer moves off the text? > clear_mouse_face w/o bug: "w/o bug" meaning what? a different Emacs version or the same version, but when it behaves correctly? ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-27 2:40 ` Eli Zaretskii @ 2014-05-27 7:21 ` Christopher Schmidt 2014-05-27 16:04 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Christopher Schmidt @ 2014-05-27 7:21 UTC (permalink / raw) To: 17588 Eli Zaretskii <eliz@gnu.org> writes: >> From: Christopher Schmidt <ch@ristopher.com> >> Date: Mon, 26 May 2014 16:17:11 -0400 (EDT) >> Whenever the faulty behaviour is present, in clear_mouse_face >> NILP (hlinfo->mouse_face_window) is always true and therefore the >> highlighting is not cleared. > > Which faulty behavior: the one when there's no highlighting at all, or > the one when it's present, but not cleared when the mouse pointer > moves off the text? The window, in which I moved my mouse pointer around, had working highlighting that was not cleared. Most of the time both issues are present. That is, in one window highlighting is present but not cleared whereas in another one there is no highlighting at all. >> clear_mouse_face w/o bug: > > "w/o bug" meaning what? a different Emacs version or the same version, > but when it behaves correctly? That is from the very same process that exposed the issue but then recovered somehow. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 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 0 siblings, 2 replies; 23+ messages in thread From: Eli Zaretskii @ 2014-05-27 16:04 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > From: Christopher Schmidt <ch@ristopher.com> > Date: Tue, 27 May 2014 03:21:26 -0400 (EDT) > > Eli Zaretskii <eliz@gnu.org> writes: > >> From: Christopher Schmidt <ch@ristopher.com> > >> Date: Mon, 26 May 2014 16:17:11 -0400 (EDT) > >> Whenever the faulty behaviour is present, in clear_mouse_face > >> NILP (hlinfo->mouse_face_window) is always true and therefore the > >> highlighting is not cleared. > > > > Which faulty behavior: the one when there's no highlighting at all, or > > the one when it's present, but not cleared when the mouse pointer > > moves off the text? > > The window, in which I moved my mouse pointer around, had working > highlighting that was not cleared. OK. > Most of the time both issues are present. That is, in one window > highlighting is present but not cleared whereas in another one there is > no highlighting at all. Let me see if I understand this part correctly: when you move the mouse pointer in one window showing the buffer rms2, the highlighting is shown, but is never removed when the mouse moves from one line to another. When you move the mouse into another window showing the same rms2 buffer, and let the mouse pointer in that other window hover above the text with mouse face, the highlighting there is never shown. Is that correct? > >> clear_mouse_face w/o bug: > > > > "w/o bug" meaning what? a different Emacs version or the same version, > > but when it behaves correctly? > > That is from the very same process that exposed the issue but then > recovered somehow. OK, thanks. The data you show in the debugger, viz.: > clear_mouse_face w/ bug: > > (gdb) p *hlinfo > {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 37, > mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0, > mouse_face_window = 12026738, mouse_face_face_id = 34, mouse_face_overlay = 12026738, > mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = -1, mouse_face_mouse_y = -1, > mouse_face_past_end = false, mouse_face_defer = false, mouse_face_hidden = false} > (gdb) p NILP (hlinfo->mouse_face_window) > true includes peculiar values -1 for both mouse_face_mouse_x and mouse_face_mouse_y. AFAICS, there's only one way to get these values: if clear_mouse_face is called via note_mouse_highlight from this function in xterm.c: static int note_mouse_movement (struct frame *frame, const XMotionEvent *event) { XRectangle *r; struct x_display_info *dpyinfo; if (!FRAME_X_OUTPUT (frame)) return 0; dpyinfo = FRAME_DISPLAY_INFO (frame); dpyinfo->last_mouse_movement_time = event->time; dpyinfo->last_mouse_motion_frame = frame; dpyinfo->last_mouse_motion_x = event->x; dpyinfo->last_mouse_motion_y = event->y; if (event->window != FRAME_X_WINDOW (frame)) { frame->mouse_moved = 1; dpyinfo->last_mouse_scroll_bar = NULL; note_mouse_highlight (frame, -1, -1); <<<<<<<<<<<<<<<<<<<<<<<<< dpyinfo->last_mouse_glyph_frame = NULL; return 1; } Can you see if clear_mouse_face is ever called from any other place, when the highlighting isn't cleared when you move the mouse pointer to another line of text in the same window? If there _are_ any other places from which clear_mouse_face is called, could you please show the full contents of the hlinfo struct when it arrives in clear_mouse_face in those other call sequences? FWIW, the corresponding code on w32 is never executed when I run your recipe and move inside and between the two windows that display the rms2 buffer. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-27 16:04 ` Eli Zaretskii @ 2014-05-27 17:09 ` Michael Heerdegen 2014-05-28 12:27 ` Christopher Schmidt 1 sibling, 0 replies; 23+ messages in thread From: Michael Heerdegen @ 2014-05-27 17:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christopher Schmidt, 17588 Eli Zaretskii <eliz@gnu.org> writes: > Let me see if I understand this part correctly: when you move the > mouse pointer in one window showing the buffer rms2, the highlighting > is shown, but is never removed when the mouse moves from one line to > another. When you move the mouse into another window showing the same > rms2 buffer, and let the mouse pointer in that other window hover > above the text with mouse face, the highlighting there is never shown. > Is that correct? That's exactly what I see. Let me add that in the window showing the rms2 buffer where no mouse face is ever visible (it is the window showing rms2 that is not the selected window), the text flickers a bit all the time, in a very high frequency. It seems to be redrawn all the time. Michael. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 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 1 sibling, 1 reply; 23+ messages in thread From: Christopher Schmidt @ 2014-05-28 12:27 UTC (permalink / raw) To: 17588 [-- Attachment #1: Type: text/plain, Size: 460 bytes --] Eli Zaretskii <eliz@gnu.org> writes: Thanks a lot for your help. > Can you see if clear_mouse_face is ever called from any other place, > when the highlighting isn't cleared when you move the mouse pointer to > another line of text in the same window? If there _are_ any other > places from which clear_mouse_face is called, could you please show > the full contents of the hlinfo struct when it arrives in > clear_mouse_face in those other call sequences? [-- Attachment #2: backtrace1 --] [-- Type: application/octet-stream, Size: 4533 bytes --] u(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 #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 #5 0x00007ffff65cca2a in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #6 0x00007ffff65ce6f6 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #7 0x00007ffff65ce77e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #8 0x00007ffff4a89355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x00007ffff4a89688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x00007ffff4a89744 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x00007ffff69609a1 in gtk_main_iteration () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #12 0x00000000004b6d82 in XTread_socket ( terminal=<optimized out>, hold_quit=0x7fffffffdc90) at xterm.c:7013 #13 0x00000000004e8be1 in gobble_input () at keyboard.c:6849 #14 0x00000000004e8605 in handle_async_input () at keyboard.c:7089 #15 process_pending_signals () at keyboard.c:7103 #16 0x0000000000538bba in Fmake_list (length=<optimized out>, init=12026738) at alloc.c:2637 #17 0x0000000000557b65 in concat (nargs=nargs@entry=1, args=args@entry=0x7fffffffde08, target_type=Lisp_Cons, last_special=last_special@entry=false) at fns.c:588 #18 0x0000000000558170 in Fcopy_sequence (arg=19393078) at fns.c:456 #19 0x00000000004e731f in timer_check () at keyboard.c:4567 #20 0x00000000004e7879 in readable_events (flags=1) at keyboard.c:3447 #21 0x00000000004e8cd8 in get_input_pending ( flags=flags@entry=1) at keyboard.c:6764 #22 0x00000000004ebb9c in detect_input_pending_run_timers ( do_display=do_display@entry=true) at keyboard.c:9892 #23 0x0000000000590c6f in wait_reading_process_output ( time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=12026738, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:4699 #24 0x000000000041f363 in sit_for (timeout=<optimized out>, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5805 #25 0x00000000004eca63 in read_char (commandflag=1, map=map@entry=19194998, prev_event=12026738, used_mouse_menu=used_mouse_menu@entry=0x7fffffffe58b, end_time=end_time@entry=0x0) at keyboard.c:2809 #26 0x00000000004edc75 in read_key_sequence ( keybuf=keybuf@entry=0x7fffffffe660, prompt=12026738, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9087 #27 0x00000000004ef950 in command_loop_1 () at keyboard.c:1452 #28 0x0000000000550977 in internal_condition_case ( bfun=bfun@entry=0x4ef760 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4e6bf0 <cmd_error>) at eval.c:1354 #29 0x00000000004e234e in command_loop_2 ( ignore=ignore@entry=12026738) at keyboard.c:1177 #30 0x000000000055085b in internal_catch (tag=12073890, func=func@entry=0x4e2330 <command_loop_2>, arg=12026738) at eval.c:1118 #31 0x00000000004e6807 in command_loop () at keyboard.c:1156 #32 recursive_edit_1 () at keyboard.c:777 #33 0x00000000004e6b20 in Frecursive_edit () at keyboard.c:848 #34 0x0000000000415ab9 in main (argc=0, argv=0x7fffffffe9a8) at emacs.c:1646 (gdb) p *hlinfo $1 = {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 0, mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0, mouse_face_window = 12026738, mouse_face_face_id = 0, mouse_face_overlay = 12026738, mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = 494, mouse_face_mouse_y = 378, mouse_face_past_end = false, mouse_face_defer = false, mouse_face_hidden = false} (gdb) p NILP (hlinfo->mouse_face_window) $2 = true [-- Attachment #3: backtrace2 --] [-- Type: application/octet-stream, Size: 2799 bytes --] (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 #3 0x000000000044c480 in redisplay_internal () at xdisp.c:13866 #4 0x000000000044e0d0 in redisplay_preserve_echo_area ( from_where=from_where@entry=8) at xdisp.c:14058 #5 0x00000000004ebbb3 in detect_input_pending_run_timers ( do_display=do_display@entry=true) at keyboard.c:9895 #6 0x0000000000590c6f in wait_reading_process_output ( time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=12026738, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:4699 #7 0x000000000041f363 in sit_for (timeout=<optimized out>, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5805 #8 0x00000000004eca63 in read_char (commandflag=1, map=map@entry=19194998, prev_event=12026738, used_mouse_menu=used_mouse_menu@entry=0x7fffffffe58b, end_time=end_time@entry=0x0) at keyboard.c:2809 #9 0x00000000004edc75 in read_key_sequence ( keybuf=keybuf@entry=0x7fffffffe660, prompt=12026738, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9087 #10 0x00000000004ef950 in command_loop_1 () at keyboard.c:1452 #11 0x0000000000550977 in internal_condition_case ( bfun=bfun@entry=0x4ef760 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4e6bf0 <cmd_error>) at eval.c:1354 #12 0x00000000004e234e in command_loop_2 ( ignore=ignore@entry=12026738) at keyboard.c:1177 #13 0x000000000055085b in internal_catch (tag=12073890, func=func@entry=0x4e2330 <command_loop_2>, arg=12026738) at eval.c:1118 #14 0x00000000004e6807 in command_loop () at keyboard.c:1156 #15 recursive_edit_1 () at keyboard.c:777 #16 0x00000000004e6b20 in Frecursive_edit () at keyboard.c:848 #17 0x0000000000415ab9 in main (argc=0, argv=0x7fffffffe9a8) at emacs.c:1646 (gdb) p *hlinfo $3 = {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 0, mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0, mouse_face_window = 12026738, mouse_face_face_id = 0, mouse_face_overlay = 12026738, mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = 62, mouse_face_mouse_y = 468, mouse_face_past_end = false, mouse_face_defer = false, mouse_face_hidden = false} (gdb) p NILP( hlinfo->mouse_face_window) $4 = true ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-28 12:27 ` Christopher Schmidt @ 2014-05-28 18:39 ` Eli Zaretskii 2014-05-28 20:15 ` Christopher Schmidt 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2014-05-28 18:39 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-28 18:39 ` Eli Zaretskii @ 2014-05-28 20:15 ` Christopher Schmidt 2014-05-29 15:56 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Christopher Schmidt @ 2014-05-28 20:15 UTC (permalink / raw) To: 17588 Eli Zaretskii <eliz@gnu.org> writes: >> 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. You've got me there. This is what I use for testing: (run-at-time nil 0.01 (lambda () (with-current-buffer (get-buffer-create "rms") (with-silent-modifications (dotimes (_ 10) (insert (if (= (random 2) 1) "gpl" "fsf") "\n")) (when (> (- (point-max) (point-min)) 100) (delete-region (point-min) (+ (point-min) 100))))))) (with-current-buffer (get-buffer-create "rms2") (dotimes (i 1000) (insert (propertize (format "%3d%3d%3d" i i i) 'mouse-face 'highlight) "\n"))) (with-selected-window (split-window-below) (with-selected-window (split-window-right) (switch-to-buffer "rms2")) (switch-to-buffer "rms2")) (with-selected-window (split-window-right) (switch-to-buffer "rms")) The snippet is loaded at startup via the --load option. As startup.el claims the first window to display the initial buffer, I switched to a four window setup. > 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); #0 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 #1 note_mouse_highlight (f=f@entry=0x1129898, x=<optimized out>, y=<optimized out>) at xdisp.c:29151 #2 0x00000000004b4b86 in note_mouse_movement (frame=frame@entry=0x1129898, event=event@entry=0x7fffffffdc80) at xterm.c:3887 #3 0x00000000004bcb09 in handle_one_xevent (dpyinfo=dpyinfo@entry=0x1396000, event=event@entry=0x7fffffffdc80, finish=finish@entry=0xb071e0, hold_quit=0x7fffffffdea0) at xterm.c:6644 #4 0x00000000004be320 in event_handler_gdk (gxev=0x7fffffffdc80, ev=<optimized out>, data=<optimized out>) at xterm.c:5720 #5 0x00007ffff65cca2a in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #6 0x00007ffff65ce6f6 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #7 0x00007ffff65ce77e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #8 0x00007ffff4a89355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x00007ffff4a89688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x00007ffff4a89744 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x00007ffff69609a1 in gtk_main_iteration () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #12 0x00000000004b6d82 in XTread_socket (terminal=<optimized out>, hold_quit=0x7fffffffdea0) at xterm.c:7013 #13 0x00000000004e8be1 in gobble_input () at keyboard.c:6849 #14 0x00000000004e8605 in handle_async_input () at keyboard.c:7089 #15 process_pending_signals () at keyboard.c:7103 #16 0x0000000000590e6e in wait_reading_process_output ( time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=12026738, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:4340 #17 0x000000000041f363 in sit_for (timeout=<optimized out>, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5805 #18 0x00000000004eca63 in read_char (commandflag=1, map=map@entry=19249734, prev_event=12026738, used_mouse_menu=used_mouse_menu@entry=0x7fffffffe58b, end_time=end_time@entry=0x0) at keyboard.c:2809 #19 0x00000000004edc75 in read_key_sequence (keybuf=keybuf@entry=0x7fffffffe660, prompt=12026738, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9087 #20 0x00000000004ef950 in command_loop_1 () at keyboard.c:1452 #21 0x0000000000550977 in internal_condition_case ( bfun=bfun@entry=0x4ef760 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4e6bf0 <cmd_error>) at eval.c:1354 #22 0x00000000004e234e in command_loop_2 (ignore=ignore@entry=12026738) at keyboard.c:1177 #23 0x000000000055085b in internal_catch (tag=12073890, func=func@entry=0x4e2330 <command_loop_2>, arg=12026738) at eval.c:1118 #24 0x00000000004e6807 in command_loop () at keyboard.c:1156 #25 recursive_edit_1 () at keyboard.c:777 #26 0x00000000004e6b20 in Frecursive_edit () at keyboard.c:848 #27 0x0000000000415ab9 in main (argc=0, argv=0x7fffffffe9a8) at emacs.c:1646 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@entry=0x1139998, force_p=<optimized out>, force_p@entry=true) at dispnew.c:3486 #3 0x000000000041c3fb in update_window_tree (w=0x1139998, force_p=force_p@entry=true) at dispnew.c:3161 #4 0x000000000041c3ee in update_window_tree (w=0x1144a48, force_p=force_p@entry=true) at dispnew.c:3159 #5 0x000000000041c3ee in update_window_tree (w=w@entry=0x1148c60, force_p=force_p@entry=true) at dispnew.c:3159 #6 0x000000000041e59d in update_frame (f=0x1129898, force_p=<optimized out>, inhibit_hairy_id_p=<optimized out>) at dispnew.c:3059 #7 0x000000000044c0df in redisplay_internal () at xdisp.c:13844 #8 0x000000000044e0d0 in redisplay_preserve_echo_area ( from_where=from_where@entry=9) at xdisp.c:14058 #9 0x00000000005902a8 in wait_reading_process_output ( time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=12026738, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:4398 #10 0x000000000041f363 in sit_for (timeout=<optimized out>, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5805 #11 0x00000000004eca63 in read_char (commandflag=1, map=map@entry=19249734, prev_event=12026738, used_mouse_menu=used_mouse_menu@entry=0x7fffffffe58b, end_time=end_time@entry=0x0) at keyboard.c:2809 #12 0x00000000004edc75 in read_key_sequence (keybuf=keybuf@entry=0x7fffffffe660, prompt=12026738, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9087 #13 0x00000000004ef950 in command_loop_1 () at keyboard.c:1452 #14 0x0000000000550977 in internal_condition_case ( bfun=bfun@entry=0x4ef760 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4e6bf0 <cmd_error>) at eval.c:1354 #15 0x00000000004e234e in command_loop_2 (ignore=ignore@entry=12026738) at keyboard.c:1177 #16 0x000000000055085b in internal_catch (tag=12073890, func=func@entry=0x4e2330 <command_loop_2>, arg=12026738) at eval.c:1118 #17 0x00000000004e6807 in command_loop () at keyboard.c:1156 #18 recursive_edit_1 () at keyboard.c:777 #19 0x00000000004e6b20 in Frecursive_edit () at keyboard.c:848 #20 0x0000000000415ab9 in main (argc=0, argv=0x7fffffffe9a8) at emacs.c:1646 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-28 20:15 ` Christopher Schmidt @ 2014-05-29 15:56 ` Eli Zaretskii 2014-05-29 16:14 ` Christopher Schmidt 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2014-05-29 15:56 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > From: Christopher Schmidt <ch@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@entry=0x1139998, > force_p=<optimized out>, force_p@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; + } } ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 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 0 siblings, 2 replies; 23+ messages in thread From: Christopher Schmidt @ 2014-05-29 16:14 UTC (permalink / raw) To: 17588 Eli Zaretskii <eliz@gnu.org> writes: > And this seems to be our villain. Does the patch below help? Yes, it fixes the problem. Thank you very much for your work, Eli. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-29 16:14 ` Christopher Schmidt @ 2014-05-29 16:49 ` Eli Zaretskii 2014-05-29 16:51 ` Eli Zaretskii 1 sibling, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2014-05-29 16:49 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 17588 > From: Christopher Schmidt <ch@ristopher.com> > Date: Thu, 29 May 2014 12:14:52 -0400 (EDT) > > Eli Zaretskii <eliz@gnu.org> writes: > > And this seems to be our villain. Does the patch below help? > > Yes, it fixes the problem. Great, committed to emacs-24 branch as revision 117171. > Thank you very much for your work, Eli. Thanks for your great help. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-29 16:14 ` Christopher Schmidt 2014-05-29 16:49 ` Eli Zaretskii @ 2014-05-29 16:51 ` Eli Zaretskii 1 sibling, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2014-05-29 16:51 UTC (permalink / raw) To: 17588-done > From: Christopher Schmidt <ch@ristopher.com> > Date: Thu, 29 May 2014 12:14:52 -0400 (EDT) > > Eli Zaretskii <eliz@gnu.org> writes: > > And this seems to be our villain. Does the patch below help? > > Yes, it fixes the problem. Great, committed to emacs-24 branch as revision 117171. > Thank you very much for your work, Eli. Thanks for your great help. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-26 2:38 ` Eli Zaretskii 2014-05-26 8:35 ` Christopher Schmidt @ 2014-05-26 20:45 ` Michael Heerdegen 2014-05-26 21:17 ` Michael Heerdegen 1 sibling, 1 reply; 23+ messages in thread From: Michael Heerdegen @ 2014-05-26 20:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christopher Schmidt, 17588 Eli Zaretskii <eliz@gnu.org> writes: > Well, I don't see any issues now, either. Perhaps some other factor > is at work here. > > How was your Emacs built? (The information collected by > 'report-emacs-bug' was not present in your report.) > > Also, can you try running this on some other machine, perhaps a faster > one? FWIW, when I follow the recipe, I see exactly the behavior as Christopher described. I have a recent build of the emacs-24 branch on Debian, (emacs-version) => "GNU Emacs 24.3.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) of 2014-05-25 on drachen" The artifacts in the mode-line/ outdated mouse highlighting stay there for minutes, until I e.g. switch to a different window. Michael. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-26 20:45 ` Michael Heerdegen @ 2014-05-26 21:17 ` Michael Heerdegen 2014-05-27 2:42 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Michael Heerdegen @ 2014-05-26 21:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christopher Schmidt, 17588 Michael Heerdegen <michael_heerdegen@web.de> writes: > (emacs-version) => "GNU Emacs 24.3.91.1 > (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) > of 2014-05-25 on drachen" I have rebuilt Emacs with the lucid X toolkit. There is no difference with that build, it shows exactly the same symptoms. Michael. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-26 21:17 ` Michael Heerdegen @ 2014-05-27 2:42 ` Eli Zaretskii 0 siblings, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2014-05-27 2:42 UTC (permalink / raw) To: Michael Heerdegen; +Cc: ch, 17588 > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: Christopher Schmidt <ch@ristopher.com>, 17588@debbugs.gnu.org > Date: Mon, 26 May 2014 23:17:19 +0200 > > Michael Heerdegen <michael_heerdegen@web.de> writes: > > > (emacs-version) => "GNU Emacs 24.3.91.1 > > (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) > > of 2014-05-25 on drachen" > > I have rebuilt Emacs with the lucid X toolkit. There is no > difference with that build, it shows exactly the same symptoms. That's expected: mouse highlight is an Emacs features, for which we use no toolkit-specific tricks. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-25 19:25 ` Eli Zaretskii 2014-05-25 20:04 ` Christopher Schmidt @ 2014-05-27 13:09 ` martin rudalics 2014-05-27 15:33 ` Eli Zaretskii 1 sibling, 1 reply; 23+ messages in thread From: martin rudalics @ 2014-05-27 13:09 UTC (permalink / raw) To: Eli Zaretskii, Christopher Schmidt; +Cc: 17588 > I see no problems with this recipe on my system. Maybe my machine is > faster than yours. It doesn't happen on my Windows builds and I have no clue why. But I can reproduce it with my Debian build. martin ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#17588: 24.3.91; mouse-face glitchy 2014-05-27 13:09 ` martin rudalics @ 2014-05-27 15:33 ` Eli Zaretskii 0 siblings, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2014-05-27 15:33 UTC (permalink / raw) To: martin rudalics; +Cc: ch, 17588 > Date: Tue, 27 May 2014 15:09:30 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: 17588@debbugs.gnu.org > > > I see no problems with this recipe on my system. Maybe my machine is > > faster than yours. > > It doesn't happen on my Windows builds and I have no clue why. But I can > reproduce it with my Debian build. Because it's X-specific. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2014-05-29 16:51 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.