GNU bug report logs - #9149
24.0.50; regression on mouse-face for completions

Previous Next

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

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

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; regression on mouse-face for completions
Date: Fri, 22 Jul 2011 07:56:56 -0700

This bug seems to have been introduced between the published Windows
builds of 2010-10-19 (no bug) and 2010-10-25 (bug).  I tried to examine
changes made to the sources during that week, but didn't see anything
super obvious as the cause.
 
What might have introduced the bug was this change (just a guess):
 
Eli Zaretskii2010-10-23 15:30:45(101157.1.16 test)
Revision ID: eliz <at> gnu.org-20101023153045-9zcud9tw7y2p7b3a
 
Implement mouse highlight for bidi-reordered lines.
 
 xdisp.c (fast_find_string_pos): #ifdef away, not used anymore.
 (mouse_face_from_string_pos): New function, replaces
 fast_find_string_pos.
 (note_mouse_highlight): Call it instead of fast_find_string_pos.
 (note_mode_line_or_margin_highlight): Support bidi-reordered
 strings and R2L glyph rows.  Fix comments.
 (note_mouse_highlight): When bidi reordering is turned on in a
 buffer, call next-single-property-change and
 previous-single-property-change with last argument nil.  Clear
 mouse highlight when mouse pointer is in a R2L row on the stretch
 glyph that stands for no text beyond the line end.
 (row_containing_pos): Don't return too early when CHARPOS is in a
 bidi-reordered continued line.  Return immediately when the first
 hit is found in a line that is not continued, or when an exact
 match for CHARPOS is found.
 (rows_from_pos_range): New function.
 (mouse_face_from_buffer_pos): Use it instead of calling
 row_containing_pos for START_CHARPOS and END_CHARPOS.  Rewrite the
 function to support mouse highlight in bidi-reordered lines and
 not to assume that START_CHARPOS is always in mouse_face_beg_row.
 If necessary, swap mouse_face_beg_row and mouse_face_end_row so
 that the former is always above the latter or identical to it.
 (show_mouse_face): Support drawing highlighted R2L lines.
 (coords_in_mouse_face_p): New function, bidi-aware.
 (cursor_in_mouse_face_p, note_mouse_highlight, erase_phys_cursor):
 Call it instead of comparing with mouse-face members of dpyinfo.
 (note_mode_line_or_margin_highlight): Fix confusingly swapped
 usage of hpos and vpos.
files modified: src/ChangeLog src/xdisp.c 
 
The bug is that the `mouse-face' highlighting is not applied to an
entire completion candidate, if that candidate is multiline and it
contains an empty line.  What happens is that the `mouse-face'
highlighting stops as soon as the empty line (i.e., \n$) is
encountered.  The rest of the text of the candidate does not have the
`mouse-face' highlighting.
 
Here's a recipe to reproduce the problem:
 
emacs -Q
 
Evaluate this code:
 
(setq foo '(("abcdefgh
ijklmn
 
opqrst
uvwxyz
 
abcde")
("123456
7890123
 
45678
9012345
 

678901
23456")))
 
(completing-read "ff: " foo)
 
When you evaluate the `completing-read' call, move the mouse pointer
over the two candidates in *Completions*.  Each candidate should be
completely `mouse-face' highlighted, but is not.  The highlighting of
each candidate stops as soon as the first blank line within the
candidate is encountered.

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-07-18 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 9149-done <at> debbugs.gnu.org
Subject: Re: bug#9149: 24.0.50; regression on mouse-face for completions
Date: Fri, 22 Jul 2011 20:45:46 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Fri, 22 Jul 2011 07:56:56 -0700
> 
> This bug seems to have been introduced between the published Windows
> builds of 2010-10-19 (no bug) and 2010-10-25 (bug).  I tried to examine
> changes made to the sources during that week, but didn't see anything
> super obvious as the cause.
>  
> What might have introduced the bug was this change (just a guess):
>  
> Eli Zaretskii2010-10-23 15:30:45(101157.1.16 test)
> Revision ID: eliz <at> gnu.org-20101023153045-9zcud9tw7y2p7b3a
>  
> Implement mouse highlight for bidi-reordered lines.

Yes, it was my fault.  Should be fixed now.  Thanks for the test case.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 9149-done <at> debbugs.gnu.org
Subject: RE: bug#9149: 24.0.50; regression on mouse-face for completions
Date: Fri, 22 Jul 2011 10:55:17 -0700

That was quick. Thank you.

Previous Next

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