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: Sat, 29 Jul 2023 09:00:22 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.

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.

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

There are two places: display_line and move_it_in_display_line_to.

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

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

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

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

Does window-text-pixel-size work better in those cases?

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

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?

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

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?  The function tries to do its
best, but why do you expect it to do miracles?  Using variable-pitch
fonts for the default face in Emacs is asking for trouble, even if Org
is not used at all.  We currently don't support that well.

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

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

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