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

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64988 in the body.
You can then email your comments to 64988 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Herman, Géza <geza.herman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; move-to-column can move across lines if there is a text with
 display property
Date: Tue, 1 Aug 2023 12:53:57 +0200

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

Message #8 received at 64988 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Herman, Géza <geza.herman <at> gmail.com>
Cc: 64988 <at> debbugs.gnu.org
Subject: Re: bug#64988: 30.0.50;
 move-to-column can move across lines if there is a text with display
 property
Date: Tue, 01 Aug 2023 15:25:52 +0300

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.

Message #13 received at 64988 <at> debbugs.gnu.org (full text, mbox):

From: "Herman, Geza" <geza.herman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64988 <at> debbugs.gnu.org
Subject: Re: bug#64988: 30.0.50; move-to-column can move across lines if there
 is a text with display property
Date: Tue, 1 Aug 2023 14:57:29 +0200

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?

Regarding how to fix this problem: wouldn't it make sense to stop 
calculating the width at the first "\n" in the displayed string? 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)

On 8/1/23 14:25, Eli Zaretskii wrote:
> 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.

Message #16 received at 64988 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Herman, Geza" <geza.herman <at> gmail.com>
Cc: 64988 <at> debbugs.gnu.org
Subject: Re: bug#64988: 30.0.50; move-to-column can move across lines if there
 is a text with display property
Date: Tue, 01 Aug 2023 16:26:57 +0300

> Date: Tue, 1 Aug 2023 14:57:29 +0200
> Cc: 64988 <at> debbugs.gnu.org
> From: "Herman, Geza" <geza.herman <at> 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.

Message #19 received at 64988 <at> debbugs.gnu.org (full text, mbox):

From: "Herman, Geza" <geza.herman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64988 <at> debbugs.gnu.org
Subject: Re: bug#64988: 30.0.50; move-to-column can move across lines if there
 is a text with display property
Date: Tue, 1 Aug 2023 16:32:22 +0200

On 8/1/23 15:26, Eli Zaretskii wrote:
> Copy text into a temporary buffer, remove 'display' properties, call
> move-to-column there, then move to the same position in the original
> buffer?
Yep, that's a possible solution, but I feel that it is such a basic 
functionality, emacs should be able to solve this question without using 
such workarounds. But this is just an intuition, feel free to ignore it 
:) Column-enforce-mode can be already slow for large files, if it had to 
do this copy all the time it would be even slower.

>> 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?
I understand that solving this problem if we want to stick with the 
current idea of move-to-column (meaning that it has to consider display 
properties), is hard, or even we can say that there are no good 
solutions. But ideally, it should move the cursor to the closest 
possible location in the same visual line. As far as I understand the 
intention of this function.

But for my problem, I don't think that this is the way to go. 
Column-enforce-mode should calculate columns without considering 
properties. I'd be good if emacs gave an out-of-box solution for this 
(without using copying), but if it doesn't, it's also fine.

Message #24 received at 64988-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64988-done <at> debbugs.gnu.org, geza.herman <at> gmail.com
Subject: Re: bug#64988: 30.0.50; move-to-column can move across lines if there
 is a text with display property
Date: Sat, 2 Sep 2023 09:38:50 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 64988 notabug wontfix
> thanks
[...]
> 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.

I'm therefore closing this bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.