bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org
> Date: Fri, 28 Jul 2023 08:06:54 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Using :align-to space spec and font-lock-keywords.
> >> This can work, although it is unfortunate that there is no "stretch"
> >> space that will automatically occupy as much space as possible without
> >> pushing the line across right fringe.
> >
> > Of course, there is: use the 'right' position with a negative offset.
> 
> This indeed works, but the annoying part is calculating the offset.

What offset?  You said "occupy as much space as possible", which means
the offset from the right edge is zero, right?

> The most robust way would be delegating offset calculation to the
> redisplay of the actual line being displayed.

That would require that the display engine scans the screen line
twice.  That's unacceptable, both for performance reasons and because
it violates the basic design of how the Emacs display iteration works.
Sorry, that won't fly.

Why does Org need to take up all the available space of a window to
begin with, btw?

> One needs to use `string-pixel-width', which is not always reliable.

string-pixel-width uses the display code, so if it is unreliable, so
will be any other implementation in the display engine (barring any
bugs).  (Of course, you didn't reveal any details of this lack of
reliability, so I don't really know what are we talking about here.)

> >> I think that the main source of the confusion is the first line "Return
> >> width of STRING when displayed in the current buffer", which sounds like
> >> certain buffer-specific display things are affecting the result.
> >
> > Feel free to suggest a single short enough sentence which doesn't have
> > this issue, and yet does explain that the value is not just the count
> > of characters in the string.
> 
> Return width of STRING when displayed using fixed width font.

That loses information (the "current buffer" part: it's important).

Can you explain why "fixed width font" is important enough for you to
want to see it there?  After all, the function counts columns, so
whether the font is fixed-pitch or variable-pitch shouldn't matter.

> However, if I look into the code, it looks like buffer-display-table is
> also taking into account.

Yes.  Also character compositions.

> And string_char_and_length, which I do not fully understand.

That's unrelated.  string_char_and_length is just a convenient way of
walking multibyte text one character at a time.  It returns the
codepoint of the current character, and also returns the length of its
multibyte sequence, so it is easy to get to the next character in one
jump.  (Keep in mind that the basic movement across buffer text is
always by bytes, and a character can be represented by 1 to 5 bytes.)

> And glyphs appear to honor variable pitch font, if it is default.

No, they don't.  When the function finds characters that will be
composed on display, it computes the pixel-width of the result of the
composition, and then converts that into the units of the frame's
default face's font.  For that conversion, and for that conversion
only, the function needs the parameter of the default face's font that
tells us the width of its characters; if that font is variable-pitch
(unlikely), then these parameters give only some kind of average
width.

But again, all this access to the font parameters is only done for
composed characters, because character composition rules can produce
glyphs that have no corresponding codepoints, and therefore we cannot
look them up in char-width-table.