GNU bug report logs - #23574
24.5; Overzealous underlining in emacs-nox

Previous Next

Package: emacs;

Reported by: Colin Woodbury <cwoodbury <at> azavea.com>

Date: Wed, 18 May 2016 17:11:01 UTC

Severity: normal

Tags: notabug

Found in version 24.5

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23574 <at> debbugs.gnu.org, john.b.mastro <at> gmail.com, cwoodbury <at> azavea.com, npostavs <at> users.sourceforge.net
Subject: bug#23574: 24.5; Overzealous underlining in emacs-nox
Date: Fri, 10 Jun 2016 10:24:30 +0200
>> 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.

> 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?  Is there
any other way to get the size of the empty space after text on each row?

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

martin




This bug report was last modified 3 years and 192 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.