bug#64988: 30.0.50; move-to-column can move across lines if there is a text with display property

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 1 Aug 2023 14:57:29 +0200
> Cc: 64988@debbugs.gnu.org
> From: "Herman, Geza" <geza.herman@gmail.com>
> 
> I think, in my case, the move-to-column should completely ignore the 
> display property. Is there a function which does that?
> 
> I noticed this problem because how indent-bars interacts with 
> column-enforce-mode (https://github.com/jordonbiondo/column-enforce-mode).
> 
> column-enforce-mode uses move-to-column to mark long lines. And because 
> the display property with "\n" basically joins neighboring lines, 
> column-enforce-mode marks lines incorrectly.
> 
> I think it should only consider what's in the buffer, and ignore all 
> rendering related properties. Is there a way to accomplish this?

Copy text into a temporary buffer, remove 'display' properties, call
move-to-column there, then move to the same position in the original
buffer?

> Regarding how to fix this problem: wouldn't it make sense to stop 
> calculating the width at the first "\n" in the displayed string?

Stop calculating and do what?  move-to-column doesn't just calculate,
it should move point to some place.  Where do you want to move point
in these cases?

> At least, it would fix this problem, as far as I understand. Not
> sure if it breaks anything. But supposedly nothing should depend on
> the exact behavior of column calculations, if the displayed string
> contains characters after the first "\n" (because it's kind of
> undefined what the width of a multi-line string is)

When the current line is shorter than N columns, move-to-column with
the argument of N should stop at the end of the line.  But it's
impossible to do that when the newline comes from a display property.
So the correct behavior is not "undefined" in this case, it is just
impossible to achieve.