[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 11:10:31 +0300 |
> Date: Fri, 10 Jun 2016 09:16:02 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, 23574@debbugs.gnu.org,
> john.b.mastro@gmail.com, cwoodbury@azavea.com
>
> >> Suppose a user wants to use the same background for all spaces at the
> >> ends of all lines of a buffer regardless of "the last face used on the
> >> line". How would she specify that?
> >
> > By putting the proper face property on the newline.
>
> 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.
> A loosely related question: Does for R2L text row->pixel_width for each
> glyph row indicate the width of that row occupied by text as it does for
> L2R text?
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. In the R2L case the width includes the stretch glyph
prepended on the left.
> Suppose we have a L2R line with dots indicating the empty space at
> the end of that line:
>
> TTTTTTTTTTTTT....
>
> R2L this line would appear as
>
> ....TTTTTTTTTTTTT
>
> Would these two lines have the same row->pixel_width? Or, would the
> length of the stretch glyph added at the left of the R2L line be that of
> ‘window-text-width’ minus row->pixel_width?
The latter. 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.
- bug#23574: 24.5; Overzealous underlining in emacs-nox, (continued)
- bug#23574: 24.5; Overzealous underlining in emacs-nox, Eli Zaretskii, 2016/06/06
- bug#23574: 24.5; Overzealous underlining in emacs-nox, martin rudalics, 2016/06/07
- bug#23574: 24.5; Overzealous underlining in emacs-nox, Eli Zaretskii, 2016/06/07
- bug#23574: 24.5; Overzealous underlining in emacs-nox, martin rudalics, 2016/06/08
- bug#23574: 24.5; Overzealous underlining in emacs-nox, Eli Zaretskii, 2016/06/08
- bug#23574: 24.5; Overzealous underlining in emacs-nox, martin rudalics, 2016/06/09
- bug#23574: 24.5; Overzealous underlining in emacs-nox, Eli Zaretskii, 2016/06/09
- bug#23574: 24.5; Overzealous underlining in emacs-nox, martin rudalics, 2016/06/10
- bug#23574: 24.5; Overzealous underlining in emacs-nox,
Eli Zaretskii <=
- bug#23574: 24.5; Overzealous underlining in emacs-nox, martin rudalics, 2016/06/10
- bug#23574: 24.5; Overzealous underlining in emacs-nox, Eli Zaretskii, 2016/06/10
- bug#23574: 24.5; Overzealous underlining in emacs-nox, martin rudalics, 2016/06/10
- bug#23574: 24.5; Overzealous underlining in emacs-nox, Eli Zaretskii, 2016/06/10