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

tags 64988 notabug wontfix
thanks

> Date: Tue, 1 Aug 2023 12:53:57 +0200
> From: Herman@debbugs.gnu.org, Géza <geza.herman@gmail.com>
> 
> If there is a text with display property in a buffer, then 
> move-to-column can move across lines.
> 
> Repro:
> * emacs -Q
> * in the scratch buffer, move the cursor to the top, and put an empty 
> line at the beginning of the buffer
> * execute 'M-: (put-text-property 1 2 'display "line\n")' (note: it's 
> likely that the "\n" causes the problem)
> * notice that the empty line becomes "line"
> * while the cursor still on the first line, execute 'M-: (move-to-column 
> 20)'
> 
> The last command will move the cursor to the next line at column 16, 
> instead of staying at the first line.
> 
> Note: I noticed this problem while using this package: 
> https://github.com/jdtsmith/indent-bars.
> 
> The problem doesn't happen with emacs 28, this is the commit that 
> introduced the issue:
> 
> 4243747b1b8c3b7e3463822804b32e83febe2878 Fix 'current-column' in the 
> presence of display strings

This is a known issue, but it is not a bug, at least not one we know
how to "fix".  In general, move-to-column cannot work correctly when
display strings with embedded newlines are involved, because Emacs
cannot place the cursor at the newline in the middle of such a display
string.

The commit to which you point fixed current-column to correctly report
the column where such display strings are involved, at least in the
important cases.  That move-to-column changed behavior in those cases
is unfortunate, but I couldn't find any sensible way of dealing with
these cases, because the correct result -- setting the cursor after
the newline embedded in the display string, because column 20 doesn't
exist on that line -- is impossible.  (The result that you expected,
which was what Emacs 28 did, i.e. for the cursor to stay at buffer
position 1, is also incorrect, since that position is column 1, not
column 20 and not the last column visible on that line.)

So I'm sorry, but unless someone comes with an idea for how to handle
these situations in a sensible way (and I thought long and hard about
it, but couldn't find such ideas), this will remain a limitation of
move-to-column, and one of the complications introduced by display
strings with embedded newlines in general.  The affected packages will
have to adapt to this change in some ways.  Since the original code
also produced incorrect results, just different incorrect results, I
don't see this as a serious problem, just as a bug that wasn't fixed,
but changed its buggy behavior.