bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window


From: Eli Zaretskii
Subject: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window
Date: Sat, 24 Mar 2012 20:32:09 +0200

> From: Stephen Berman <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> Date: Wed, 21 Mar 2012 18:52:42 +0100
> 
> On Thu, 22 Mar 2012 00:29:06 +0800 Chong Yidong <address@hidden> wrote:
> 
> > Eli Zaretskii <address@hidden> writes:
> >
> >>> > 1. emacs -q
> >>> > 2. C-x 2
> >>> > 3. Put the mouse pointer over one of the links in the splash screen, so
> >>> > that the link becomes highlighted.
> >>> > 4. C-x 1
> >>> > => The highlighting from step 3 disappears
> >>>
> >>> > This problem is reliably reproducible, also on earlier builds of Emacs
> >>> > 24 I have, but not on Emacs 23.1.91 (I don't have 23.2).
> >>> 
> >>> I can reproduce it on Windows in Emacs 23.2.90 and also in stock Emacs
> >>> 23.2 and Emacs 23.1.  I don't have Emacs 23.1.90 anymore to test.
> >
> > I can't reproduce this with latest trunk (x86_64-unknown-linux-gnu, GTK+
> > Version 3.2.0).  Maybe this has been fixed since the bug report?  Eli,
> > could you check again, since you could reproduce it before?
> 
> I just updated from the trunk and rebuilt (GNU Emacs 24.0.94.6
> (i686-suse-linux-gnu, GTK+ Version 2.24.7) of 2012-03-21 on escher), and
> I can still reproduce the bug.

I found why this happens.  The lines ("glyph rows") in which some of
the glyphs are highlighted in mouse face are marked with a special
flag.  This flag is checked by redisplay, and it tells redisplay that
when that row is redrawn, its mouse face should be restored.

Now, "C-x 1" calls delete-other-windows-internal, which, as part of
its job, deletes the glyph matrices of the original window.  With that
deletion, those flags of the highlighted rows are reset, i.e. the
information about the highlight stored in the glyph matrix is lost.
But no one tells redisplay that the mouse highlight was effectively
overwritten, and that it should arrange for it to be redisplayed.

The patch below fixes that.  Again, since this isn't a regression wrt
Emacs 23, I will not install it now unless Chong and Stefan decide I
should.

=== modified file 'src/window.c'
--- src/window.c        2012-03-12 06:34:32 +0000
+++ src/window.c        2012-03-24 18:19:24 +0000
@@ -2565,6 +2565,7 @@ window-start value is reasonable when th
   Lisp_Object sibling, pwindow, swindow IF_LINT (= Qnil), delta;
   EMACS_INT startpos IF_LINT (= 0);
   int top IF_LINT (= 0), new_top, resize_failed;
+  Mouse_HLInfo *hlinfo;
 
   w = decode_any_window (window);
   XSETWINDOW (window, w);
@@ -2645,6 +2646,20 @@ window-start value is reasonable when th
     }
 
   BLOCK_INPUT;
+  hlinfo = MOUSE_HL_INFO (f);
+  /* We are going to free the glyph matrices of WINDOW, and with that
+     we might lose any information about glyph rows that have some of
+     their glyphs highlighted in mouse face.  (These rows are marked
+     with a non-zero mouse_face_p flag.)  If WINDOW indeed has some
+     glyphs highlighted in mouse face, signal to frame's up-to-date
+     hook that mouse highlight was overwritten, so that it will
+     arrange for redisplaying the highlight.  */
+  if (EQ (hlinfo->mouse_face_window, window))
+    {
+      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;
+    }
   free_window_matrices (r);
 
   windows_or_buffers_changed++;






reply via email to

[Prev in Thread] Current Thread [Next in Thread]