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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org
> Date: Thu, 27 Jul 2023 08:58:54 +0000
> 
> >> With visual part only using 'display text properties that do not
> >> modify the actual text in file.
> >
> > This will (a) not help you, because the issue of width of the
> > whitespace stretches will still be pertinent; and (b) will complicate
> > Emacs much more, because copying such "text" will become much more
> > tricky in general.
> 
> I am not sure if I understand the problem with copying. Certain text
> properties are already ignored when copying anyway.

Display properties are only supported in Emacs, so copying "outside"
will cause the text to look differently.  Likewise in Emacs, if
display properties are removed when copying.

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

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