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

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

[Stephen Berman]

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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@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.

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

[Eli Zaretskii]

> Date: Mon, 22 Nov 2010 19:54:21 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 7464@debbugs.gnu.org
> 
> > From: Stephen Berman <stephen.berman@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.

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

[Chong Yidong]

Eli Zaretskii <eliz@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?

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

[Stephen Berman]

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

> Eli Zaretskii <eliz@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

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

[Stephen Berman]

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

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

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

[Eli Zaretskii]

> Date: 21 Mar 2012 23:41:36 +0100
> From: "Stephen Berman" <stephen.berman@gmx.net>
> Cc: Chong Yidong <cyd@gnu.org>, 7464@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.

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

[Stefan Monnier]

> 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

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

[Stephen Berman]

On Thu, 22 Mar 2012 10:51:23 -0400 Stefan Monnier <monnier@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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Stephen Berman <stephen.berman@gmx.net>, cyd@gnu.org, 7464@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.

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

[Eli Zaretskii]

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

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

[Stephen Berman]

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

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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: cyd@gnu.org,  7464@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.

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: cyd@gnu.org,  7464@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: cyd@gnu.org,  7464@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.

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: cyd@gnu.org,  7464@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: cyd@gnu.org,  7464@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?

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: cyd@gnu.org,  7464@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

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

[Eli Zaretskii]

> Date: 30 Mar 2012 00:56:02 +0200
> From: "Stephen Berman" <stephen.berman@gmx.net>
> Cc: cyd@gnu.org, 7464@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.

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

[Stephen Berman]

On Fri, 30 Mar 2012 09:35:45 +0300 Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: cyd@gnu.org,  7464@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.

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

[Stephen Berman]

On Fri, 30 Mar 2012 12:10:05 +0300 Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: cyd@gnu.org,  7464@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.

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

[Stephen Berman]

On Fri, 30 Mar 2012 15:06:36 +0300 Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: cyd@gnu.org,  7464@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".

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

[Stephen Berman]

On Fri, 30 Mar 2012 23:41:15 +0300 Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> Date: 31 Mar 2012 01:09:26 +0200
> From: "Stephen Berman" <stephen.berman@gmx.net>
> Cc: cyd@gnu.org, 7464@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.

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

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

On Sat, 31 Mar 2012 08:56:00 +0300 Eli Zaretskii <eliz@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


[-- Attachment #2: backtrace #1 --]
[-- Type: text/plain, Size: 19489 bytes --]

(gdb) r -Q
[libraries get loaded...]
Breakpoint 3, cancel_mouse_face (f=0x88a9188)
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:27545
27545     Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
(gdb) bt full
#0  cancel_mouse_face (f=0x88a9188)
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:27545
        window = 60
        hlinfo = 0x88a9770
#1  0x0814e1b3 in xg_frame_set_char_size (f=0x88a9188, cols=80, rows=35)
    at /data/steve/bzr/emacs/quickfixes/src/gtkutil.c:933
        pixelheight = 490
        pixelwidth = 602
#2  0x08120e1f in x_set_window_size (f=0x88a9188, change_gravity=0, cols=80, 
    rows=35) at /data/steve/bzr/emacs/quickfixes/src/xterm.c:8913
No locals.
#3  0x08069eff in x_set_scroll_bar_width (f=0x88a9188, arg=139210986, oldval=
    139210986) at /data/steve/bzr/emacs/quickfixes/src/frame.c:3477
        wid = 7
#4  0x0806882b in x_set_frame_parameters (f=0x88a9188, alist=139210986)
    at /data/steve/bzr/emacs/quickfixes/src/frame.c:2911
---Type <return> to continue, or q <return> to quit---
        param_index = 60                                                        
        old_value = 139210986                                                   
        prop = 139287906                                                        
        val = 139210986                                                         
        tail = 139210986                                                        
        width = 80                                                              
        height = 35                                                             
        left = 139210962                                                        
        top = 139210962                                                         
        icon_left = 139210962                                                   
        icon_top = 139210962                                                    
        parms = 0xbfffd740                                                      
        values = 0xbfffd720                                                     
        i = 0                                                                   
        p = 1                                                                   
        left_no_change = 0                                                      
---Type <return> to continue, or q <return> to quit---                          
        top_no_change = 0                                                       
        icon_left_no_change = 0                                                 
        icon_top_no_change = 0                                                  
        size_changed = 0                                                        
        gcpro1 = {                                                              
          next = 0x88d2cc9,                                                     
          var = 0x88d2cb9,                                                      
          nvars = 1                                                             
        }                                                                       
        gcpro2 = {                                                              
          next = 0xbfffd7c8,                                                    
          var = 0x806abc0,                                                      
          nvars = 1                                                             
        }                                                                       
#5  0x0806af53 in x_default_parameter (f=0x88a9188, alist=139868894, prop=      
    139287906, deflt=139210986, xprop=0x828c124 "scrollBarWidth", xclass=       
---Type <return> to continue, or q <return> to quit---                          
    0x828c115 "ScrollBarWidth", type=RES_TYPE_NUMBER)                           
    at /data/steve/bzr/emacs/quickfixes/src/frame.c:3920                        
        tem = 139210986                                                         
#6  0x0812a3da in Fx_create_frame (parms=139868894)                             
    at /data/steve/bzr/emacs/quickfixes/src/xfns.c:3401                         
        f = 0x88a9188                                                           
        frame = 143298957                                                       
        tem = 139210962                                                         
        name = 139210962                                                        
        minibuffer_only = 0                                                     
        window_prompting = 0                                                    
        width = 18                                                              
        height = 136261421                                                      
        count = 16                                                              
        gcpro1 = {                                                              
          next = 0x828b870,                                                     
---Type <return> to continue, or q <return> to quit---                          
          var = 0x84c30ea,                                                      
          nvars = -1073751816                                                   
        }
        gcpro2 = {
          next = 0x0, 
          var = 0xbfffd6bc, 
          nvars = 139210986
        }
        gcpro3 = {
          next = 0x0, 
          var = 0x8563d06, 
          nvars = 1
        }
        gcpro4 = {
          next = 0x84cb0fa, 
          var = 0x84c30d2, 
---Type <return> to continue, or q <return> to quit---
          nvars = 0
        }
        display = 139210986
        dpyinfo = 0x8703db0
        parent = 139210986
        kb = 0x8703960
#7  0x081f2618 in Ffuncall (nargs=2, args=0xbfffd9b0)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3002
        fun = 137167653
        original_fun = 139365394
        funcar = 0
        numargs = 1
        lisp_numargs = 0
        val = 139869446
        backtrace = {
          next = 0xbfffdc40, 
---Type <return> to continue, or q <return> to quit---
          function = 0xbfffd9b0, 
          args = 0xbfffd9b4, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0xbfffd9b4
        i = 0
#8  0x08230c84 in exec_byte_code (bytestr=137441553, vector=137441573, 
    maxdepth=16, args_template=139210986, nargs=0, args=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/bytecode.c:785
        count = 11
        op = 1
        vectorp = 0x8313128
        stack = {
          pc = 
    0x843a4a6 "\024Ύ\317\f!\210\320\f\b\"\210\321\f\322\"\210\323\f\b\"\210\n\2---Type <return> to continue, or q <return> to quit---
04W", 
          byte_string = 137441553, 
          byte_string_start = 
    0x843a470 "\306\b!\020\307\b!\031\310\b\236\032\311\033ʉ\034\035\v\312\036\026\211\036\027\203\060", 
          constants = 137441573, 
          next = 0xbfffdce4
        }
        top = 0xbfffd9b0
        result = 138270292
#9  0x081f2f18 in funcall_lambda (fun=137441517, nargs=1, arg_vector=0x84c30ea)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3233
        val = 1
        syms_left = 139210986
        next = 139473282
        lexenv = 139210986
---Type <return> to continue, or q <return> to quit---
        count = 10
        i = 1
        optional = 1
        rest = 0
#10 0x081f2837 in Ffuncall (nargs=2, args=0xbfffdca0)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3051
        fun = 137441517
        original_fun = 139779786
        funcar = 0
        numargs = 1
        lisp_numargs = 0
        val = 139210986
        backtrace = {
          next = 0xbfffdf40, 
          function = 0xbfffdca0, 
          args = 0xbfffdca4, 
---Type <return> to continue, or q <return> to quit---
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0xc0
        i = 140316841
#11 0x08230c84 in exec_byte_code (bytestr=137770961, vector=137770981, 
    maxdepth=20, args_template=139210986, nargs=0, args=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/bytecode.c:785
        count = 5
        op = 1
        vectorp = 0x83637e8
        stack = {
          pc = 
    0x8404a9e "\026\027\320\016\027!\210\016\035\311\036\036\211\036\037\203", <incomplete sequence \354>, 
          byte_string = 137770961, 
---Type <return> to continue, or q <return> to quit---
          byte_string_start = 0x84049ee "\306\b\236\203,", 
          constants = 137770981, 
          next = 0xbfffdfe4
        }
        top = 0xbfffdca0
        result = 139869718
#12 0x081f2f18 in funcall_lambda (fun=137770933, nargs=1, arg_vector=0x84c30ea)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3233
        val = 1
        syms_left = 139210986
        next = 139473282
        lexenv = 139210986
        count = 4
        i = 1
        optional = 1
        rest = 0
---Type <return> to continue, or q <return> to quit---
#13 0x081f2837 in Ffuncall (nargs=2, args=0xbfffdfa0)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3051
        fun = 137770933
        original_fun = 139709370
        funcar = 0
        numargs = 1
        lisp_numargs = -1073750136
        val = 139210986
        backtrace = {
          next = 0xbfffe240, 
          function = 0xbfffdfa0, 
          args = 0xbfffdfa4, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x84c30ea
---Type <return> to continue, or q <return> to quit---
        i = 0
#14 0x08230c84 in exec_byte_code (bytestr=137768257, vector=137768277, 
    maxdepth=24, args_template=139210986, nargs=0, args=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/bytecode.c:785
        count = 4
        op = 1
        vectorp = 0x8362d58
        stack = {
          pc = 
    0x8405329 "\211\026\024\026\025\317\v!\023\320\016\024\321\322\n\321\"#\210\323\n!\210ʉ\022\207", 
          byte_string = 137768257, 
          byte_string_start = 0x84052f8 "\b\205K", 
          constants = 137768277, 
          next = 0xbfffe314
        }
---Type <return> to continue, or q <return> to quit---
        top = 0xbfffdfa0
        result = 135481803
#15 0x081f2f18 in funcall_lambda (fun=137768229, nargs=0, arg_vector=0x84c30ea)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3233
        val = 139210986
        syms_left = 139210986
        next = 139232096
        lexenv = 139210986
        count = 4
        i = 0
        optional = 0
        rest = 0
#16 0x081f2837 in Ffuncall (nargs=1, args=0xbfffe2a0)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3051
        fun = 137768229
        original_fun = 139778098
---Type <return> to continue, or q <return> to quit---
        funcar = 0
        numargs = 0
        lisp_numargs = -1073749368
        val = 139211010
        backtrace = {
          next = 0xbfffe570, 
          function = 0xbfffe2a0, 
          args = 0xbfffe2a4, 
          nargs = 0, 
          debug_on_exit = 0
        }
        internal_args = 0x50
        i = 139871318
#17 0x08230c84 in exec_byte_code (bytestr=137461305, vector=137461325, 
    maxdepth=72, args_template=0, nargs=0, args=0xbfffe5d8)
    at /data/steve/bzr/emacs/quickfixes/src/bytecode.c:785
---Type <return> to continue, or q <return> to quit---
        count = 4
        op = 0
        vectorp = 0x8317e50
        stack = {
          pc = 0x8437642 "\210\201\210", 
          byte_string = 137461305, 
          byte_string_start = 
    0x8437396 "\306 \020\307\021\n\023\307\024\310\311!\211\307=\204\060", 
          constants = 137461325, 
          next = 0xbfffe614
        }
        top = 0xbfffe2a0
        result = -1230496548
#18 0x081f2c90 in funcall_lambda (fun=137461277, nargs=0, arg_vector=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3167
        val = 5
---Type <return> to continue, or q <return> to quit---
        syms_left = 0
        next = 136136817
        lexenv = -1073748504
        count = 4
        i = 2
        optional = 136278320
        rest = -1073748712
#19 0x081f2837 in Ffuncall (nargs=1, args=0xbfffe5d4)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3051
        fun = 137461277
        original_fun = 139710434
        funcar = 228
        numargs = 0
        lisp_numargs = -1073748552
        val = 142874461
        backtrace = {
---Type <return> to continue, or q <return> to quit---
          next = 0xbfffe928, 
          function = 0xbfffe5d4, 
          args = 0xbfffe5d8, 
          nargs = 0, 
          debug_on_exit = 0
        }
        internal_args = 0x40
        i = 0
#20 0x08230c84 in exec_byte_code (bytestr=137458513, vector=137458533, 
    maxdepth=32, args_template=0, nargs=0, args=0xbfffe830)
    at /data/steve/bzr/emacs/quickfixes/src/bytecode.c:785
        count = 3
        op = 0
        vectorp = 0x8317368
        stack = {
          pc = 
---Type <return> to continue, or q <return> to quit---
    0x84382c0 "\210)\210\346\347\350\"\210\351\317\352\"\211;\203\240", 
          byte_string = 137458513, 
          byte_string_start = 0x8438239 "\b\203\b", 
          constants = 137458533, 
          next = 0x0
        }
        top = 0xbfffe5d4
        result = 33554559
#21 0x081f2c90 in funcall_lambda (fun=137458485, nargs=0, arg_vector=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3167
        val = -1073747824
        syms_left = 0
        next = 19
        lexenv = 1952803683
        count = 3
        i = 1869819748
---Type <return> to continue, or q <return> to quit---
        optional = 1668509231
        rest = 1853190703
#22 0x081f2aca in apply_lambda (fun=137458485, args=139210986)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:3110
        args_left = 139210986
        i = 0
        numargs = 0
        arg_vector = 0xbfffe830
        gcpro1 = {
          next = 0x110019, 
          var = 0x2, 
          nvars = 0
        }
        gcpro2 = {
          next = 0x12, 
          var = 0x4000, 
---Type <return> to continue, or q <return> to quit---
          nvars = 7
        }
        gcpro3 = {
          next = 0xb6b18191, 
          var = 0x7, 
          nvars = -1073747856
        }
        tem = -1073745968
        sa_count = 3
        sa_must_free = 0
#23 0x081f1657 in eval_sub (form=139413902)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:2395
        fun = 137458485
        val = 139210986
        original_fun = 139449002
        original_args = 139210986
---Type <return> to continue, or q <return> to quit---
        funcar = 0
        backtrace = {
          next = 0x0, 
          function = 0xbfffe940, 
          args = 0xbfffe830, 
          nargs = 0, 
          debug_on_exit = 0
        }
        gcpro1 = {
          next = 0x0, 
          var = 0x0, 
          nvars = -1073745968
        }
        gcpro2 = {
          next = 0x84a9008, 
          var = 0x84c30ea, 
---Type <return> to continue, or q <return> to quit---
          nvars = 139230736
        }
        gcpro3 = {
          next = 0x84c30ea, 
          var = 0xbfffe958, 
          nvars = 136161612
        }
#24 0x081f0efd in Feval (form=139413902, lexical=139210986)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:2204
        count = 2
#25 0x0816fe8d in top_level_2 ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:1168
No locals.
#26 0x081efda2 in internal_condition_case (bfun=0x816fe70 <top_level_2>, 
    handlers=139242018, hfun=0x816faca <cmd_error>)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:1515
---Type <return> to continue, or q <return> to quit---
        val = 134534884
        c = {
          tag = 139210986, 
          val = 139210986, 
          next = 0xbfffeb18, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {-1073745968, -1073746084, -1073746684, -1073747240, 
    -1111826081, 2140363312}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {3086979752, 3064016392, 36, 0, 0, 1, 3221220048, 
    3061047008, 0, 3087005928, 134550898, 134530308, 3065551346, 136564430, 0, 
    3221219984, 0, 0, 0, 0, 3064033000, 3066779744, 3221220292, 135838830, 2, 
    3221220164, 4294967295, 0, 3087003588, 3087005928, 1, 137156004}
              }
---Type <return> to continue, or q <return> to quit---
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 139242018, 
          var = 139210986, 
          chosen_clause = 134525140, 
          tag = 0xbfffea04, 
          next = 0x0
        }
---Type <return> to continue, or q <return> to quit---
#27 0x0816fec1 in top_level_1 (ignore=139210986)
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:1176
No locals.
#28 0x081ef874 in internal_catch (tag=139239994, func=0x816fe8f <top_level_1>, 
    arg=139210986) at /data/steve/bzr/emacs/quickfixes/src/eval.c:1272
        c = {
          tag = 139239994, 
          val = 139210986, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {-1073745968, -1073746084, -1073746684, -1073746968, 
    -1111547553, 2140793392}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {0 <repeats 12 times>, 3064459342, 0, 0, 0, 
---Type <return> to continue, or q <return> to quit---
    3064459342, 0, 0, 4, 139210986, 3221220328, 136161612, 138823144, 
    139210986, 139230736, 216, 9999, 3221221328, 138823144, 139230736, 
    138823144}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#29 0x0816fdf7 in command_loop ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:1131
No locals.
---Type <return> to continue, or q <return> to quit---
#30 0x0816f703 in recursive_edit_1 ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:758
        count = 1
        val = -1073746824
#31 0x0816f854 in Frecursive_edit ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:822
        count = 0
        buffer = 139210986
#32 0x0816dcd8 in main (argc=2, argv=0xbffff064)
    at /data/steve/bzr/emacs/quickfixes/src/emacs.c:1715
        dummy = 0
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
          rlim_cur = 8388608, 
---Type <return> to continue, or q <return> to quit---
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0

Lisp Backtrace:
"x-create-frame" (0xbfffd9b4)
"x-create-frame-with-faces" (0xbfffdca4)
"make-frame" (0xbfffdfa4)
"frame-initialize" (0xbfffe2a4)
"command-line" (0xbfffe5d8)
"normal-top-level" (0xbfffe830)

[-- Attachment #3: backtrace #2 --]
[-- Type: text/plain, Size: 34803 bytes --]

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

(gdb) bt full
#0  cancel_mouse_face (f=0x88a9188)                                             
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:27545                       
        window = 86                                                             
        hlinfo = 0xbfffed04                                                     
#1  0x08153539 in xg_update_scrollbar_pos (f=0x88a9188, scrollbar_id=0, top=0,  
    left=586, width=16, height=461)                                             
    at /data/steve/bzr/emacs/quickfixes/src/gtkutil.c:3597                      
        wparent = 0x8bd4818                                                     
        oldy = -1                                                               
        oldw = -1                                                               
        wfixed = 0x85efac0                                                      
        msl = 30                                                                
        oldx = -1                                                               
        oldh = -1                                                               
        wscroll = 0x8704140                                                     
#2  0x0811a59b in x_scroll_bar_create (w=0x88a9330, top=0, left=586, width=16,  
---Type <return> to continue, or q <return> to quit---                          
    height=461) at /data/steve/bzr/emacs/quickfixes/src/xterm.c:5012            
        f = 0x88a9188                                                           
        bar = 0x86d3710                                                         
#3  0x0811ac59 in XTset_vertical_scroll_bar (w=0x88a9330, portion=994, whole=   
    994, position=0) at /data/steve/bzr/emacs/quickfixes/src/xterm.c:5248       
        f = 0x88a9188                                                           
        bar = 0xffffffff                                                        
        top = 0                                                                 
        height = 461                                                            
        left = 581                                                              
        sb_left = 586                                                           
        width = 21                                                              
        sb_width = 16                                                           
        window_y = 0                                                            
        window_height = 461                                                     
        fringe_extended_p = 1                                                   
---Type <return> to continue, or q <return> to quit---                          
#4  0x0808d183 in set_vertical_scroll_bar (w=0x88a9330)                         
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:15047                       
        start = 0                                                               
        end = 994                                                               
        whole = 994                                                             
#5  0x0808f6cb in redisplay_window (window=143299381, just_this_one_p=0)        
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:15912                       
        w = 0x88a9330                                                           
        f = 0x88a9188                                                           
        buffer = 0x8a7ec48                                                      
        old = 0x8a7ec48                                                         
        lpoint = {                                                              
          charpos = 1,                                                          
          bytepos = 1                                                           
        }                                                                       
        opoint = {                                                              
---Type <return> to continue, or q <return> to quit---                          
          charpos = 1,                                                          
          bytepos = 1                                                           
        }
        startp = {
          charpos = 1, 
          bytepos = 1
        }
        update_mode_line = 1
        tem = 0
        it = {
          window = 139210986, 
          w = 0x86544b8, 
          f = 0xb6b84b20, 
          method = 3076496843, 
          stop_charpos = 140854460, 
          prev_stop = 137159580, 
---Type <return> to continue, or q <return> to quit---
          base_level_stop = 1, 
          end_charpos = 0, 
          s = 0xb76aeff4 "\204\236\017", 
          string_nchars = 0, 
          region_beg_charpos = -1073756168, 
          region_end_charpos = 134717556, 
          redisplay_end_trigger_charpos = -1073756000, 
          multibyte_p = 1, 
          header_line_p = 0, 
          string_from_display_prop_p = 0, 
          from_disp_prop_p = 0, 
          ellipsis_p = 0, 
          avoid_cursor_p = 0, 
          dp = 0x1, 
          dpvec = 0x0, 
          dpend = 0x86544b8, 
---Type <return> to continue, or q <return> to quit---
          dpvec_char_len = 0, 
          dpvec_face_id = -1229440368, 
          saved_face_id = 1, 
          ctl_chars = {448, 64, 1, 64, 143496304, 1, 1, 1, 0, 8, 0, 0, 0, 0, 
    448, 0}, 
          start = {
            pos = {
              charpos = 1, 
              bytepos = 0
            }, 
            overlay_string_index = 67, 
            string_pos = {
              charpos = 134689698, 
              bytepos = -1073756000
            }, 
            dpvec_index = 143299736
---Type <return> to continue, or q <return> to quit---
          }, 
          current = {
            pos = {
              charpos = 1, 
              bytepos = 1
            }, 
            overlay_string_index = 143496304, 
            string_pos = {
              charpos = 0, 
              bytepos = 0
            }, 
            dpvec_index = 0
          }, 
          n_overlay_strings = -1, 
          overlay_strings_charpos = 12, 
          overlay_strings = {0, 0, 1, 0, 143496304, 1, -1073746084, 
---Type <return> to continue, or q <return> to quit---
    -1073746684, -1073753784, 134805630, -1073756000, 143299736, 1, 1, 
    143299741, 143299736}, 
          string_overlays = {143298952, 0, 66, 0, 0, 66, 0, 0, -1, -1, 0, 0, 
    0, 0, 0, 0}, 
          string = 0, 
          from_overlay = 0, 
          stack = {{
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
---Type <return> to continue, or q <return> to quit---
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = 0, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 66, 
                to = 66, 
                width = -1
              }, 
              face_id = -1, 
              u = {
                image = {
                  object = -1, 
---Type <return> to continue, or q <return> to quit---
                  slice = {
                    x = -1, 
                    y = 66, 
                    width = 66, 
                    height = -1
                  }, 
                  image_id = -1
                }, 
                comp = {
                  object = -1
                }, 
                stretch = {
                  object = -1
                }
              }, 
              position = {
---Type <return> to continue, or q <return> to quit---
                charpos = -1, 
                bytepos = -1
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 66
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
---Type <return> to continue, or q <return> to quit---
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = 0, 
              string_from_display_prop_p = 0, 
              display_ellipsis_p = 0, 
              avoid_cursor_p = 0, 
              bidi_p = 0, 
              from_disp_prop_p = 0, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
---Type <return> to continue, or q <return> to quit---
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = 0, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
---Type <return> to continue, or q <return> to quit---
                to = 0, 
                width = 0
              }, 
              face_id = 139210986, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                comp = {
---Type <return> to continue, or q <return> to quit---
                  object = 0
                }, 
                stretch = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
---Type <return> to continue, or q <return> to quit---
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = 0, 
              string_from_display_prop_p = 0, 
              display_ellipsis_p = 0, 
              avoid_cursor_p = 0, 
              bidi_p = 0, 
              from_disp_prop_p = 0, 
---Type <return> to continue, or q <return> to quit---
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
---Type <return> to continue, or q <return> to quit---
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = 0, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
---Type <return> to continue, or q <return> to quit---
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                comp = {
                  object = 0
                }, 
                stretch = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
---Type <return> to continue, or q <return> to quit---
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
---Type <return> to continue, or q <return> to quit---
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = 0, 
              string_from_display_prop_p = 0, 
              display_ellipsis_p = 0, 
              avoid_cursor_p = 0, 
              bidi_p = 0, 
              from_disp_prop_p = 0, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
---Type <return> to continue, or q <return> to quit---
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
                reversed_p = 0, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
---Type <return> to continue, or q <return> to quit---
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
                    height = 0
                  }, 
                  image_id = 0
                }, 
                comp = {
                  object = 0
                }, 
---Type <return> to continue, or q <return> to quit---
                stretch = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
---Type <return> to continue, or q <return> to quit---
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = 0, 
              string_from_display_prop_p = 0, 
              display_ellipsis_p = 0, 
              avoid_cursor_p = 0, 
              bidi_p = 0, 
              from_disp_prop_p = 0, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
---Type <return> to continue, or q <return> to quit---
              space_width = 0, 
              font_height = 0
            }, {
              string = 0, 
              string_nchars = 0, 
              end_charpos = 0, 
              stop_charpos = 0, 
              prev_stop = 0, 
              base_level_stop = 0, 
              cmp_it = {
                stop_pos = 0, 
                id = 0, 
                ch = 0, 
                rule_idx = 0, 
                lookback = 0, 
                nglyphs = 0, 
---Type <return> to continue, or q <return> to quit---
                reversed_p = 0, 
                charpos = 0, 
                nchars = 0, 
                nbytes = 0, 
                from = 0, 
                to = 0, 
                width = 0
              }, 
              face_id = 0, 
              u = {
                image = {
                  object = 0, 
                  slice = {
                    x = 0, 
                    y = 0, 
                    width = 0, 
---Type <return> to continue, or q <return> to quit---
                    height = 0
                  }, 
                  image_id = 0
                }, 
                comp = {
                  object = 0
                }, 
                stretch = {
                  object = 0
                }
              }, 
              position = {
                charpos = 0, 
                bytepos = 0
              }, 
              current = {
---Type <return> to continue, or q <return> to quit---
                pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                overlay_string_index = 0, 
                string_pos = {
                  charpos = 0, 
                  bytepos = 0
                }, 
                dpvec_index = 0
              }, 
              from_overlay = 0, 
              area = LEFT_MARGIN_AREA, 
              method = GET_FROM_BUFFER, 
              paragraph_embedding = NEUTRAL_DIR, 
              multibyte_p = 0, 
---Type <return> to continue, or q <return> to quit---
              string_from_display_prop_p = 0, 
              display_ellipsis_p = 0, 
              avoid_cursor_p = 0, 
              bidi_p = 0, 
              from_disp_prop_p = 0, 
              line_wrap = TRUNCATE, 
              voffset = 0, 
              space_width = 0, 
              font_height = 0
            }}, 
          sp = 0, 
          selective = 0, 
          what = IT_CHARACTER, 
          face_id = 0, 
          selective_display_ellipsis_p = 0, 
          ctl_arrow_p = 0, 
---Type <return> to continue, or q <return> to quit---
          face_box_p = 0, 
          start_of_box_run_p = 0, 
          end_of_box_run_p = 0, 
          overlay_strings_at_end_processed_p = 0, 
          ignore_overlay_strings_at_pos_p = 0, 
          glyph_not_available_p = 0, 
          starts_in_middle_of_char_p = 0, 
          face_before_selective_p = 0, 
          constrain_row_ascent_descent_p = 0, 
          line_wrap = TRUNCATE, 
          base_face_id = 0, 
          c = 0, 
          len = 0, 
          cmp_it = {
            stop_pos = 0, 
            id = 0, 
---Type <return> to continue, or q <return> to quit---
            ch = 0, 
            rule_idx = 0, 
            lookback = 0, 
            nglyphs = 0, 
            reversed_p = 0, 
            charpos = 0, 
            nchars = 0, 
            nbytes = 0, 
            from = 0, 
            to = 0, 
            width = 0
          }, 
          char_to_display = 0, 
          glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, 
          image_id = 0, 
          slice = {
---Type <return> to continue, or q <return> to quit---
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          space_width = 0, 
          voffset = 0, 
          tab_width = 0, 
          font_height = 0, 
          object = 0, 
          position = {
            charpos = 0, 
            bytepos = 0
          }, 
          truncation_pixel_width = 0, 
          continuation_pixel_width = 0, 
---Type <return> to continue, or q <return> to quit---
          first_visible_x = 0, 
          last_visible_x = 0, 
          last_visible_y = 0, 
          extra_line_spacing = 0, 
          max_extra_line_spacing = 0, 
          override_ascent = 0, 
          override_descent = 0, 
          override_boff = 0, 
          glyph_row = 0x0, 
          area = LEFT_MARGIN_AREA, 
          nglyphs = 0, 
          pixel_width = 0, 
          ascent = 0, 
          descent = 0, 
          max_ascent = 0, 
          max_descent = 0, 
---Type <return> to continue, or q <return> to quit---
          phys_ascent = 0, 
          phys_descent = 0, 
          max_phys_ascent = 0, 
          max_phys_descent = 0, 
          current_x = 0, 
          continuation_lines_width = 0, 
          eol_pos = {
            charpos = 0, 
            bytepos = 0
          }, 
          current_y = 0, 
          first_vpos = 0, 
          vpos = 0, 
          hpos = 0, 
          left_user_fringe_bitmap = 0, 
          right_user_fringe_bitmap = 0, 
---Type <return> to continue, or q <return> to quit---
          left_user_fringe_face_id = 0, 
          right_user_fringe_face_id = 5, 
          bidi_p = 0, 
          bidi_it = {
            bytepos = 0, 
            charpos = 35, 
            ch = 2, 
            nchars = 0, 
            ch_len = 46, 
            type = STRONG_L, 
            type_after_w1 = 66, 
            orig_type = 4294967295, 
            resolved_level = -2, 
            invalid_levels = 0, 
            invalid_rl_levels = 0, 
            prev_was_pdf = 0, 
---Type <return> to continue, or q <return> to quit---
            prev = {
              bytepos = 0, 
              charpos = 0, 
              type = UNKNOWN_BT, 
              type_after_w1 = UNKNOWN_BT, 
              orig_type = UNKNOWN_BT
            }, 
            last_strong = {
              bytepos = 0, 
              charpos = 0, 
              type = 46, 
              type_after_w1 = UNKNOWN_BT, 
              orig_type = UNKNOWN_BT
            }, 
            next_for_neutral = {
              bytepos = 139210986, 
---Type <return> to continue, or q <return> to quit---
              charpos = 139210986, 
              type = 139210986, 
              type_after_w1 = 139210986, 
              orig_type = 139210986
            }, 
            prev_for_neutral = {
              bytepos = 524288, 
              charpos = 139210986, 
              type = 144902061, 
              type_after_w1 = 66, 
              orig_type = 66
            }, 
            next_for_ws = {
              bytepos = 0, 
              charpos = 0, 
              type = 560, 
---Type <return> to continue, or q <return> to quit---
              type_after_w1 = WEAK_ET, 
              orig_type = UNKNOWN_BT
            }, 
            next_en_pos = 0, 
            next_en_type = 4294967295, 
            ignore_bn_limit = 0, 
            sor = NEUTRAL_DIR, 
            scan_dir = 143496476, 
            disp_pos = 1, 
            disp_prop = 1, 
            stack_idx = 7, 
            level_stack = {{
                level = 11, 
                override = 3
              }, {
                level = 0, 
---Type <return> to continue, or q <return> to quit---
                override = NEUTRAL_DIR
              }, {
                level = 0, 
                override = NEUTRAL_DIR
              }, {
                level = 0, 
                override = NEUTRAL_DIR
              }, {
                level = 0, 
                override = NEUTRAL_DIR
              }, {
                level = 0, 
                override = NEUTRAL_DIR
              }, {
                level = 14, 
                override = NEUTRAL_DIR
---Type <return> to continue, or q <return> to quit---
              }, {
                level = 1, 
                override = NEUTRAL_DIR
              }, {
                level = 0, 
                override = NEUTRAL_DIR
              } <repeats 56 times>}, 
            string = {
              lstring = 0, 
              s = 0x0, 
              schars = 0, 
              bufpos = 0, 
              from_disp_str = 0, 
              unibyte = 0
            }, 
            paragraph_dir = NEUTRAL_DIR, 
---Type <return> to continue, or q <return> to quit---
            separator_limit = 0, 
            first_elt = 0, 
            new_paragraph = 0, 
            frame_window_p = 0
          }, 
          paragraph_embedding = NEUTRAL_DIR
        }
        current_matrix_up_to_date_p = 0
        used_current_matrix_p = 0
        buffer_unchanged_p = 0
        temp_scroll_step = 0
        count = 4
        rc = 0
        centering_position = -1
        last_line_misfit = 0
        beg_unchanged = 0
---Type <return> to continue, or q <return> to quit---
        end_unchanged = 0
#6  0x08089852 in redisplay_window_0 (window=143299381)
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13619
No locals.
#7  0x081efeae in internal_condition_case_1 (bfun=
    0x808981f <redisplay_window_0>, arg=143299381, handlers=139193110, hfun=
    0x80897fe <redisplay_window_error>)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:1553
        val = 134759425
        c = {
          tag = 139210986, 
          val = 139210986, 
          next = 0xbfffea04, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {64, -1073746084, -1073746684, -1073753576, 
---Type <return> to continue, or q <return> to quit---
    -1110744737, 2140513840}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {139247634, 1600000, 139302386, 139210986, 64, 64, 
    3221213640, 139247634, 1600000, 0, 0, 0, 139247634, 2147483644, 0, 
    144902061, 5, 0, 1, 139210986, 145222728, 139210986, 3221213704, 
    134755108, 4, 139210986, 134755113, 143299736, 139210986, 0, 0, 136160439}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0xbfffe9f0, 
          lisp_eval_depth = 0, 
          pdlcount = 4, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
---Type <return> to continue, or q <return> to quit---
        }
        h = {
          handler = 139193110, 
          var = 139210986, 
          chosen_clause = 143496144, 
          tag = 0xbfffd144, 
          next = 0xbfffe9f0
        }
#8  0x080897e5 in redisplay_windows (window=143299381)
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13599
        w = 0x88a9330
#9  0x08088ad4 in redisplay_internal ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:13176
        f = 0x88a9188
        tail = 139905694
        frame = 143298957
---Type <return> to continue, or q <return> to quit---
        w = 0x88a9330
        sw = 0x88a9330
        fr = 0x88a9188
        pending = 0
        must_finish = 1
        tlbufpos = {
          charpos = 0, 
          bytepos = 0
        }
        tlendpos = {
          charpos = 0, 
          bytepos = 0
        }
        number_of_visible_frames = 1
        count = 2
        count1 = 4
---Type <return> to continue, or q <return> to quit---
        sf = 0x88a9188
        polling_stopped_here = 0
        old_frame = 143298957
        consider_all_windows_p = 1
#10 0x08086e7e in redisplay ()
    at /data/steve/bzr/emacs/quickfixes/src/xdisp.c:12399
No locals.
#11 0x08171f95 in read_char (commandflag=1, nmaps=2, maps=0xbfffe6d0, 
    prev_event=139210986, used_mouse_menu=0xbfffe7a8, end_time=0x0)
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:2446
        echo_current = 0
        c = 139210986
        jmpcount = 139686784
        local_getcjmp = {{
            __jmpbuf = {234, 140309467, 139210986, 0, 1, 0}, 
            __mask_was_saved = 139233194, 
---Type <return> to continue, or q <return> to quit---
            __saved_mask = {
              __val = {3221218952, 136191581, 139233194, 4, 145222733, 
    0 <repeats 27 times>}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, -1, 0, 0, 0}, 
            __mask_was_saved = 1, 
            __saved_mask = {
              __val = {1, 139233194, 1, 3221218584, 136617525, 139233194, 
    139210986, 0, 1, 3, 455, 0, 139233194, 1, 3221220612, 3221218616, 
    136617352, 139210986, 139233194, 1, 0, 139233194, 1, 3221218680, 
    136637971, 139233194, 139210986, 0, 16, 0, 220, 140309443}
            }
          }}
        key_already_recorded = 0
---Type <return> to continue, or q <return> to quit---
        tem = 139951008
        save = 139686784
        previous_echo_area_message = 139210986
        also_record = 139210986
        reread = 0
        gcpro1 = {
          next = 0x8a307ad, 
          var = 0x42, 
          nvars = 66
        }
        gcpro2 = {
          next = 0x84c30ea, 
          var = 0x80000, 
          nvars = 139210986
        }
        polling_stopped_here = 0
---Type <return> to continue, or q <return> to quit---
        orig_kboard = 0x8703960
#12 0x0817d1c6 in read_key_sequence (keybuf=0xbfffe924, bufsize=30, prompt=
    139210986, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1)
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:9326
        interrupted_kboard = 0x8703960
        interrupted_frame = 0x88a9188
        key = 139210986
        used_mouse_menu = 0
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        local_first_binding = 0
        from_string = 139210986
        count = 2
        t = 0
---Type <return> to continue, or q <return> to quit---
        echo_start = 0
        keys_start = 0
        nmaps = 2
        nmaps_allocated = 2
        defs = 0xbfffe6b0
        submaps = 0xbfffe6d0
        orig_local_map = 139818654
        orig_keymap = 139210986
        localized_local_map = 0
        first_binding = 0
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = 142488054, 
          map = 142488054, 
          start = 0, 
---Type <return> to continue, or q <return> to quit---
          end = 0
        }
        keytran = {
          parent = 139198150, 
          map = 139198150, 
          start = 0, 
          end = 0
        }
        indec = {
          parent = 142488070, 
          map = 142488070, 
          start = 0, 
          end = 0
        }
        shift_translated = 0
        delayed_switch_frame = 139210986
---Type <return> to continue, or q <return> to quit---
        original_uppercase = 2
        original_uppercase_position = -1
        dummyflag = 0
        starting_buffer = 0x8a7ec48
        fake_prefixed_keys = 139210986
        gcpro1 = {
          next = 0x8a7ec48, 
          var = 0xbfffed04, 
          nvars = -1073748008
        }
#13 0x0817045d in command_loop_1 ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:1448
        cmd = -1228187552
        keybuf = {-1073745968, -1073747576, 136262947, 139281698, 139210986, 
    0, 139210986, 139449002, 0, -1230934296, 139281698, 139210986, 0, 0, 
    136262494, 139281698, 139210986, 139422558, 137458485, 41, 139210986, 
---Type <return> to continue, or q <return> to quit---
    -1208055868, 139210986, -1073746084, -1073746684, -1073747528, 136253196, 
    2, 139422558, -1472036457}
        i = -1073747496
        prev_modiff = 0
        prev_buffer = 0x0
        already_adjusted = 0
#14 0x081efda2 in internal_condition_case (bfun=0x8170109 <command_loop_1>, 
    handlers=139242018, hfun=0x816faca <cmd_error>)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:1515
        val = 139422558
        c = {
          tag = 139210986, 
          val = 139210986, 
          next = 0xbfffeb18, 
          gcpro = 0x0, 
          jmp = {{
---Type <return> to continue, or q <return> to quit---
              __jmpbuf = {-1073745968, -1073746084, -1073746684, -1073747240, 
    -1111826081, 2140363312}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {3086979752, 3064016392, 36, 0, 0, 1, 3221220048, 
    3061047008, 0, 3087005928, 134550898, 134530308, 3065551346, 136564430, 0, 
    3221219984, 0, 0, 0, 0, 3064033000, 3066779744, 3221220292, 135838830, 2, 
    3221220164, 4294967295, 0, 3087003588, 3087005928, 1, 137156004}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
---Type <return> to continue, or q <return> to quit---
          byte_stack = 0x0
        }
        h = {
          handler = 139242018, 
          var = 139210986, 
          chosen_clause = 134525140, 
          tag = 0xbfffea04, 
          next = 0x0
        }
#15 0x0816fe5a in command_loop_2 (ignore=139210986)
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:1159
        val = -1073745968
#16 0x081ef874 in internal_catch (tag=139239994, func=
    0x816fe36 <command_loop_2>, arg=139210986)
    at /data/steve/bzr/emacs/quickfixes/src/eval.c:1272
        c = {
---Type <return> to continue, or q <return> to quit---
          tag = 139239994, 
          val = 139210986, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {-1073745968, -1073746084, -1073746684, -1073746968, 
    -1111547553, 2140793392}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {0 <repeats 12 times>, 3064459342, 0, 0, 0, 
    3064459342, 0, 0, 4, 139210986, 3221220328, 136161612, 138823144, 
    139210986, 139230736, 216, 9999, 3221221328, 138823144, 139230736, 
    138823144}
              }
            }}, 
          backlist = 0x0, 
---Type <return> to continue, or q <return> to quit---
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#17 0x0816fe16 in command_loop ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:1138
No locals.
#18 0x0816f703 in recursive_edit_1 ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:758
        count = 1
        val = -1073746824
#19 0x0816f854 in Frecursive_edit ()
    at /data/steve/bzr/emacs/quickfixes/src/keyboard.c:822
---Type <return> to continue, or q <return> to quit---
        count = 0
        buffer = 139210986
#20 0x0816dcd8 in main (argc=2, argv=0xbffff064)
    at /data/steve/bzr/emacs/quickfixes/src/emacs.c:1715
        dummy = 0
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
          rlim_cur = 8388608, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: cyd@gnu.org,  7464@debbugs.gnu.org
> Date: Sat, 31 Mar 2012 16:01:19 +0200
> 
> On Sat, 31 Mar 2012 08:56:00 +0300 Eli Zaretskii <eliz@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.

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

[Jan D.]

Hello.

Eli Zaretskii skrev 2012-03-29 20:47:
>> From: Stephen Berman<stephen.berman@gmx.net>
>> Cc: cyd@gnu.org,  7464@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.

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

[Eli Zaretskii]

> Date: Fri, 30 Mar 2012 09:43:52 +0200
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: Stephen Berman <stephen.berman@gmx.net>, cyd@gnu.org, 
>  7464@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.

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

[Stephen Berman]

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

>> Date: Fri, 30 Mar 2012 09:43:52 +0200
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: Stephen Berman <stephen.berman@gmx.net>, cyd@gnu.org, 
>>  7464@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: "Jan D." <jan.h.d@swipnet.se>,  cyd@gnu.org,  7464@debbugs.gnu.org
> Date: Fri, 30 Mar 2012 10:45:13 +0200
> 
> On Fri, 30 Mar 2012 11:00:49 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> Date: Fri, 30 Mar 2012 09:43:52 +0200
> >> From: "Jan D." <jan.h.d@swipnet.se>
> >> CC: Stephen Berman <stephen.berman@gmx.net>, cyd@gnu.org, 
> >>  7464@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.

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

[Jan Djärv]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: "Jan D." <jan.h.d@swipnet.se>,  cyd@gnu.org,  7464@debbugs.gnu.org
>> Date: Fri, 30 Mar 2012 10:45:13 +0200
>> 
>> On Fri, 30 Mar 2012 11:00:49 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>>> Date: Fri, 30 Mar 2012 09:43:52 +0200
>>>> From: "Jan D." <jan.h.d@swipnet.se>
>>>> CC: Stephen Berman <stephen.berman@gmx.net>, cyd@gnu.org, 
>>>> 7464@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.

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

[Stefan Monnier]

> 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

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

[martin rudalics]

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

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

[Eli Zaretskii]

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