bug#9149: 24.0.50; regression on mouse-face for completions

["Drew Adams" <drew.adams@oracle.com>]

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