bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#23574: 24.5; Overzealous underlining in emacs-nox


From: Eli Zaretskii
Subject: bug#23574: 24.5; Overzealous underlining in emacs-nox
Date: Fri, 10 Jun 2016 12:50:33 +0300

> Date: Fri, 10 Jun 2016 10:24:30 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, 23574@debbugs.gnu.org, 
>  john.b.mastro@gmail.com, cwoodbury@azavea.com
> 
>  >> Which gets me back to my initial concern: If our user does that eagerly
>  >> for the entire buffer, the overhead might be non-negligible.
>  >
>  > I don't see why.  Redisplay only considers the visible portion of the
>  > buffer.
> 
> I meant the overhead for adding the text property to every newline
> character in the buffer.

You mean, memory overhead?  I don't think it's significant.

>  > row->pixel_width doesn't count text glyphs, it counts all of the
>  > glyphs in a glyph row, including the glyphs produced by the display
>  > engine for its own purposes.  E.g., it always includes the space glyph
>  > produced at the end of a line, which is needed for displaying the
>  > cursor.
> 
> Are there any other significant objects but that space glyph?

Yes, a few.  Look at the comments at the beginning of 'struct glyph'
definition in dispextern.h.

> Is there any other way to get the size of the empty space after text
> on each row?

"Other way"? other than what?

>  > row->pixel_width is computed in compute_line_metrics,
>  > after the stretch glyph (and any other glyphs needed for line display)
>  > were already inserted.  compute_line_metrics doesn't care about what
>  > glyphs are there, it counts them all.
> 
> Hmm... How would I get the width of that stretch glyph then?

It's recorded in the glyph's pixel_width.  Or maybe I don't understand
the problem you are trying to solve.





reply via email to

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