bug#19872: 24.4; UTF8 characters of unusual width (Gnus markers)

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Sebastien Vauban <sva-news@mygooglest.com>, 19872@debbugs.gnu.org
> Date: Tue, 17 Feb 2015 15:17:28 +1100
> 
> Using align-to in the summary buffer wouldn't help much directly,
> because Gnus also has to limit the width of the strings.

No, you just need to place the display property on the first character
that exceeds the width limit.

> That can be done with vertical-motion and stuff, but would make
> generating the buffer slow.

I don't see why would you need to do all that.  First, you already do
these calculations, to know how many blanks to insert, right?  So you
already know whether a string is too long, at least in terms of
characters, right?  And :align-to can work in character units as well
as in pixels.

And second, AFAIU you are talking about an additional feature.  The OP
presented a use case where no string is too long, AFAICT.  So it would
get you bonus points to handle long strings as well, but that's not
what this bug report is about: the same problem exists with the
current "alignment" using whitespace, right?

> If Emacs had a version of align-to that really aligned to the specified
> pixel position, even if the text displayed there is wider than that
> position, then that would be nice.
> 
> (That is, it would have to truncate the text if it's too wide.)

The things people expect the display engine to do...

I think it would be wrong for the display engine to automatically
truncate text in this case, since there's also the use case where the
alignment is only meant to be in effect when preceding text is not
long enough, similar to minimum width specification in formatted
output.