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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I do not think that double scan will be needed. Just space width
>> calculation is to be postponed until the line is processed.
>
> That's what I meant by "double scan".  The Emacs display engine never
> looks back, once it processed some text property.  Looking back is
> particularly unacceptable when the display engine is called to start
> in the middle of the line, because it would mean we need always go to
> the beginning of the line.

What about fill_up_glyph_row_area_with_spaces and
fill_up_frame_row_with_spaces? They append extra space glyphs to build
up to window/frame width. And what I propose would enlarge some
existing space glyphs instead.

>> > 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:
>
> I guessed that much, but my point is: why not set some reasonable
> fixed right position, and align to that?

That's what we do (org-tags-column). However, people often ask for
auto-adjustment to right margin when frame/window is resized.

The usual use-case for auto-adjustment is when Org/agenda window is
first built as a sole window in the frame and then user splits the frame
into two windows vertically:

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

* Heading                           →| Other text file here.
* Another heading                   →| Tags on the left are not visible.

or

* Heading                           ⤶| Other text file here.
           :tag1:tag2:tag3:          | Tags wrapped and look ugly.
* Another heading                   ⤶|
                     :tag4:          |

> If that is the problem, you should use buffer-text-pixel-size or
> window-text-pixel-size instead.

Good point. Thanks!

>> 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.
>
> How does your proposal for the change in the doc string serve these
> issues?  I asked a specific question about your proposed change, and I
> don't think what you say above answers that specific question?

I was referring to one step earlier in the discussion:

    >> A toggle: disable all visual contributors.
    > It will never be used.

    I would use it in Org instead of `org-current-text-column'.
    It currently relies upon `string-width' ignoring visuals, which may or
    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.")

You pointed that my docstring reference did not include the whole
docstring and that the docstring, in fact, does say that visuals have
"limited" effect. So, I proceeded with docstring suggestion to highlight
that window settings have no effect.

My suggestion turned out to be wrong: (1) variable pitch faces can
affect the results for glyphs; (2) buffer-display-table can alter the
results.

And note that the full docstring of `string-width' does not mention the
above 2 factors. It just mentions a small subset of visual settings that
_do not_ affect the results. Which is deceiving.

> If variable-pitch fonts are used for the _default_ face's font, then
> using string-width as the measure of width on display is clearly
> inadequate to begin with, isn't it?

So, we coming back to the original discussion about a toggle to disable
"visuals", there seems to be a need in it, at the end.
`org-current-text-column' is clearly not 100% reliable when using
`string-width'.

> I don't understand why "ignore".  But TBH, I don't think I understand
> what are you trying to accomplish with this long discussion.

We have discussed multiple topics in this thread. From my point point of
view, things are mostly revolving around understanding how
invisible/display/other visual settings are affecting `indent-to', and
`current-column'. Because on Org mode side, we sometimes want and
sometimes don't want to account for visuals.

On Emacs side, I can see that full, partial, or limited subset of visual
settings is accounted for in various functions, like `indent-to',
`current-column', and `string-width'. Not everything is clearly
documented for `string-width' and accounting for invisible text
properties is not fully consistent in `indent-to'.

>> Org syntax must not depend on Emacs visual settings.
>
> If that is what you are trying to do, I think you will have quite a
> few difficulties.  Emacs does not cater to such applications,
> especially when you are using APIs whose purpose was to support
> display and layout calculations.

I'd prefer to use the existing API if possible. But to do it, I first
want to understand its logic. Inconsistencies in this logic is what this
report is about.

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