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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

I meant:

^some text<stretch space>some more text$

With <stretch space> adjusting its width in such a way that the whole
line occupies exactly buffer width.

Now, I have to use

^some text<:align-to `(- right-fringe ,(string-pixel-width "some more 
text"))>some more text$

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

I do not think that double scan will be needed. Just space width
calculation is to be postponed until the line is processed.

May you point me to the place in code where the line scan is performed?

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

To produce right-aligned text columns:

* Heading                                              :tag1:tag2:tag3:
* Another heading                                                :tag4:

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

Because `string-pixel-width' does not account for display and
fontification settings in current-buffer. For example, buffer-local
invisibility specs will be ignored; display tables will be ignored; face
remapping will be ignored.

There is also a number of edge cases when `string-pixel-width' will
straight return wrong width. For example, when string has
line-prefix/wrap-prefix text property, its width will depend on whether
string is displayed at bol or not. `string-pixel-width' will always make
it as if string is displayed at bol, thus adding line-prefix width to
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.

My original concern was about `string-width' not producing reliable
results when Emacs visual settings are changed. And, indeed, some
visuals that are not detailed in the docstring are taken into account.

The purpose of using `string-width' in `org-current-text-column' is to
produce reliable result for different users with different visual
settings and fonts. This is because indentation is used in Org syntax
and must not be broken if the Org file is unchanged and visual settings
are.

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

I am concerned exactly about this unlikely scenario.
I have seen variable pitch creating one-off errors for width in the
past.

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

So, it is something Org needs to ignore somehow.
Org syntax must not depend on Emacs visual settings.

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