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

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Mon, 22 Nov 2010 14:54:02 UTC

Severity: normal

Found in version 24.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#7464: closed (24.0.50; mouse highlighting vanishes upon
 unsplitting window)
Date: Sat, 31 Mar 2012 18:13:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Sat, 31 Mar 2012 21:12:39 +0300
with message-id <83hax4k5bc.fsf <at> gnu.org>
and subject line Re: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window
has caused the debbugs.gnu.org bug report #7464,
regarding 24.0.50; mouse highlighting vanishes upon unsplitting window
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
7464: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7464
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; mouse highlighting vanishes upon unsplitting window
Date: Mon, 22 Nov 2010 15:57:51 +0100
1. emacs -q
2. C-x 2
3. Put the mouse pointer over one of the links in the splash screen, so
that the link becomes highlighted.
4. C-x 1
=> The highlighting from step 3 disappears, although the mouse pointer
is still over the link.  If the cursor is moved onto the link, then the
character under the cursor shows highlighting again, and moving the
cursor within the link extends the highlighting.

This problem is reliably reproducible, also on earlier builds of Emacs
24 I have, but not on Emacs 23.1.91 (I don't have 23.2).

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

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


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

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

I'm therefore closing the bug.


This bug report was last modified 13 years and 54 days ago.

Previous Next


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