GNU bug report logs - #7464
24.0.50; mouse highlighting vanishes upon unsplitting window

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7464 in the body.
You can then email your comments to 7464 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; mouse highlighting vanishes upon unsplitting window
Date: Mon, 22 Nov 2010 15:57:51 +0100

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, although the mouse pointer
is still over the link.  If the cursor is moved onto the link, then the
character under the cursor shows highlighting again, and moving the
cursor within the link extends the highlighting.

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).

In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
 of 2010-11-22 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
configured using `configure  '--without-toolkit-scroll-bars''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Mon, 22 Nov 2010 19:54:21 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Mon, 22 Nov 2010 15:57:51 +0100
> Cc: 
> 
> 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, although the mouse pointer
> is still over the link.  If the cursor is moved onto the link, then the
> character under the cursor shows highlighting again, and moving the
> cursor within the link extends the highlighting.
> 
> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephen.berman <at> gmx.net, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Mon, 22 Nov 2010 21:17:34 +0200

> Date: Mon, 22 Nov 2010 19:54:21 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 7464 <at> debbugs.gnu.org
> 
> > From: Stephen Berman <stephen.berman <at> gmx.net>
> > Date: Mon, 22 Nov 2010 15:57:51 +0100
> > Cc: 
> > 
> > 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, although the mouse pointer
> > is still over the link.  If the cursor is moved onto the link, then the
> > character under the cursor shows highlighting again, and moving the
> > cursor within the link extends the highlighting.
> > 
> > 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.

From tinkering around a bit with GDB, it looks like some code removes
the mouse highlight from the glass without telling the display engine
about that.  That's why redisplay never re-highlights: it thinks the
mouse highlight is already active.

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

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stephen.berman <at> gmx.net, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Thu, 22 Mar 2012 00:29:06 +0800

Eli Zaretskii <eliz <at> gnu.org> 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?

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Wed, 21 Mar 2012 18:52:42 +0100

On Thu, 22 Mar 2012 00:29:06 +0800 Chong Yidong <cyd <at> gnu.org> wrote:

> Eli Zaretskii <eliz <at> gnu.org> 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.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: stephen.berman <at> gmx.net, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Wed, 21 Mar 2012 20:54:03 +0200

> From: Chong Yidong <cyd <at> gnu.org>
> Cc: stephen.berman <at> gmx.net,  7464 <at> debbugs.gnu.org
> Date: Thu, 22 Mar 2012 00:29:06 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> 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?

Still reproducible here.

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

From: "Stephen Berman" <stephen.berman <at> gmx.net>
To: "Stephen Berman" <stephen.berman <at> gmx.net>
Cc: Chong Yidong <cyd <at> gnu.org>, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: 21 Mar 2012 23:41:36 +0100

On Wed, 21 Mar 2012 18:52:42 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Thu, 22 Mar 2012 00:29:06 +0800 Chong Yidong <cyd <at> gnu.org> wrote:
>
>> Eli Zaretskii <eliz <at> gnu.org> 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.

But I can't reproduce it on the same machine with GNU Emacs 23.3.1
(i586-suse-linux-gnu, GTK+ Version 2.24.7) of 2011-10-30 on build34.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Thu, 22 Mar 2012 05:55:37 +0200

> Date: 21 Mar 2012 23:41:36 +0100
> From: "Stephen Berman" <stephen.berman <at> gmx.net>
> Cc: Chong Yidong <cyd <at> gnu.org>, 7464 <at> debbugs.gnu.org
> 
> >>>> 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.
> 
> But I can't reproduce it on the same machine with GNU Emacs 23.3.1
> (i586-suse-linux-gnu, GTK+ Version 2.24.7) of 2011-10-30 on build34.

Just now, I cannot reproduce it in any version, including the latest
trunk.  As you see above, I could at least at some point reproduce it
in the entire Emacs 23.x series.

So I submit that what you see is just the sign of the elusiveness of
this bug.  It exists since about forever.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Thu, 22 Mar 2012 10:51:23 -0400

> Just now, I cannot reproduce it in any version, including the latest
> trunk.  As you see above, I could at least at some point reproduce it
> in the entire Emacs 23.x series.
> So I submit that what you see is just the sign of the elusiveness of
> this bug.  It exists since about forever.

Could it simply be due to different values of `mouse-highlight'?


        Stefan

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

From: "Stephen Berman" <stephen.berman <at> gmx.net>
To: "Stefan Monnier" <monnier <at> IRO.UMontreal.CA>
Cc: Eli Zaretskii <eliz <at> gnu.org>, cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: 22 Mar 2012 18:01:33 +0100

On Thu, 22 Mar 2012 10:51:23 -0400 Stefan Monnier <monnier <at> IRO.UMontreal.CA> wrote:

>> Just now, I cannot reproduce it in any version, including the latest
>> trunk.  As you see above, I could at least at some point reproduce it
>> in the entire Emacs 23.x series.
>> So I submit that what you see is just the sign of the elusiveness of
>> this bug.  It exists since about forever.
>
> Could it simply be due to different values of `mouse-highlight'?

The value of mouse-highlight is t in both my Emacs built from the
current trunk, where I see the bug, and my Emacs 23.3 from openSUSE
12.1, where I don't see the bug (both started with -Q).

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: stephen.berman <at> gmx.net, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Thu, 22 Mar 2012 19:05:40 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Stephen Berman <stephen.berman <at> gmx.net>, cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
> Date: Thu, 22 Mar 2012 10:51:23 -0400
> 
> > Just now, I cannot reproduce it in any version, including the latest
> > trunk.  As you see above, I could at least at some point reproduce it
> > in the entire Emacs 23.x series.
> > So I submit that what you see is just the sign of the elusiveness of
> > this bug.  It exists since about forever.
> 
> Could it simply be due to different values of `mouse-highlight'?

What value?  I always try this exactly as in the recipe: with the
splash screen.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Sat, 24 Mar 2012 20:32:09 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  7464 <at> debbugs.gnu.org
> Date: Wed, 21 Mar 2012 18:52:42 +0100
> 
> On Thu, 22 Mar 2012 00:29:06 +0800 Chong Yidong <cyd <at> gnu.org> wrote:
> 
> > Eli Zaretskii <eliz <at> gnu.org> 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++;

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Sat, 24 Mar 2012 22:46:44 +0100

On Sat, 24 Mar 2012 20:32:09 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  7464 <at> debbugs.gnu.org
>> Date: Wed, 21 Mar 2012 18:52:42 +0100
>> 
>> On Thu, 22 Mar 2012 00:29:06 +0800 Chong Yidong <cyd <at> gnu.org> wrote:
>> 
>> > Eli Zaretskii <eliz <at> gnu.org> 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.  

I applied the patch and rebuilt, and confirm it fixes the bug; thanks.

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

According to my observations it is a regression, though I don't know why
your observations differ from mine.  Does your patch also fix Emacs 23
for you?  Since the code involved changed significantly between Emacs 23
and 24, I'm curious if your fix also applies to Emacs 23 -- would it go
before the invocation of free_window_matrices in delete_window?  But if
so, why do I not see the bug in Emacs 23?  (And why does Chong Yidong
not see it in Emacs 24?)

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Sun, 25 Mar 2012 05:55:25 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Sat, 24 Mar 2012 22:46:44 +0100
> 
> >                              Again, since this isn't a regression wrt
> > Emacs 23, I will not install it now unless Chong and Stefan decide I
> > should.
> 
> According to my observations it is a regression, though I don't know why
> your observations differ from mine.  Does your patch also fix Emacs 23
> for you?

I didn't try.

> why do I not see the bug in Emacs 23?  (And why does Chong Yidong
> not see it in Emacs 24?)

I don't know.  I can describe in detail what I saw in the debugger and
where, and then you and Chong could step through the same places and
see what, if anything, is different for you there.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting
	window
Date: Sun, 25 Mar 2012 14:56:46 +0200

>> 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.
[...]
> According to my observations it is a regression, though I don't know why
> your observations differ from mine.  Does your patch also fix Emacs 23
> for you?  Since the code involved changed significantly between Emacs 23
> and 24, I'm curious if your fix also applies to Emacs 23 -- would it go
> before the invocation of free_window_matrices in delete_window?  But if
> so, why do I not see the bug in Emacs 23?  (And why does Chong Yidong
> not see it in Emacs 24?)

I'm not sure whether it's relevant but `delete-other-windows' has been
rewritten completely.  With Emacs 23 it used window_loop to walk over
the windows of the frame and kill them one after the other.  With Emacs
24 it simply replaces the frame's root window with the argument window.
This also means that the implementation of `delete-other-windows' is
now completely independent from that of `delete-window'.

martin

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Sun, 25 Mar 2012 14:57:18 +0200

On Sun, 25 Mar 2012 05:55:25 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
>> Date: Sat, 24 Mar 2012 22:46:44 +0100
>> 
>> >                              Again, since this isn't a regression wrt
>> > Emacs 23, I will not install it now unless Chong and Stefan decide I
>> > should.
>> 
>> According to my observations it is a regression, though I don't know why
>> your observations differ from mine.  Does your patch also fix Emacs 23
>> for you?
>
> I didn't try.
>
>> why do I not see the bug in Emacs 23?  (And why does Chong Yidong
>> not see it in Emacs 24?)
>
> I don't know.  I can describe in detail what I saw in the debugger and
> where, and then you and Chong could step through the same places and
> see what, if anything, is different for you there.

It would interest me to try, when you have the time.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Wed, 28 Mar 2012 20:56:14 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Sun, 25 Mar 2012 14:57:18 +0200
> 
> >> why do I not see the bug in Emacs 23?  (And why does Chong Yidong
> >> not see it in Emacs 24?)
> >
> > I don't know.  I can describe in detail what I saw in the debugger and
> > where, and then you and Chong could step through the same places and
> > see what, if anything, is different for you there.
> 
> It would interest me to try, when you have the time.

Here's what I see in GDB when I step through Emacs 24 code
(delete-other-windows-internal):

  (gdb) break Fdelete_other_windows_internal
  Breakpoint 3 at 0x11e73c0: file window.c, line 2572.
  (gdb) r -q
  Starting program: D:\usr\emacs\src/./oo/i386/emacs.exe -q
  [New Thread 5492.0x458]
  [New Thread 5492.0x824]
  [New Thread 5492.0x17e4]

  Breakpoint 3, Fdelete_other_windows_internal (window=56121349, root=53254170)
      at window.c:2572
  2572      w = decode_any_window (window);
  (gdb) n
  2573      XSETWINDOW (window, w);
  (gdb) p w->current_matrix
  $1 = (struct glyph_matrix *) 0x348c980
  (gdb) p w->current_matrix->rows
  $2 = (struct glyph_row *) 0x40e4000
  (gdb) p (w->current_matrix->rows+1)->mouse_face_p
  $3 = 1

Here we see the values of the window's current_matrix glyph matrix,
and the pointer to the first glyph row of the matrix.  We also see
that the second row (== screen line) has the mouse_face_p flag set,
which tells redisplay that some of this row's glyphs are shown in
mouse face.

Stepping further:

  (gdb) n
  2574      f = XFRAME (w->frame);
  (gdb)
  2576      if (NILP (root))
  (gdb)
  2579          root = FRAME_ROOT_WINDOW (f);
  (gdb)
  2580          r = XWINDOW (root);
  (gdb)
  2596      if (EQ (window, root))
  (gdb)
  2602      else if (MINI_WINDOW_P (w)) /* && top > 0) */
  (gdb)
  2605      if (!NILP (w->buffer))
  (gdb)
  2607          startpos = marker_position (w->start);
  (gdb)
  2608          top = WINDOW_TOP_EDGE_LINE (w)
  (gdb)
  2611          if (!EQ (window, FRAME_SELECTED_WINDOW (f)))
  (gdb)
  2650      BLOCK_INPUT;
  (gdb)
  2651      free_window_matrices (r);
  (gdb) p (w->current_matrix->rows+1)->mouse_face_p
  $4 = 1
  (gdb) p w->current_matrix
  $5 = (struct glyph_matrix *) 0x348c980
  (gdb) p w->current_matrix->rows
  $6 = (struct glyph_row *) 0x40e4000

Still the same values of the pointers.  But when we step over the call
to free_window_matrices, we get this:

  (gdb) n
  2653      windows_or_buffers_changed++;
  (gdb) p w->current_matrix
  $7 = (struct glyph_matrix *) 0x0

The glyph matrix was freed and its pointer is now NULL.  And then the
call to adjust_glyphs allocates a new glyph matrix, with different
pointers:

  (gdb) until 2772
  Fdelete_other_windows_internal (window=56121349, root=53328389)
      at window.c:2772
  2772      adjust_glyphs (f);
  (gdb) p w->current_matrix
  $10 = (struct glyph_matrix *) 0x0
  (gdb) n
  2773      UNBLOCK_INPUT;
  (gdb) p w->current_matrix
  $11 = (struct glyph_matrix *) 0x348c880
  (gdb) p w->current_matrix->rows
  $12 = (struct glyph_row *) 0x413b000

However, the mouse_face_p flag is of course reset in this newly
allocated matrix:

  (gdb) p (w->current_matrix->rows+1)->mouse_face_p
  $13 = 0

A similar picture is seen in Emacs 23.3 (I didn't have 23.4 where I
tried this, sorry):

  (gdb) break Fdelete_other_windows
  Breakpoint 3 at 0x10d5476: file window.c, line 2501.
  (gdb) r -q
  Starting program: D:\usr\emacs-23.3\src/./oo/i386/emacs.exe -q
  [New Thread 3240.0x11f8]
  [New Thread 3240.0x628]
  [New Thread 3240.0xe40]

  Breakpoint 3, Fdelete_other_windows (window=45307906) at window.c:2501
  2501      if (NILP (window))
  (gdb) n
  2502        window = selected_window;
  (gdb)
  2505      w = XWINDOW (window);
  (gdb)
  2507      startpos = marker_position (w->start);
  (gdb) p w
  $1 = (struct window *) 0x3824800
  (gdb) p $1->current_matrix
  $2 = (struct glyph_matrix *) 0x2f18c00
  (gdb) p $1->current_matrix->rows
  $3 = (struct glyph_row *) 0x2d6a000
  (gdb) p ($1->current_matrix->rows+1)->mouse_face_p
  $4 = 1

Again, the mouse_face_p flag is set on the second glyph row.

Now let's step into window_loop:

  (gdb) n
  2508      top = WINDOW_TOP_EDGE_LINE (w) - FRAME_TOP_MARGIN (XFRAME (WINDOW_FRAM
  E (w)));
  (gdb)
  2510      if (MINI_WINDOW_P (w) && top > 0)
  (gdb)
  2513      window_loop (DELETE_OTHER_WINDOWS, window, 0, WINDOW_FRAME (w));
  (gdb) s
  window_loop (type=DELETE_OTHER_WINDOWS, obj=58869765, mini=0, frames=58867717)
      at window.c:2191
  2191      if (FRAMEP (frames))
  (gdb) n
  2192        f = XFRAME (frames);
  (gdb)
  2198      if (f)
  (gdb)
  2199        frame_arg = Qlambda;
  (gdb)
  2212      if (WINDOWP (obj))
  (gdb)
  2213        window = obj;
  (gdb)
  2219      windows = window_list_1 (window, mini ? Qt : Qnil, frame_arg);
  (gdb)
  2221      best_window = Qnil;
  (gdb)
  2223      for (; CONSP (windows); windows = XCDR (windows))
  (gdb)
  2227          window = XCAR (windows);
  (gdb)
  2228          w = XWINDOW (window);
  (gdb)
  2233          if (!MINI_WINDOW_P (w)
  (gdb)
  2237            switch (type)
  (gdb)
  2274                if (!EQ (window, obj))
  (gdb)
  2223      for (; CONSP (windows); windows = XCDR (windows))
  (gdb)
  2227          window = XCAR (windows);
  (gdb)
  2228          w = XWINDOW (window);
  (gdb)
  2233          if (!MINI_WINDOW_P (w)
  (gdb)
  2237            switch (type)
  (gdb)
  2274                if (!EQ (window, obj))
  (gdb)
  2275                  Fdelete_window (window);

And then into Fdelete_window:

  (gdb) s
  Fdelete_window (window=58900997) at window.c:1544
  1544      if (NILP (window))
  (gdb) n
  1547        CHECK_LIVE_WINDOW (window);
  (gdb) p $1
  $5 = (struct window *) 0x3824800
  (gdb) up 2
  #2  0x010d555d in Fdelete_other_windows (window=58869765) at window.c:2513
  2513      window_loop (DELETE_OTHER_WINDOWS, window, 0, WINDOW_FRAME (w));
  (gdb) p $1->current_matrix
  $6 = (struct glyph_matrix *) 0x2f18c00
  (gdb) p $1->current_matrix->rows
  $7 = (struct glyph_row *) 0x2d6a000
  (gdb) down 2
  #0  Fdelete_window (window=58900997) at window.c:1547
  1547        CHECK_LIVE_WINDOW (window);
  (gdb) n
  1549      f = XFRAME (WINDOW_FRAME (XWINDOW (window)));
  (gdb)
  1550      delete_window (window);

And into delete_window:

  (gdb) s
  delete_window (window=58900997) at window.c:1569
  1569      CHECK_WINDOW (window);
  (gdb) n
  1570      p = XWINDOW (window);
  (gdb)
  1573      if (NILP (p->buffer)
  (gdb)
  1578      parent = p->parent;
  (gdb)
  1579      if (NILP (parent))
  (gdb)
  1581      par = XWINDOW (parent);
  (gdb) until 1654
  delete_window (window=58900997) at window.c:1654
  1654      free_window_matrices (XWINDOW (FRAME_ROOT_WINDOW (f)));

You can see that it is going to free the matrices of the frame's root
window.  This will, of course, free all the glyph matrices of all the
child windows on that frame.  Observe:

  (gdb) up 3
  #3  0x010d555d in Fdelete_other_windows (window=58869765) at window.c:2513
  2513      window_loop (DELETE_OTHER_WINDOWS, window, 0, WINDOW_FRAME (w));
  (gdb) p w->current_matrix
  $8 = (struct glyph_matrix *) 0x2f18c00
  (gdb) p w->current_matrix->rows
  $9 = (struct glyph_row *) 0x2d6a000

Before the call to free_window_matrices, the pointers are still
intact.  Now...

  (gdb) down 3
  #0  delete_window (window=58900997) at window.c:1654
  1654      free_window_matrices (XWINDOW (FRAME_ROOT_WINDOW (f)));
  (gdb) n
  1656      tem = p->next;
  (gdb) up 3
  #3  0x010d555d in Fdelete_other_windows (window=58869765) at window.c:2513
  2513      window_loop (DELETE_OTHER_WINDOWS, window, 0, WINDOW_FRAME (w));
  (gdb) p w->current_matrix
  $10 = (struct glyph_matrix *) 0x0

The matrix is a NULL pointer.  And later:

  (gdb) until 1758
  delete_window (window=58908165) at window.c:1758
  1758      adjust_glyphs (f);
  (gdb) up 3
  #3  0x010d555d in Fdelete_other_windows (window=58869765) at window.c:2513
  2513      window_loop (DELETE_OTHER_WINDOWS, window, 0, WINDOW_FRAME (w));
  (gdb) p w->current_matrix
  $13 = (struct glyph_matrix *) 0x0
  (gdb) down 3
  #0  delete_window (window=58908165) at window.c:1758
  1758      adjust_glyphs (f);
  (gdb) n
  1759      UNBLOCK_INPUT;
  (gdb) up 3
  #3  0x010d555d in Fdelete_other_windows (window=58869765) at window.c:2513
  2513      window_loop (DELETE_OTHER_WINDOWS, window, 0, WINDOW_FRAME (w));
  (gdb) p w->current_matrix
  $14 = (struct glyph_matrix *) 0x3872000
  (gdb) p w->current_matrix->rows
  $15 = (struct glyph_row *) 0x39ee000

As in Emacs 24, the call to adjust_glyphs reallocates a new glyph
matrix for the window that is left on the frame, and the mouse_face_p
flag is zero in that matrix.

So, while the code was indeed rewritten, the problem that caused the
bug was not affected: freeing the glyph matrix of the window without
signaling to the display engine that it should recreate the mouse
highlight on the next redisplay cycle.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Thu, 29 Mar 2012 09:57:53 +0200

On Wed, 28 Mar 2012 20:56:14 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
>> Date: Sun, 25 Mar 2012 14:57:18 +0200
>> 
>> >> why do I not see the bug in Emacs 23?  (And why does Chong Yidong
>> >> not see it in Emacs 24?)
>> >
>> > I don't know.  I can describe in detail what I saw in the debugger and
>> > where, and then you and Chong could step through the same places and
>> > see what, if anything, is different for you there.
>> 
>> It would interest me to try, when you have the time.
>
> Here's what I see in GDB when I step through Emacs 24 code
> (delete-other-windows-internal):

Thanks for the very instructive debugging details; they led to some
unexpected observations, which I hope you can (help me) make sense of.

Since unlike you I did't see the highlighting disappear in Emacs 23, I
wanted to try and follow your instructions there, and since I don't have
the C sources of 23.3 from openSUSE installed on my machine, I
downloaded the tarball of 23.4, configured and built it, and tested the
bug recipe -- and to my surprise, I hit the bug: the mouse highlighting
vanished, just as I observe with Emacs 24.  I don't think the window
deletion code of 23.4 differs from that of 23.4, but the two builds do
differ in a way I didn't think would be relevant, but proved to be:
openSUSE's 23.3 has GTK scroll bars, while I built 23.4 like I build 24,
i.e., without toolkit scroll bars.  So I rebuilt 23.4 with GTK scroll
bars, did the bug recipe and sure enough, now the mouse highlighting
remained, i.e., no bug.  Then I disabled the scroll bars in that build,
tested again, and got the bug again.  Then I rebuilt Emacs 24 with GTK
scroll bars, and now did not see the bug with them enabled but did see
it with them disabled.  So the answers to my questions above appear to
involve the presence vs. absence of GTK scroll bars.  (I guess Chong
Yidong also builds Emacs 24 with GTK scroll bars and tested the recipe
with them enabled, so that's why he did not observe the bug.)

After these tests, I ran both Emacs 24 builds (i.e., with and without
GTK scroll bars) under gdb, and in both cases, the value of
(w->current_matrix->rows+1)->mouse_face_p is 0 both at the breakpoint
and after the call to free_window_matrices (and of course after
adjust_glyphs).  I also ran 23.4 under gdb, with the same result:
(w->current_matrix->rows+1)->mouse_face_p is already 0 before
adjust_glyphs.  Do you have any idea why, or any further debugging
suggestions?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Thu, 29 Mar 2012 20:47:09 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Thu, 29 Mar 2012 09:57:53 +0200
> 
> openSUSE's 23.3 has GTK scroll bars, while I built 23.4 like I build 24,
> i.e., without toolkit scroll bars.  So I rebuilt 23.4 with GTK scroll
> bars, did the bug recipe and sure enough, now the mouse highlighting
> remained, i.e., no bug.  Then I disabled the scroll bars in that build,
> tested again, and got the bug again.  Then I rebuilt Emacs 24 with GTK
> scroll bars, and now did not see the bug with them enabled but did see
> it with them disabled.  So the answers to my questions above appear to
> involve the presence vs. absence of GTK scroll bars.  (I guess Chong
> Yidong also builds Emacs 24 with GTK scroll bars and tested the recipe
> with them enabled, so that's why he did not observe the bug.)

Unfortunately, I know almost nothing about how GTK in general and GTK
scroll bars in particular are integrated into Emacs, and what, if
anything, they change in how the Emacs display engine works.

> After these tests, I ran both Emacs 24 builds (i.e., with and without
> GTK scroll bars) under gdb, and in both cases, the value of
> (w->current_matrix->rows+1)->mouse_face_p is 0 both at the breakpoint
> and after the call to free_window_matrices (and of course after
> adjust_glyphs).  I also ran 23.4 under gdb, with the same result:
> (w->current_matrix->rows+1)->mouse_face_p is already 0 before
> adjust_glyphs.  Do you have any idea why, or any further debugging
> suggestions?

The other piece of info I can share is how the mouse_face_p flag that
is reset clears the mouse highlight.  This happens in
update_window_line:


      /* Update the display of the text area.  */
      if (update_text_area (w, vpos))
	{
	  changed_p = 1;
	  if (current_row->mouse_face_p)
	    *mouse_face_overwritten_p = 1;
	}
  ...
  /* Update current_row from desired_row.  */
  make_current (w->desired_matrix, w->current_matrix, vpos);

And in make_current we see this:

  struct glyph_row *current_row = MATRIX_ROW (current_matrix, row);
  struct glyph_row *desired_row = MATRIX_ROW (desired_matrix, row);
  int mouse_face_p = current_row->mouse_face_p;

  /* Do current_row = desired_row.  This exchanges glyph pointers
     between both rows, and does a structure assignment otherwise.  */
  assign_row (current_row, desired_row);

  /* Enable current_row to mark it as valid.  */
  current_row->enabled_p = 1;
  current_row->mouse_face_p = mouse_face_p;

So if the mouse_face_p flag is reset in the current glyph matrix, it
will be forcibly reset in the desired matrix, and also, the
display-specific update_end_hook function will be called with
mouse_face_overwritten_p arg set to zero, and will not redraw the
mouse-highlighted characters:

      rif->update_window_end_hook (w, !paused_p, mouse_face_overwritten_p);

Perhaps you could step through these functions and see what happens
there with and without GTK scroll bars.  To do so, put a breakpoint
inside Fdelete_other_windows_internal, do the recipe, and when the
breakpoint breaks, put a breakpoint in redisplay_internal and
continue.  When the breakpoint in redisplay_internal breaks, put a
breakpoint in update_window, and step through the loop which updates
the screen lines:

      /* Update the rest of the lines.  */
      for (; row < end && (force_p || !input_pending); ++row)

This loop calls update_window_line:

	    changed_p |= update_window_line (w, vpos,
					     &mouse_face_overwritten_p);

Does the mouse_face_overwritten_p flag return being set when the line
with highlight is updated?

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

From: "Stephen Berman" <stephen.berman <at> gmx.net>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: 30 Mar 2012 00:56:02 +0200

On Thu, 29 Mar 2012 20:47:09 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
>> Date: Thu, 29 Mar 2012 09:57:53 +0200
>> 
>> openSUSE's 23.3 has GTK scroll bars, while I built 23.4 like I build 24,
>> i.e., without toolkit scroll bars.  So I rebuilt 23.4 with GTK scroll
>> bars, did the bug recipe and sure enough, now the mouse highlighting
>> remained, i.e., no bug.  Then I disabled the scroll bars in that build,
>> tested again, and got the bug again.  Then I rebuilt Emacs 24 with GTK
>> scroll bars, and now did not see the bug with them enabled but did see
>> it with them disabled.  So the answers to my questions above appear to
>> involve the presence vs. absence of GTK scroll bars.  (I guess Chong
>> Yidong also builds Emacs 24 with GTK scroll bars and tested the recipe
>> with them enabled, so that's why he did not observe the bug.)
>
> Unfortunately, I know almost nothing about how GTK in general and GTK
> scroll bars in particular are integrated into Emacs, and what, if
> anything, they change in how the Emacs display engine works.
>
>> After these tests, I ran both Emacs 24 builds (i.e., with and without
>> GTK scroll bars) under gdb, and in both cases, the value of
>> (w->current_matrix->rows+1)->mouse_face_p is 0 both at the breakpoint
>> and after the call to free_window_matrices (and of course after
>> adjust_glyphs).  I also ran 23.4 under gdb, with the same result:
>> (w->current_matrix->rows+1)->mouse_face_p is already 0 before
>> adjust_glyphs.  Do you have any idea why, or any further debugging
>> suggestions?

In the meantime I also built Emacs 24 --with-x-toolkit=athena, and this
shows the bug just like the non-toolkit-scrollbar and scrollbarless GTK
builds.  I ran the Athena build under gdb and carried out the
instructions from your previous post, and here too,
(w->current_matrix->rows+1)->mouse_face_p is 0 at the breakpoint.

[...]
> Perhaps you could step through these functions and see what happens
> there with and without GTK scroll bars.  To do so, put a breakpoint
> inside Fdelete_other_windows_internal, do the recipe, and when the
> breakpoint breaks, put a breakpoint in redisplay_internal and
> continue.  When the breakpoint in redisplay_internal breaks, put a
> breakpoint in update_window, and step through the loop which updates
> the screen lines:
>
>       /* Update the rest of the lines.  */
>       for (; row < end && (force_p || !input_pending); ++row)
>
> This loop calls update_window_line:
>
> 	    changed_p |= update_window_line (w, vpos,
> 					     &mouse_face_overwritten_p);

I got this far, but...

> Does the mouse_face_overwritten_p flag return being set when the line
> with highlight is updated?

...I don't understand what I should do to answer this question.  Here's
what I tried (the Emacs window was still displaying mouse highlighting):

(gdb) 
3655                changed_p |= update_window_line (w, vpos,
(gdb) s
update_window_line (w=0x88a9290, vpos=2, mouse_face_overwritten_p=0xbfffd17c)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:4009
4009      struct glyph_row *current_row = MATRIX_ROW (w->current_matrix, vpos);
(gdb) n
4010      struct glyph_row *desired_row = MATRIX_ROW (w->desired_matrix, vpos);
(gdb) p w->current_matrix
$8 = (struct glyph_matrix *) 0x89f2e58
(gdb) p w->current_matrix->rows
$9 = (struct glyph_row *) 0x8aa18a0
(gdb) p (w->current_matrix->rows+1)->mouse_face_p
$10 = 0
(gdb) p mouse_face_overwritten_p
$11 = (int *) 0xbfffd17c

I guess this isn't the answer you're looking for.  If you can continue
to indulge me with precise gdb instructions, I'll be happy to try again.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 09:35:45 +0300

> Date: 30 Mar 2012 00:56:02 +0200
> From: "Stephen Berman" <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
> 
> > 	    changed_p |= update_window_line (w, vpos,
> > 					     &mouse_face_overwritten_p);
> 
> I got this far, but...
> 
> > Does the mouse_face_overwritten_p flag return being set when the line
> > with highlight is updated?
> 
> ...I don't understand what I should do to answer this question.  Here's
> what I tried (the Emacs window was still displaying mouse highlighting):
> 
> (gdb) 
> 3655                changed_p |= update_window_line (w, vpos,
> (gdb) s
> update_window_line (w=0x88a9290, vpos=2, mouse_face_overwritten_p=0xbfffd17c)
>     at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:4009
> 4009      struct glyph_row *current_row = MATRIX_ROW (w->current_matrix, vpos);
> (gdb) n
> 4010      struct glyph_row *desired_row = MATRIX_ROW (w->desired_matrix, vpos);
> (gdb) p w->current_matrix
> $8 = (struct glyph_matrix *) 0x89f2e58
> (gdb) p w->current_matrix->rows
> $9 = (struct glyph_row *) 0x8aa18a0
> (gdb) p (w->current_matrix->rows+1)->mouse_face_p
> $10 = 0
> (gdb) p mouse_face_overwritten_p
> $11 = (int *) 0xbfffd17c
> 
> I guess this isn't the answer you're looking for.  If you can continue
> to indulge me with precise gdb instructions, I'll be happy to try again.

When update_window_line updates the screen line that has some
characters highlighted, it should set mouse_face_overwritten_p to a
non-zero value.  So either step over the call to update_window_line
(i.e. 'n' instead of 's'), or, if you stepped into it, type "finish",
and then look at the value of mouse_face_overwritten_p after the call.
But please do it for the row with highlight; e.g., if it's the 2nd
screen line, do it when the value of vpos is 1.

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

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting
	window
Date: Fri, 30 Mar 2012 09:43:52 +0200

Hello.

Eli Zaretskii skrev 2012-03-29 20:47:
>> From: Stephen Berman<stephen.berman <at> gmx.net>
>> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
>> Date: Thu, 29 Mar 2012 09:57:53 +0200
>>
>> openSUSE's 23.3 has GTK scroll bars, while I built 23.4 like I build 24,
>> i.e., without toolkit scroll bars.  So I rebuilt 23.4 with GTK scroll
>> bars, did the bug recipe and sure enough, now the mouse highlighting
>> remained, i.e., no bug.  Then I disabled the scroll bars in that build,
>> tested again, and got the bug again.  Then I rebuilt Emacs 24 with GTK
>> scroll bars, and now did not see the bug with them enabled but did see
>> it with them disabled.  So the answers to my questions above appear to
>> involve the presence vs. absence of GTK scroll bars.  (I guess Chong
>> Yidong also builds Emacs 24 with GTK scroll bars and tested the recipe
>> with them enabled, so that's why he did not observe the bug.)
>
> Unfortunately, I know almost nothing about how GTK in general and GTK
> scroll bars in particular are integrated into Emacs, and what, if
> anything, they change in how the Emacs display engine works.
>

It probably has something to do with the fact that Gtk+ scrollbars 
aren't handeled by the display engine and we therefore have to force a 
redraw of the scroll bars at certain points so the scrollbars look ok. 
Presumably one of these redraws does something that triggers a redraw of 
mouse highlight?  It might be that a redraw of the scroll bar generates 
some X expose/configuration event that in turn invokes the display 
engine.  I'm just speculating.


	Jan D.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: stephen.berman <at> gmx.net, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 11:00:49 +0300

> Date: Fri, 30 Mar 2012 09:43:52 +0200
> From: "Jan D." <jan.h.d <at> swipnet.se>
> CC: Stephen Berman <stephen.berman <at> gmx.net>, cyd <at> gnu.org, 
>  7464 <at> debbugs.gnu.org
> 
> It probably has something to do with the fact that Gtk+ scrollbars 
> aren't handeled by the display engine and we therefore have to force a 
> redraw of the scroll bars at certain points so the scrollbars look ok. 
> Presumably one of these redraws does something that triggers a redraw of 
> mouse highlight?  It might be that a redraw of the scroll bar generates 
> some X expose/configuration event that in turn invokes the display 
> engine.  I'm just speculating.

I think your speculation is exactly right.  Perhaps Stephen or someone
else who has access to a GTK build could confirm that an extra
redraw of mouse highlight is triggered at some point in this scenario.

Anyway, I think it is not important (however interesting and exciting)
to determine the exact reason which causes the bug not to appear in
the GTK build.  It suffices to say that any non-GTK build suffers from
this bug, and suffered in the past (Emacs 23 at least) as well.  I
think this information, and the patch that cures the bug I posted
earlier, is enough for Chong and Stefan to make the decision whether
to install the change now or defer it until after v24.1.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 10:44:52 +0200

On Fri, 30 Mar 2012 09:35:45 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

> When update_window_line updates the screen line that has some
> characters highlighted, it should set mouse_face_overwritten_p to a
> non-zero value.  So either step over the call to update_window_line
> (i.e. 'n' instead of 's'), or, if you stepped into it, type "finish",
> and then look at the value of mouse_face_overwritten_p after the call.
> But please do it for the row with highlight; e.g., if it's the 2nd
> screen line, do it when the value of vpos is 1.

I tried to make a simple test case, but I think I still don't understand
exactly what to do.  I started my Athena build, in order to circumvent
GTK+ interference with Emacs redisplay, under gdb with -Q, set a
breakpoint at Fdelete_other_windows_internal, in Emacs switched to a new
buffer, typed "test" at line 1, column 0 and then M-: (put-text-property
(point-min) (point-max) 'mouse-face 'highlight).  Then I typed C-x 2,
put the mouse over the word "test", highlighting it, typed C-x 1 and
proceeded in gdb thus:

Breakpoint 3, Fdelete_other_windows_internal (window=141594565, root=139227370)
    at /data/steve/bzr/emacs/quickfixes/src/window.c:2569
2569      w = decode_any_window (window);
(gdb) br redisplay_internal
Breakpoint 4 at 0x8084dee: file /data/steve/bzr/emacs/quickfixes/src/xdisp.c, line 12669.
(gdb) c
Continuing.

Breakpoint 4, redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12669
12669     struct window *w = XWINDOW (selected_window);
(gdb) br update_window
Breakpoint 5 at 0x8059e53: file /data/steve/bzr/emacs/quickfixes/src/dispnew.c, line 3547.
(gdb) c
Continuing.

Breakpoint 5, update_window (w=0x86b1998, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
(gdb) p w->current_matrix
$1 = (struct glyph_matrix *) 0x86c77e0
(gdb) p w->current_matrix->rows
$2 = (struct glyph_row *) 0x8918298
(gdb) p (w->current_matrix->rows+1)->mouse_face_p
$3 = 0
(gdb) n
3552      struct redisplay_interface *rif = FRAME_RIF (XFRAME (WINDOW_FRAME (w)));
(gdb) 
3566      if (force_p || !input_pending || !NILP (do_mouse_tracking))
(gdb) 
3571          int yb, changed_p = 0, mouse_face_overwritten_p = 0;
(gdb) 
3576          rif->update_window_begin_hook (w);
(gdb) 
3577          yb = window_text_bottom_y (w);
(gdb) 
3578          row = desired_matrix->rows;
(gdb) 
3579          end = row + desired_matrix->nrows - 1;
(gdb) 
3583          if (row->mode_line_p)
(gdb) 
3589            header_line_row = NULL;
(gdb) 
3592          mode_line_row = MATRIX_MODE_LINE_ROW (desired_matrix);
(gdb) 
3593          if (mode_line_row->mode_line_p && mode_line_row->enabled_p)
(gdb) 
3604          while (row < end && !row->enabled_p)
(gdb) 
3608          if (row < end && !desired_matrix->no_scrolling_p)
(gdb) 
3629            if (row->enabled_p)
(gdb) 
3631                int vpos = MATRIX_ROW_VPOS (row, desired_matrix);
(gdb) p vpos
$4 = 268435456
(gdb) 
$5 = 268435456
(gdb) n
3639                if (!force_p)
(gdb) 
3655                changed_p |= update_window_line (w, vpos,
(gdb) p vpos
$6 = 0
(gdb) n
3667                if (MATRIX_ROW_BOTTOM_Y (row) >= yb)
(gdb) p vpos
$7 = 0
(gdb) p mouse_face_overwritten_p
$8 = 0
(gdb) n
3626          for (; row < end && (force_p || !input_pending); ++row)
(gdb) 
3629            if (row->enabled_p)
(gdb) 
3631                int vpos = MATRIX_ROW_VPOS (row, desired_matrix);
(gdb) 
3639                if (!force_p)
(gdb) 
3655                changed_p |= update_window_line (w, vpos,
(gdb) p vpos
$9 = 1
(gdb) p mouse_face_overwritten_p
$10 = 0
(gdb) n
3667                if (MATRIX_ROW_BOTTOM_Y (row) >= yb)
(gdb) p mouse_face_overwritten_p
$11 = 0

At this point (vpos = 1) aren't we past the highlighted text?  Yet
nothing has changed.  What I am doing wrong?

Steve Berman

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "Jan D." <jan.h.d <at> swipnet.se>, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 10:45:13 +0200

On Fri, 30 Mar 2012 11:00:49 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Date: Fri, 30 Mar 2012 09:43:52 +0200
>> From: "Jan D." <jan.h.d <at> swipnet.se>
>> CC: Stephen Berman <stephen.berman <at> gmx.net>, cyd <at> gnu.org, 
>>  7464 <at> debbugs.gnu.org
>> 
>> It probably has something to do with the fact that Gtk+ scrollbars 
>> aren't handeled by the display engine and we therefore have to force a 
>> redraw of the scroll bars at certain points so the scrollbars look ok. 
>> Presumably one of these redraws does something that triggers a redraw of 
>> mouse highlight?  It might be that a redraw of the scroll bar generates 
>> some X expose/configuration event that in turn invokes the display 
>> engine.  I'm just speculating.
>
> I think your speculation is exactly right.  Perhaps Stephen or someone
> else who has access to a GTK build could confirm that an extra
> redraw of mouse highlight is triggered at some point in this scenario.

Can you tell me what I have to type in gdb to do this?

> Anyway, I think it is not important (however interesting and exciting)
> to determine the exact reason which causes the bug not to appear in
> the GTK build.  It suffices to say that any non-GTK build suffers from
> this bug, and suffered in the past (Emacs 23 at least) as well.  I
> think this information, and the patch that cures the bug I posted
> earlier, is enough for Chong and Stefan to make the decision whether
> to install the change now or defer it until after v24.1.

I think it should be installed now.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: jan.h.d <at> swipnet.se, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 11:57:17 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: "Jan D." <jan.h.d <at> swipnet.se>,  cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Fri, 30 Mar 2012 10:45:13 +0200
> 
> On Fri, 30 Mar 2012 11:00:49 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> Date: Fri, 30 Mar 2012 09:43:52 +0200
> >> From: "Jan D." <jan.h.d <at> swipnet.se>
> >> CC: Stephen Berman <stephen.berman <at> gmx.net>, cyd <at> gnu.org, 
> >>  7464 <at> debbugs.gnu.org
> >> 
> >> It probably has something to do with the fact that Gtk+ scrollbars 
> >> aren't handeled by the display engine and we therefore have to force a 
> >> redraw of the scroll bars at certain points so the scrollbars look ok. 
> >> Presumably one of these redraws does something that triggers a redraw of 
> >> mouse highlight?  It might be that a redraw of the scroll bar generates 
> >> some X expose/configuration event that in turn invokes the display 
> >> engine.  I'm just speculating.
> >
> > I think your speculation is exactly right.  Perhaps Stephen or someone
> > else who has access to a GTK build could confirm that an extra
> > redraw of mouse highlight is triggered at some point in this scenario.
> 
> Can you tell me what I have to type in gdb to do this?

Jan, could you please point out where in the sources we force the
redraw of the GTK scroll bars?

> > Anyway, I think it is not important (however interesting and exciting)
> > to determine the exact reason which causes the bug not to appear in
> > the GTK build.  It suffices to say that any non-GTK build suffers from
> > this bug, and suffered in the past (Emacs 23 at least) as well.  I
> > think this information, and the patch that cures the bug I posted
> > earlier, is enough for Chong and Stefan to make the decision whether
> > to install the change now or defer it until after v24.1.
> 
> I think it should be installed now.

I don't disagree; the changes are very minor and cannot do any harm.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 12:10:05 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Fri, 30 Mar 2012 10:44:52 +0200
> 
> I tried to make a simple test case, but I think I still don't understand
> exactly what to do.  I started my Athena build, in order to circumvent
> GTK+ interference with Emacs redisplay, under gdb with -Q, set a
> breakpoint at Fdelete_other_windows_internal, in Emacs switched to a new
> buffer, typed "test" at line 1, column 0 and then M-: (put-text-property
> (point-min) (point-max) 'mouse-face 'highlight).  Then I typed C-x 2,
> put the mouse over the word "test", highlighting it, typed C-x 1 and
> proceeded in gdb thus:
> [...]
> 3631                int vpos = MATRIX_ROW_VPOS (row, desired_matrix);
> (gdb) p vpos
> $4 = 268435456

vpos is garbage because line 3631 was not yet executed, you stopped
_before_ it.

> 3655                changed_p |= update_window_line (w, vpos,
> (gdb) p vpos
> $6 = 0
> (gdb) n
> 3667                if (MATRIX_ROW_BOTTOM_Y (row) >= yb)
> (gdb) p vpos
> $7 = 0
> (gdb) p mouse_face_overwritten_p
> $8 = 0

Since you put the mouse highlighting on the 1st line of the window,
its vpos is zero, so the fact that the call to update_window_line
returned with mouse_face_overwritten_p set to zero means that the bug
is present.  At this point, if you look at the Emacs display, is the
mouse highlighting still visible?  I believe in the non-GTK build the
highlighting disappears when update_window_line is called for the line
with highlighting.

> At this point (vpos = 1) aren't we past the highlighted text?

In your example, we are past it when vpos is zero.

> Yet nothing has changed.  What I am doing wrong?

I think you are in the wrong call to update_window_line (for another
window).  At this point, type "continue" and repeat the above steps
when you are inside update_window_line again.  I think this next call
to update_window_line is for the correct window.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 13:08:53 +0200

On Fri, 30 Mar 2012 12:10:05 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

> Since you put the mouse highlighting on the 1st line of the window,
> its vpos is zero, so the fact that the call to update_window_line
> returned with mouse_face_overwritten_p set to zero means that the bug
> is present.  At this point, if you look at the Emacs display, is the
> mouse highlighting still visible?  

Yes, see also below.

>                                    I believe in the non-GTK build the
> highlighting disappears when update_window_line is called for the line
> with highlighting.
>
>> At this point (vpos = 1) aren't we past the highlighted text?
>
> In your example, we are past it when vpos is zero.
>
>> Yet nothing has changed.  What I am doing wrong?
>
> I think you are in the wrong call to update_window_line (for another
> window).  At this point, type "continue" and repeat the above steps
> when you are inside update_window_line again.  I think this next call
> to update_window_line is for the correct window.

(I'm not sure this is still appropriate for the bugtracker; if you still
want to help me, maybe we should continue off list, though it's also
fine with me to keep it on list.)  I cannot tell in gdb when I'm in the
window with the mouse face highlighting.  I tried to do what you
suggested; here's the abbreviated protocol, with my comments and
questions interspersed:

  Breakpoint 3, Fdelete_other_windows_internal (window=141312565, root=139227370)
      at /data/steve/bzr/emacs/quickfixes/src/window.c:2569
  2569      w = decode_any_window (window);
  (gdb) p w
  $8 = (struct window *) 0x84c70ea

Is this the window with the mouse face highlighting or the deleted
window?

  (gdb) br redisplay_internal
  Breakpoint 6 at 0x8084dee: file /data/steve/bzr/emacs/quickfixes/src/xdisp.c, line 12669.
  (gdb) c
  Continuing.
  
  Breakpoint 6, redisplay_internal ()
      at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12669
  12669     struct window *w = XWINDOW (selected_window);
  (gdb) br update_window
  Breakpoint 7 at 0x8059e53: file /data/steve/bzr/emacs/quickfixes/src/dispnew.c, line 3547.
  (gdb) c
  Continuing.
  
  Breakpoint 7, update_window (w=0x8711888, force_p=1)
      at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
  3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
  (gdb) n
  [...]
  3655                changed_p |= update_window_line (w, vpos,
  (gdb) p w
  $9 = (struct window *) 0x8711888

Or is this the window with the mouse face highlighting?

  (gdb) p vpos
  $10 = 0
  (gdb)  p mouse_face_overwritten_p
  $11 = 0

The highlighted text (still visible in the Emacs window) is in line 2,
so why is mouse_face_overwritten_p already 0?

  (gdb) c
  Continuing.
  
  Breakpoint 7, update_window (w=0x86c4230, force_p=1)
      at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
  3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
  (gdb) n
  [...]
  3655                changed_p |= update_window_line (w, vpos,
  (gdb) p w
  $12 = (struct window *) 0x86c4230
  (gdb) p vpos
  $13 = 0
  (gdb)  p mouse_face_overwritten_p
  $14 = 0

Now we're on the first line of a third (which?) window...

  (gdb) c
  Continuing.
  
  Breakpoint 7, update_window (w=0x86f0e48, force_p=1)
      at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
  3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
  (gdb) n
  [...]
  3655                changed_p |= update_window_line (w, vpos,
  (gdb) p vpos
  $15 = 0
  (gdb)  p mouse_face_overwritten_p
  $16 = 0

Fourth window...

  (gdb) c
  Continuing.

At this point the highlighting vanished.  Does that mean the fourth
window is the one that contained the highlighting?
  
  Breakpoint 6, redisplay_internal ()
      at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12669
  12669     struct window *w = XWINDOW (selected_window);

I guess the four windows are the two vertically deployed windows (one of
which was deleted at the beginning) displaying the buffer in which I
typed "test" on line 2 + the window displaying the minibuffer + the root
window; is this right?  Why do they all show mouse_face_overwritten_p =
0 at line 1 and how can I tell which one contained the highlighted text?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 15:06:36 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Fri, 30 Mar 2012 13:08:53 +0200
> 
> I'm not sure this is still appropriate for the bugtracker

I think it's appropriate, as we still don't understand exactly what
restores the highlighting in the GTK build.

> I cannot tell in gdb when I'm in the window with the mouse face
> highlighting.

Whenever you are in update_window, typing "pp w->buffer" should
display the buffer this window is displaying.  I get to this function
3 times, with these self-explanatory results:

  Breakpoint 5, update_window (w=0x3574200, force_p=1) at dispnew.c:3547
  3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
  (gdb) pp w->buffer
  nil
  (gdb) c
  Continuing.

  Breakpoint 5, update_window (w=0x356bc00, force_p=1) at dispnew.c:3547
  3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
  (gdb) pp w->buffer
  #<buffer *GNU Emacs*>
  (gdb) c
  Continuing.

  Breakpoint 5, update_window (w=0x356ba00, force_p=1) at dispnew.c:3547
  3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
  (gdb) pp w->buffer
  #<buffer  *Minibuf-0*>

So in my case, the second call is for the window we are interested in.
(The window whose buffer is nil is the root window of the frame, which
does not display anything; it is the root of the tree of all the
windows on that frame.)

>   Breakpoint 7, update_window (w=0x8711888, force_p=1)
>       at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
>   3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
>   (gdb) n
>   [...]
>   3655                changed_p |= update_window_line (w, vpos,
>   (gdb) p w
>   $9 = (struct window *) 0x8711888
> 
> Or is this the window with the mouse face highlighting?
> 
>   (gdb) p vpos
>   $10 = 0
>   (gdb)  p mouse_face_overwritten_p
>   $11 = 0
> 
> The highlighted text (still visible in the Emacs window) is in line 2,
> so why is mouse_face_overwritten_p already 0?

This variable starts as zero.  If update_window_line finds a line with
a mouse highlight, it sets it to one; otherwise it doesn't touch it.
So if _any_ line in the window has mouse highlight, this variable will
end up being 1; otherwise it will stay at zero.

>   Breakpoint 7, update_window (w=0x86f0e48, force_p=1)
>       at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
>   3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
>   (gdb) n
>   [...]
>   3655                changed_p |= update_window_line (w, vpos,
>   (gdb) p vpos
>   $15 = 0
>   (gdb)  p mouse_face_overwritten_p
>   $16 = 0
> 
> Fourth window...
> 
>   (gdb) c
>   Continuing.
> 
> At this point the highlighting vanished.  Does that mean the fourth
> window is the one that contained the highlighting?

Maybe, maybe not.  To know exactly where the highlighting disappeared,
keep stepping with 'n', even after you exit update_window, until you
find the source line that actually clears the highlighting.  (Yes, it
could take a while, sorry, but I don't have a better suggestion.)
Then we will have our culprit, or at least the clue where to look for
it (since the line that clears the highlighting could be a call to
another function; then you'd need to step into it, etc.).

> I guess the four windows are the two vertically deployed windows (one of
> which was deleted at the beginning) displaying the buffer in which I
> typed "test" on line 2 + the window displaying the minibuffer + the root
> window; is this right?

Yes; but "pp w->buffer" will tell.

> Why do they all show mouse_face_overwritten_p = 0 at line 1 and how
> can I tell which one contained the highlighted text?

I hope this is clear now.

Thanks.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 14:20:14 +0200

30 mar 2012 kl. 10:57 skrev Eli Zaretskii:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: "Jan D." <jan.h.d <at> swipnet.se>,  cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
>> Date: Fri, 30 Mar 2012 10:45:13 +0200
>> 
>> On Fri, 30 Mar 2012 11:00:49 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>>>> Date: Fri, 30 Mar 2012 09:43:52 +0200
>>>> From: "Jan D." <jan.h.d <at> swipnet.se>
>>>> CC: Stephen Berman <stephen.berman <at> gmx.net>, cyd <at> gnu.org, 
>>>> 7464 <at> debbugs.gnu.org
>>>> 
>>>> It probably has something to do with the fact that Gtk+ scrollbars 
>>>> aren't handeled by the display engine and we therefore have to force a 
>>>> redraw of the scroll bars at certain points so the scrollbars look ok. 
>>>> Presumably one of these redraws does something that triggers a redraw of 
>>>> mouse highlight?  It might be that a redraw of the scroll bar generates 
>>>> some X expose/configuration event that in turn invokes the display 
>>>> engine.  I'm just speculating.
>>> 
>>> I think your speculation is exactly right.  Perhaps Stephen or someone
>>> else who has access to a GTK build could confirm that an extra
>>> redraw of mouse highlight is triggered at some point in this scenario.
>> 
>> Can you tell me what I have to type in gdb to do this?
> 
> Jan, could you please point out where in the sources we force the
> redraw of the GTK scroll bars?

The one relevant here is probably in gtkutil.c, xg_update_scrollbar_pos at the end of the function.
We also do it in xterm.c, x_clear_frame and x_clear_frame_area.

	Jan D.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "Jan D." <jan.h.d <at> swipnet.se>, 7464 <at> debbugs.gnu.org, cyd <at> gnu.org,
	stephen.berman <at> gmx.net
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 08:37:38 -0400

> think this information, and the patch that cures the bug I posted
> earlier, is enough for Chong and Stefan to make the decision whether
> to install the change now or defer it until after v24.1.

I think it's OK to install,


        Stefan

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 21:35:27 +0200

On Fri, 30 Mar 2012 15:06:36 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> I cannot tell in gdb when I'm in the window with the mouse face
>> highlighting.
>
> Whenever you are in update_window, typing "pp w->buffer" should
> display the buffer this window is displaying.  

Thanks for this very helpful tip.

[...]
>> The highlighted text (still visible in the Emacs window) is in line 2,
>> so why is mouse_face_overwritten_p already 0?
>
> This variable starts as zero.  If update_window_line finds a line with
> a mouse highlight, it sets it to one; otherwise it doesn't touch it.
> So if _any_ line in the window has mouse highlight, this variable will
> end up being 1; otherwise it will stay at zero.

Hm, I have failed to find where its value becomes 1; every time I typed
`p mouse_face_overwritten_p' while stepping over the code, the value was
0.  I also tried `watch mouse_face_overwritten_p' at each update_window
breakpoint: that found where the value was set to 0, but every other
watchpoint was deleted unchanged after the program left the containing
block.

[...]
> To know exactly where the highlighting disappeared,
> keep stepping with 'n', even after you exit update_window, until you
> find the source line that actually clears the highlighting.  (Yes, it
> could take a while, sorry, but I don't have a better suggestion.)
> Then we will have our culprit, or at least the clue where to look for
> it (since the line that clears the highlighting could be a call to
> another function; then you'd need to step into it, etc.).

Here's the protocol of an attempt to do this (with the Athena build of
Emacs 24):

Breakpoint 3, Fdelete_other_windows_internal (window=141560709, root=139227370)
    at /data/steve/bzr/emacs/quickfixes/src/window.c:2569
2569      w = decode_any_window (window);
(gdb) br redisplay_internal
Breakpoint 22 at 0x8084dee: file /data/steve/bzr/emacs/quickfixes/src/xdisp.c, line 12669.
(gdb) c
Continuing.

Breakpoint 22, redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12669
12669     struct window *w = XWINDOW (selected_window);
(gdb) br update_window
Breakpoint 23 at 0x8059e53: file /data/steve/bzr/emacs/quickfixes/src/dispnew.c, line 3547.
(gdb) c
Continuing.

Breakpoint 23, update_window (w=0x86c07f0, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
(gdb) c
Continuing.

Breakpoint 23, update_window (w=0x8700b80, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
(gdb) c
Continuing.

Breakpoint 23, update_window (w=0x8712ae0, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
(gdb) pp w->buffer
#<buffer  *Minibuf-0*>
(gdb) n
3552      struct redisplay_interface *rif = FRAME_RIF (XFRAME (WINDOW_FRAME (w)));
(gdb) fin
Run till exit from #0  update_window (w=0x8712ae0, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3552
0x080598af in update_window_tree (w=0x8712ae0, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3355
3355            paused_p |= update_window (w, force_p);
Value returned is $25 = 0
(gdb) n
3357          w = NILP (w->next) ? 0 : XWINDOW (w->next);
(gdb) fin
Run till exit from #0  update_window_tree (w=0x8712ae0, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3357
0x08059692 in update_frame (f=0x8700a00, force_p=1, inhibit_hairy_id_p=0)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3282
3282          paused_p = update_window_tree (root_window, force_p);
Value returned is $26 = 0
(gdb) n
3283          update_end (f);
(gdb) fin
Run till exit from #0  update_frame (f=0x8700a00, force_p=1, 
    inhibit_hairy_id_p=0)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3283
0x08085fca in redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13213
13213                     pending |= update_frame (f, 0, 0);
Value returned is $27 = 0
(gdb) n
13214                     f->updated_p = 1;
(gdb) fin
Run till exit from #0  redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13214
redisplay () at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12400
12400   }
(gdb) n
read_char (commandflag=1, nmaps=2, maps=0xbfffe6e0, prev_event=139227370, 
    used_mouse_menu=0xbfffe7b8, end_time=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:2448
2448              if (!input_pending)
(gdb) fin
Run till exit from #0  read_char (commandflag=1, nmaps=2, maps=0xbfffe6e0, 
    prev_event=139227370, used_mouse_menu=0xbfffe7b8, end_time=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:2448

Breakpoint 22, redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12669
12669     struct window *w = XWINDOW (selected_window);
(gdb) n
12673     int must_finish = 0;
(gdb) fin
Run till exit from #0  redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12673

Breakpoint 23, update_window (w=0x8700b80, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3547
3547      struct glyph_matrix *desired_matrix = w->desired_matrix;
(gdb) pp w->buffer
#<buffer a>
(gdb) n
3552      struct redisplay_interface *rif = FRAME_RIF (XFRAME (WINDOW_FRAME (w)));
(gdb) fin
Run till exit from #0  update_window (w=0x8700b80, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3552
0x080598af in update_window_tree (w=0x8700b80, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3355
3355            paused_p |= update_window (w, force_p);
Value returned is $28 = 0
(gdb) n
3357          w = NILP (w->next) ? 0 : XWINDOW (w->next);
(gdb) fin
Run till exit from #0  update_window_tree (w=0x8700b80, force_p=1)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3357
0x08059692 in update_frame (f=0x8700a00, force_p=1, inhibit_hairy_id_p=0)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3282
3282          paused_p = update_window_tree (root_window, force_p);
Value returned is $29 = 0
(gdb) n
3283          update_end (f);
(gdb) fin
Run till exit from #0  update_frame (f=0x8700a00, force_p=1, 
    inhibit_hairy_id_p=0)
    at /data/steve/bzr/emacs/quickfixes/src/dispnew.c:3283
0x080861f9 in redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13276
13276             pending = update_frame (sf, 0, 0);
Value returned is $30 = 0
(gdb) n
13284         mini_window = FRAME_MINIBUF_WINDOW (sf);
(gdb) fin
Run till exit from #0  redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13284
redisplay_preserve_echo_area (from_where=7)
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13433
13433     if (FRAME_RIF (SELECTED_FRAME ()) != NULL
(gdb) s
13434         && FRAME_RIF (SELECTED_FRAME ())->flush_display_optional)
(gdb) 
13435       FRAME_RIF (SELECTED_FRAME ())->flush_display_optional (NULL);
(gdb) 
x_flush (f=0x0) at /data/steve/bzr/emacs/quickfixes/src/xterm.c:373
373       if (!NILP (Vinhibit_redisplay))
(gdb) 
376       BLOCK_INPUT;
(gdb) 
377       if (f == NULL)
(gdb) 
380           FOR_EACH_FRAME (rest, frame)
(gdb) 
381             if (FRAME_X_P (XFRAME (frame)))
(gdb) 
382               x_flush (XFRAME (frame));
(gdb) 
x_flush (f=0x8700a00) at /data/steve/bzr/emacs/quickfixes/src/xterm.c:373
373       if (!NILP (Vinhibit_redisplay))
(gdb) 
376       BLOCK_INPUT;
(gdb) 
377       if (f == NULL)
(gdb) 
384       else if (FRAME_X_P (f))
(gdb) 
385         XFlush (FRAME_X_DISPLAY (f));
(gdb) 
386       UNBLOCK_INPUT;

When I hit RET at the gdb prompt before UNBLOCK_INPUT, the highlighting
vanished.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Fri, 30 Mar 2012 23:41:15 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Fri, 30 Mar 2012 21:35:27 +0200
> 
> Hm, I have failed to find where its value becomes 1; every time I typed
> `p mouse_face_overwritten_p' while stepping over the code, the value was
> 0.  I also tried `watch mouse_face_overwritten_p' at each update_window
> breakpoint: that found where the value was set to 0, but every other
> watchpoint was deleted unchanged after the program left the containing
> block.

This is consistent with the fact that the glyph matrices of the
original window were freed and reallocated.  They are cleared when
they are allocated.

> (gdb) 
> 385         XFlush (FRAME_X_DISPLAY (f));
> (gdb) 
> 386       UNBLOCK_INPUT;
> 
> When I hit RET at the gdb prompt before UNBLOCK_INPUT, the highlighting
> vanished.

So I think this means that the GTK build, like non-GTK builds, removes
the highlighting.  It's just that, due to peculiarities of how Emacs
works with X window system, the highlighting doesn't actually
disappear from display until some time later, when Emacs flushes
everything it has drawn to X.

Now, how does the mouse highlighting gets restored in the GTK build,
after it was cleared above?  I think the answer to that was pointed
out by Jan, earlier in this thread: the function
xg_update_scrollbar_pos in gtkutil.c.  It does this near its very end:

      x_sync (f);
      SET_FRAME_GARBAGED (f);
      cancel_mouse_face (f);

And if you look at cancel_mouse_face, you will see that it does
exactly what my proposed patch for delete-other-windows-internal would
do!

So could you please see if the above call to cancel_mouse_face is
indeed made, in the GTK build, after mouse highlighting disappears?

Actually, it would be good to put a breakpoint in cancel_mouse_face,
right after you hit the breakpoint in Fdelete_other_windows_internal,
type "continue", and see if that function ever gets called and by what
code.  When I try this on my system, I don't see the breakpoint inside
cancel_mouse_face break at all when I reproduce the recipe with "emacs -q".

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

From: "Stephen Berman" <stephen.berman <at> gmx.net>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: 31 Mar 2012 01:09:26 +0200

On Fri, 30 Mar 2012 23:41:15 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> (gdb) 
>> 385         XFlush (FRAME_X_DISPLAY (f));
>> (gdb) 
>> 386       UNBLOCK_INPUT;
>> 
>> When I hit RET at the gdb prompt before UNBLOCK_INPUT, the highlighting
>> vanished.
>
> So I think this means that the GTK build, like non-GTK builds, removes
> the highlighting.  It's just that, due to peculiarities of how Emacs
> works with X window system, the highlighting doesn't actually
> disappear from display until some time later, when Emacs flushes
> everything it has drawn to X.

You missed that I said that protocol was from the Athena build; however,
it is exactly the same in the GTK build with toolkit scrollbars
disabled.  With GTk scrollbars enabled, the highlighting doesn't
disappear at all.

> Now, how does the mouse highlighting gets restored in the GTK build,
> after it was cleared above?  I think the answer to that was pointed
> out by Jan, earlier in this thread: the function
> xg_update_scrollbar_pos in gtkutil.c.  It does this near its very end:
>
>       x_sync (f);
>       SET_FRAME_GARBAGED (f);
>       cancel_mouse_face (f);
>
> And if you look at cancel_mouse_face, you will see that it does
> exactly what my proposed patch for delete-other-windows-internal would
> do!
>
> So could you please see if the above call to cancel_mouse_face is
> indeed made, in the GTK build, after mouse highlighting disappears?

Again, AFAICT the highlighting does not disappear when GTK scrollbars
are enabled.

> Actually, it would be good to put a breakpoint in cancel_mouse_face,
> right after you hit the breakpoint in Fdelete_other_windows_internal,
> type "continue", and see if that function ever gets called and by what
> code.  When I try this on my system, I don't see the breakpoint inside
> cancel_mouse_face break at all when I reproduce the recipe with "emacs -q".

It's the same for me when I do this with the GTK scrollbars disabled,
the execution does not stop at cancel_mouse_face:

Breakpoint 3, Fdelete_other_windows_internal (window=141773653, root=139210986)
    at /data/steve/bzr/emacs/quickfixes/src/window.c:2569
2569      w = decode_any_window (window);
(gdb) br cancel_mouse_face
Breakpoint 19 at 0x80acc38: file /data/steve/bzr/emacs/quickfixes/src/xdisp.c, line 27545.
(gdb) c
Continuing.

At this point, the highlighting has vanished.  But when I set the
breakpoint with GTK scrollbars enabled, execution stops many times:

Breakpoint 19, cancel_mouse_face (f=0x87349c8)
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:27545
27545     Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
(gdb) c
Continuing.

At each break, a portion of the scroll bar is redisplayed.  For example,
after typing C-x 2, execution stops and the scroll bar vanishes.  When I
type c, the upper portion is redisplayed, then execution stops.  Next c,
the upper scroll bar vanishes but the lower one is redisplayed, then
execution stops.  Then the upper scroll bar is redisplayed again,
completing the window splitting, and the execution returns to the
command loop.  However, throughout this process, as long as the mouse
pointer remains over the mouse-face propertized text, it remains
highlighted.  Likewise after Fdelete_other_windows_internal.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Sat, 31 Mar 2012 08:56:00 +0300

> Date: 31 Mar 2012 01:09:26 +0200
> From: "Stephen Berman" <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
> 
> But when I set the breakpoint with GTK scrollbars enabled, execution
> stops many times:
> 
> Breakpoint 19, cancel_mouse_face (f=0x87349c8)
>     at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:27545
> 27545     Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
> (gdb) c
> Continuing.
> 
> At each break, a portion of the scroll bar is redisplayed.  For example,
> after typing C-x 2, execution stops and the scroll bar vanishes.  When I
> type c, the upper portion is redisplayed, then execution stops.  Next c,
> the upper scroll bar vanishes but the lower one is redisplayed, then
> execution stops.  Then the upper scroll bar is redisplayed again,
> completing the window splitting, and the execution returns to the
> command loop.  However, throughout this process, as long as the mouse
> pointer remains over the mouse-face propertized text, it remains
> highlighted.  Likewise after Fdelete_other_windows_internal.

Can you show a backtrace in a few instances when the breakpoint inside
cancel_mouse_face breaks?  I think these calls are those that keep the
highlighting from being wiped out in the GTK build.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 7464 <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Sat, 31 Mar 2012 16:01:19 +0200

[Message part 1 (text/plain, inline)]

On Sat, 31 Mar 2012 08:56:00 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

> Can you show a backtrace in a few instances when the breakpoint inside
> cancel_mouse_face breaks?  I think these calls are those that keep the
> highlighting from being wiped out in the GTK build.

I've attached two backtraces.  The first backtrace was produced
immediately after typing `r -q', with execution breaking before the
frame appeared.  The second backtrace was produced after the second
break, when the frame appeared with the menu and tool bars but no scroll
bar or text.  This backtrace and subsequent (essentially identical) ones
included no Lisp backtrace.  At the third break, the scroll bar
appeared; the backtrace is the same as the second one.  Continuing after
that, the splash screen appeared and execution reverted to the command
loop.  I then typed C-x 2 and execution broke four times to split the
window and redisplay the scroll bars.  Then C-x 1 with the mouse pointer
over a link text, showing highlighting (which remained after
continuing), the execution breaking once.  Each of these breaks produced
the same backtrace, essentially like the second one, but without the
call to x_scroll_bar_create and with a much larger level_stack in the
redisplay_window frame.

Steve Berman

[Message part 2 (text/plain, attachment)]

[Message part 3 (text/plain, attachment)]

Message #115 received at 7464-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: cyd <at> gnu.org, 7464-done <at> debbugs.gnu.org
Subject: Re: bug#7464: 24.0.50;
	mouse highlighting vanishes upon unsplitting window
Date: Sat, 31 Mar 2012 21:12:39 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: cyd <at> gnu.org,  7464 <at> debbugs.gnu.org
> Date: Sat, 31 Mar 2012 16:01:19 +0200
> 
> On Sat, 31 Mar 2012 08:56:00 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Can you show a backtrace in a few instances when the breakpoint inside
> > cancel_mouse_face breaks?  I think these calls are those that keep the
> > highlighting from being wiped out in the GTK build.
> 
> I've attached two backtraces.  The first backtrace was produced
> immediately after typing `r -q', with execution breaking before the
> frame appeared.  The second backtrace was produced after the second
> break, when the frame appeared with the menu and tool bars but no scroll
> bar or text.  This backtrace and subsequent (essentially identical) ones
> included no Lisp backtrace.  At the third break, the scroll bar
> appeared; the backtrace is the same as the second one.  Continuing after
> that, the splash screen appeared and execution reverted to the command
> loop.  I then typed C-x 2 and execution broke four times to split the
> window and redisplay the scroll bars.  Then C-x 1 with the mouse pointer
> over a link text, showing highlighting (which remained after
> continuing), the execution breaking once.  Each of these breaks produced
> the same backtrace, essentially like the second one, but without the
> call to x_scroll_bar_create and with a much larger level_stack in the
> redisplay_window frame.

Thanks.  So I think the issue is now completely clear, and with
Stefan's permission I installed the fix for this bug (as trunk
revision 107713).

I'm therefore closing the bug.

Previous Next

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