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

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

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> 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?

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

[Stefan Monnier]

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

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

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 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.

This might be doable by fixing the glyph size to its original
(unhighlighted) value.  I don't know if that violates assumptions made
in the redisplay code, which might be difficult to work out.

The trouble is that the result might end up looking hideous, and there's
no guarantee that it won't; that would be font-dependent.  While
restricting mouse-highlight to coloring is a little less flexible, we
know the result will look OK.

I think a size restriction is regrettable but unimportant.  Since mouse
highlighting takes place on graphical displays, colors can do the job of
"lighting up" the text, which is what mouse-face is for.

> 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.

I've noticed flickering of this sort with the new font backend: M-x info
moving the mouse through the info links causes the text to flicker.  It
doesn't happen when a non-fontconfig font is used, so maybe the new code
is doing something silly.

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

[Kenichi Handa]

In article <871w5dw445.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
> > 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.

That is just a bug, and I've already fixed it in my working
version.

---
Kenichi Handa
handa@ni.aist.go.jp