Re: bug#129: Mouse highlighting fails for font sizes.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> At some point, the Unicode-2 branch redisplay was changed to allow
>> mouse-highlighted text to have a different font size from the
>> unhighlighted characters.  Unfortunately, this doesn't mesh well with
>> the existing code in note_mouse_highlight, which assumes the highlighted
>> glyphs overlap exactly with unhighlighted glyphs.
>> 
>> (defface foo-face
>> '((t :height 1.5))
>> "Face")
>> 
>> (defface bar-face
>> '((t :height 1.0))
>> "Face")
>> 
>> (defun foo-test ()
>> (interactive)
>> (switch-to-buffer "*Test*")
>> (erase-buffer)
>> (insert "Copying Conditions")
>> (put-text-property (point-min) (point-max) 'face 'foo-face)
>> (put-text-property (point-min) (point-max) 'mouse-face '(bar-face highlight)))

> After thinking some more, I think it's problematic to let
> mouse-highlighted text differ in size from the unhighlighted characters.
> Even if we fix the redisplay engine to correctly update the glyph row in
> such situations, there's the problem of how to decide when to perform
> highlighting.

> Consider a buffer containing the letters "A B" in a big font, which I
> schematically depict as

>  -A- -B-

> Suppose the letter A has a mouse highlight face that contains a small
> font.  So if we put the cursor over it, in the position marked ^, we see

>  A -B-
>  ^

> Now, move the cursor slightly to the right, so that it moves off the
> highlighted A:

>  A -B-
>   ^

> The highlighting disappears, and we see

>  -A- -B-
>   ^

> But the mouse is now again on the letter A, which means we need to
> highlight!

> Is the benefit of allowing a different-sized mouse-face significant?  If
> not, I propose imposing (or restoring) the restricting that only the
> foreground-color and background-color of the mouse-face takes effect;
> all other properties are ignored, and taken from the underlying face.

> What do you think?

I think resizing on mouse-movement is a bad idea indeed (for the
meta-stable problem you mention above, for other technical reasons, as
well as for purely aesthetic reasons).
But restricting "same size properties" for mouse-face is problematic as
well: we may want to use boldness for highlighting but it's not
guaranteed to preserve the size.  It's more restrictive than necessary.

So the best idea I can come up with is: don't restrict the face, but
when highlighting, don't change the size of the box in which the text
is drawn.  This works perfectly for changes that preserve the size, it
works fine for changes that reduce the size (the reduced-size text is
just surrounded with more whitespace than necessary, but the user won't
be surprised).  It doesn't work well if the size is increased (you get
clipping), but there's not much we can do in that case anyway, so it's
probably OK.

Of course, I have no idea how easy it'd be to implement that.
So maybe in the short term it's best to simply rule out size-changes.

Another problem with the mouse-highlighting is the flickering we get
whenever we redisplay: because the mouse-highlighting is done outside of
the main redisplay, it needs to be undone before redisplay and
re-applied afterwards.  This is problematic when you have a timer
changing the display every second.


        Stefan