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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 64696@debbugs.gnu.org
> Date: Tue, 18 Jul 2023 12:09:43 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Whether the inherited properties should also include the invisible
> > property could be subject to discussion, but it isn't 100% clear to me
> > that it should always be excluded.
> 
> The problem is that inheriting 'invisible (if its value is actually
> hiding text) yields to cursor not moving to the target column.
> 
> When I read the docstring:
> 
>     (indent-to COLUMN &optional MINIMUM)
>     
>     Documentation
>     Indent from point with tabs and spaces until COLUMN is reached.
> 
> I expect that (current-column) will become COLUMN after calling
> `indent-to'. It is not the case in the described scenario.

If the problem is documentation, we can easily augment the
documentation to match the actual behavior.

So let's first discuss the behavior, not what the documentation says.

> More generally, `indent-to' implementation assumes that it is sufficient
> to insert "COLUMN - (current-column)" spaces in order to reach COLUMN
> (let me ignore tabs for simplicity).

But ignoring the tabs is not a valid "trick" here, because it exactly
means that your interpretation is too naïve: there's more in
indentation to a certain column than meets the eye, precisely because
of stuff like tabs, display properties, composed characters, and other
calamities.

> And the actual scenario for Org is even more complex because
> Org fontification is what is adding that problematic invisible text
> property, leading to race condition between redisplay and indentation.
> When I sprinkled (redisplay) calls to different places in Org's
> tag alignment code, the results varied depending on where the
> (redisplay) call was inserted.

there couldn't be any race condition here, because indent-to is not
run when redisplay runs.  I guess you mean that one could see the
indentation appear, then disappear as result of JIT fontifications, or
not appear at all, depending on the details?

> > In any case, I think you can bind text-property-default-nonsticky
> > around the indent-to call to control this, right?  Or use the
> > rear-sticky text property.
> 
> That's what I did to fix things on Org side, but I believe that the
> current behaviour is a genuine bug.

"Bug" in what sense?  Do you mean that indenting should disregard
properties completely? or just the invisible property? or something
else?  indent-to is a general-purpose primitive, so any change there
will affect gobs of Emacs Lisp programs, and we must specify the
desired behavior in a lot of detail in order to be able to discuss
such changes.