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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> In the ideal world, Emacs would indent both visually and textually.
>
> I disagree that this is the ideal.  "Textual" indentation is not
> indentation at all, it is fundamentally a completely different feature
> for completely different purposes.  Even if we agree that Emacs should
> have it (and I don't yet agree), you shouldn't expect from the Emacs
> indentation to fill this niche, except by sheer luck in some use
> cases.

Got it.

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

> But if you want to work on adding this, please feel free.  It has its
> uses, even for indentation; see, for example, pixel-fill.el.  It is on
> our TODO to provide pixel-granularity indentation for text using
> variable-pitch fonts (but this again is for visual appearance only).

I did some preliminary work in Org mode.
For example, I tried to right-align tags like

|left fringe|* Heading                             :tag:|right fringe|

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.

Org also provides org-indent-mode that uses text properties to align
text visually.

>> I would use it in Org instead of `org-current-text-column'.
>
> So we have one user.  And even in your case, you don't want them all
> disabled: the character compositions, for example, should stay turned
> ON.

Sure. Especially if the composition is dictated by UTF standard.

>> may not hold in future (the docstring implies that `string-width' may as
>> well consider visuals: "Return width of STRING when displayed in the
>> current buffer.")
>
> Selective citation alert!  The full text of the doc string is:
>
>   Return width of STRING when displayed in the current buffer.
>   Width is measured by how many columns it occupies on the screen.
>   Optional arguments FROM and TO specify the substring of STRING to
>   consider, and are interpreted as in ‘substring’.
>
>   When calculating width of a multibyte character in STRING,
>   only the base leading-code is considered; the validity of
>   the following bytes is not checked.  Tabs in STRING are always
>   taken to occupy ‘tab-width’ columns.  The effect of faces and fonts
>   used for non-Latin and other unusual characters (such as emoji) is
>   ignored as well, as are display properties and invisible text.
>   For these reasons, the results are not generally reliable;
>   for accurate dimensions of text as it will be displayed,
>   use ‘window-text-pixel-size’ instead.
>
> What else do you want us to say, for you to understand that the
> "visual" part here is quite limited?

It is clear that it is limited, but I am concerned that there are still
some display features (and possibly display features added in future)
that may change the behavior.

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>