From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window Date: Fri, 30 Mar 2012 12:10:05 +0300 Message-ID: <8362dm1mky.fsf@gnu.org> References: <877hg5l828.fsf@escher.home> <8362vp9rci.fsf@gnu.org> <83y68l88xd.fsf@gnu.org> <87sjh12a0d.fsf@gnu.org> <871uolhmdx.fsf@escher.home> <83d381u9xy.fsf@gnu.org> <87limpoenv.fsf@escher.home> <83vclts5aq.fsf@gnu.org> <87pqc0bzyp.fsf@escher.home> <83mx70imgh.fsf@gnu.org> <874nt7hm9q.fsf@escher.home> <83r4wb1byq.fsf@gnu.org> <87ty173tkt.fsf@escher.home> <83limi1tq6.fsf@gnu.org> <87sjgqqxyz.fsf@escher.home> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1333098712 12913 80.91.229.3 (30 Mar 2012 09:11:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2012 09:11:52 +0000 (UTC) Cc: cyd@gnu.org, 7464@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 30 11:11:50 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SDXs5-0007p6-QO for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2012 11:11:49 +0200 Original-Received: from localhost ([::1]:60126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDXs5-0005Kz-4f for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2012 05:11:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDXrz-0005Jx-6D for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 05:11:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SDXrs-00049O-QO for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 05:11:42 -0400 Original-Received: from [140.186.70.43] (port=39224 helo=debbugs.gnu.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDXrs-00048e-NA for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 05:11:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SDYMI-0003jg-4n for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 05:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Mar 2012 09:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7464 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7464-submit@debbugs.gnu.org id=B7464.133310054914304 (code B ref 7464); Fri, 30 Mar 2012 09:43:02 +0000 Original-Received: (at 7464) by debbugs.gnu.org; 30 Mar 2012 09:42:29 +0000 Original-Received: from localhost ([127.0.0.1]:46056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SDYLl-0003ie-4N for submit@debbugs.gnu.org; Fri, 30 Mar 2012 05:42:29 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:59848) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SDYLH-0003he-Q4 for 7464@debbugs.gnu.org; Fri, 30 Mar 2012 05:42:27 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M1O00100XEVUV00@a-mtaout23.012.net.il> for 7464@debbugs.gnu.org; Fri, 30 Mar 2012 12:10:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.100.223]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1O001JJXGSSQ30@a-mtaout23.012.net.il>; Fri, 30 Mar 2012 12:10:05 +0300 (IDT) In-reply-to: <87sjgqqxyz.fsf@escher.home> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:58325 Archived-At: > From: Stephen Berman > 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.