emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus


From: Stephen Berman
Subject: Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus
Date: Mon, 18 Feb 2008 01:36:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

On Sun, 17 Feb 2008 21:25:18 +0100 address@hidden (Johan Bockgård) wrote:

> Stephen Berman <address@hidden> writes:
>
>> I had also tried an italic Dejavu and it showed the problem but, as I
>> said, not with as many strings; here's a case in point:
>>
>> (progn (font-lock-mode 0)
>>   (insert (propertize "Re: 23.0.60" 'mouse-face 'highlight))
>>   (insert (propertize "Re: 23.0.60" 'face 'italic 'mouse-face 'highlight)))
>>
>> I see a gap in mouse-face highlighting when the cursor is over the
>> unitalicized "R" and "2" but not when it is over the italicized ones.
>> Do you see that too?  This seems contrary to you characterization of the
>> triggering conditions, i.e. characters that stick out of their box, but
>> I do not know the properties of the font nor understand the code you
>> pointed to, so maybe it is no contradiction.
>
> Well, when I try this I notice a problem with highlighting next to the
> cursor to the right of the R in the non-italic case and to the left of
> the 3 in the italic case.  (Going from unslanted to slanted makes the
> lower right of "R" extend less, while OTOH slanting "3" makes the lower
> curve protrude to the left.)  

It sounds likes like you're describing a subtle problem with the drawing
of the italic characters; perhaps, but I don't see any problem with
highlighting in the italicized text, while in the unitalicized test,
when the cursor is over the "R" the following "e" lacks mouse-face
highlighting, likewise with "3" when the cursor is over the "2".

Anyway, I have some additional observations:

- The highlighting gap only occurs with the filled box cursor-type, not
  with hollow, bar (not even with type '(bar . 10), which appears to
  have the same extent as the box cursor with 12 point Dejavu), or
  hbar.  However, with '(hbar . 8) and higher height values, putting the
  cursor over the first "R", which is at (point-min) does not show the
  highlighting gap, but then typing C-b or <left> does make the gap
  appear over the following "e".

- When I eval the above sexp (or just the unitalicized part) with 14
  point Dejavu, and then move the cursor from the end to the beginning,
  the gap appears over the "3" when the cursor is over the "2", and
  remains as the cursor continues to the left, until it is over the "R"
  at (point-min), and then there is a highlighting gap over the the "e"
  and the "3".  Now typing C-b or <left> eliminates the gap over the "3"
  (but the one over the "e" remains).  I do not see the double gap with
  12 point Dejavu.

- For kicks I tried the above sexp with the font settings you gave in
  your followup posting, i.e.: emacs -Q -xrm 'emacs*font: bitstream vera
  sans mono:pixelsize=17'.  With this, I see no highlighting gap with
  the unitalicized text (Bitstream Vera and Dejavu differ here), but the
  italicized text shows strange redisplay effects under mouse-face
  highlighting.  First, my system appears to lack an italicized 17 point
  Bitstream Vera Sans, and the italicized text is in 12 point.  When I
  put the mouse over the text to hightlight it, the italicized text
  loses its slant and also takes up much less horizontal space, as if
  condensed.  But when I start to move the cursor over the italicized
  (but under highlighting not italicized) text, then the original
  spacing replaces the condensed spacing character by character.

>                               I haven't examined the font in detail, but
> in any case `contains_overlapping_glyphs_p' is the relevant variable.

> The problem goes away if you add a `&& hl == DRAW_NORMAL_TEXT' test to
> the conditional below (but I don't think this fix is entirely right.)
>
>>> The responsible code is this part in `draw_glyphs':
>>>
>>>    /* If there are any glyphs with lbearing < 0 or rbearing > width in
>>>       the row, redraw some glyphs in front or following the glyph
>>>       strings built above.  */
>>>   if (head && !overlaps && row->contains_overlapping_glyphs_p)
>>>      {
>>>        ...
>>
>> How did you figure this out?  Do you just know the code well and realize
>> that draw_glyphs was involved, or did you arrive there by using gdb?  If
>> the latter, could you tell me how you did it?  That might help me make
>> more useful bug reports and perhaps even suggest bug fixes.
>
> Actually, I had already discovered another problem with precisely this
> code that I had been planning to report.  That one also involved display
> problems around the (box) cursor, which led me to x_draw_window_cursor
> -> draw_phys_cursor_glyph -> draw_glyphs (with hl=DRAW_CURSOR;
> similarly, mouse-face highlighting is produced by draw_glyphs with
> hl=DRAW_MOUSE_FACE).  (I was somewhat familiar with the box cursor
> drawing code, http://article.gmane.org/gmane.emacs.devel/81652.)  gdb
> helped revealing the difference between the working and non-working
> cases (contains_overlapping_glyphs_p).

Thanks for the details.

Steve Berman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]