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: Sun, 30 Jul 2023 07:51:09 +0000
> 
> 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.

First, these are for TTY frames only (that's the meaning of
"frame-based redisplay" in Emacs display parlance).

And more importantly, these fill _the_rest_ of a screen line with
space glyphs.  We already know how to do that, on both TTY and GUI
frames, see extend_face_to_end_of_line, where it calls
append_stretch_glyph.  The problem is that when these functions are
called, we need to be able to calculate the width of the stretch glyph
to produce.  That is possible if the stretch is the last element of a
screen line and ends at the right edge of the window's text area, but
not possible if some text is yet to follow, because the width of the
following text on display is not yet known -- it was not calculated.

The basic design of the Emacs display engine is that layout
calculations proceed in strict left-to-right visual order, one buffer
or string position at a time, and each position is completely
processed before we proceed to the next.  What you are asking for will
violate this basic design, so it is something I very much would like
to avoid, because it will definitely cause complications and bugs.

> And what I propose would enlarge some existing space glyphs instead.

What do you mean by "enlarge existing space glyphs"?  In the functions
to which you pointed, each space glyph is just the SPC character
(which is eventually sent to the text-mode terminal); those cannot be
enlarged, because this is a text-mode terminal.

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

And you must honor each and every request?  Why?  There's nothing
wrong with telling users "this is too complicated to implement,
sorry".

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

When a window is split, the alignment could be re-done, no?

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

"Deceiving" is a harsh word, please reconsider.

There's a limit to which a doc string can describe every single
subtlety of a non-trivial implementation, and still remain useful.  If
someone needs to know about these aspects (presumably because their
Lisp program does something very special, because otherwise these
things "just work"), they should either read the source or ask here,
because they basically use string-width outside of its main usage
domain.

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

I don't see how this follows.  And I thought I already explained why
"visuals" is not well defined in general: each application needs to
disable some parts of it, but never all of them, and which parts
depends on the application.  Why do we have to reiterate this over and
over again?

> `org-current-text-column' is clearly not 100% reliable when using
> `string-width'.

Then don't use string-width.  I don't know what you should use
instead, because I don't understand well enough what
org-current-text-column wants to do and for what purpose.  It could be
that the functionality you want doesn't exist, or maybe it can be had
by some tweaking of the existing APIs, I don't know.  But if that is
the issue here, we should restart the discussion from a very different
point: by your describing what you need to do win
org-current-text-column and why.  What current-column and indent-to do
or don't do is almost irrelevant, it seems.

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

There are no inconsistencies, not from where I stand.  Each API was
written for a specific purpose and does a specific job; if your
purpose is very different, you need to describe it first, and do that
with all the details.  Then we can see if we already support your
purpose or need new APIs.