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: Mon, 24 Jul 2023 08:18:54 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1. Org mode is generally aiming for the produced Org files to be
> >>    readable as unfontified plain text. So, quirks related to visual
> >>    indentation generally tend to mess things up.
> >
> > "Unfontified"?  AFAIK, Org files do use fontifications, don't they?
> > So what do you mean by "unfontified plain text" here?  But that's an
> > aside, feel free to ignore.
> 
> For example, consider an Org table like
> 
> | *This* | is | some text |
> | more |    |  text     |
> 
> It looks aligned in Org buffers ("*" is invisible), but not when copied
> to message buffer.

Where does fontification enter this picture?

> >> 2. Org mode uses indentation as part of the syntax. I had to get rid of
> >>    using `current-column' and calculated "true textual indentation"
> >>    manually to avoid breakage after `current-column' started to take
> >>    into account invisibility. (bug#56837)
> >
> > This cannot be avoided.  Emacs provides by default many features that
> > "mess up" this kind of "true textual indentation".  Some of these
> > features include:
> > ...
> > (I'm probably missing some more.)  Only the Lisp program knows which
> > of those are relevant to the particular application at hand.
> 
> Sure, but how can an application, say, disable all the effects of visual
> representation without (1) searching and let-binding each specific
> toggle (and possibly adding more in future versions of Emacs); (2)
> re-implementing the existing indentation code (like what
> `org-current-text-column' does)?

It can't.  But then it also doesn't want to.  In practice, most of
these features should not be turned off, because either the text will
become illegible, or the indentation performed when the features are
turned off will break when the text is displayed "normally".

IOW, the tendency should be to provide _more_ visual indentation, by
making our indentation commands smarter and more fine-grained (e.g.,
pixel-wise), not to make them _less_ visual by disabling the important
display features.

The important thing to remember is that Emacs makes all those
display-time transformation because that's how people want to see the
text on the screen.  It is very rare to see an application that wants
to show decomposed characters, as in a◌́ instead of á, or to see a TAB
shown as a single column.  Heck, even the display of control
characters, like 
, is part of this, and why would we want to turn
that off?

IOW, the need for turning these off is extremely rare, and doesn't
justify such global toggles, because no one will use them.

> > We could introduce separate indentation/current-column knobs for each
> > of the above features, but it would make little sense to me, since
> > most, if not all, of them already have such knobs.  For example,
> > character composition can be disabled by flipping a variable.
> 
> It would help to list what contributes to indentation/columns in the
> documentation.

They are a legion.  Basically, every display-related feature described
in the ELisp manual -- and there are a lot of them -- is of this
nature.  Since we already describe them all in the manual, adding a
section which mentions them all together is strictly not necessary for
a reference manual.  It's more a job for a tutorial.

You are asking that someone does a very large job of collecting
existing stuff together, for facilitating a solution of some pretty
rare problem.  I cannot justify a large job such as this one -- going
through all the Emacs display features and describing them together --
for this kind of purpose.  But if someone wants to work on that, I
won't necessarily object if the result is concise and doesn't repeat
the existing material.

> > See above: you are actually opening a Pandora box, and any solution
> > will likely be based on existing variables.  So I think we already
> > have what you want, it just might not be immediately obvious in each
> > case which of the knobs to use.  The default behavior of
> > current-column can already be affected by disabling
> > auto-composition-mode, by tweaking the buffer's invisibility spec, and
> > by defining display properties whose values are conditional.  Tab
> > expansion can also be controlled.  What else would make sense?
> 
> A toggle: disable all visual contributors.

It will never be used.