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

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

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


From: Stephen Berman
Subject: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window
Date: 31 Mar 2012 01:09:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

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





reply via email to

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