GNU bug report logs -
#64988
30.0.50; move-to-column can move across lines if there is a text with display property
Previous Next
Reported by: Herman, Géza <geza.herman <at> gmail.com>
Date: Tue, 1 Aug 2023 10:55:02 UTC
Severity: normal
Tags: notabug, wontfix
Merged with 66942
Found in version 30.0.50
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #8 received at 64988 <at> debbugs.gnu.org (full text, mbox):
tags 64988 notabug wontfix
thanks
> Date: Tue, 1 Aug 2023 12:53:57 +0200
> From: Herman <at> debbugs.gnu.org, Géza <geza.herman <at> 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.
This bug report was last modified 1 year and 133 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.