bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Martin Edström]

There remains a niggling issue related to bug 61580 ( https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-03/msg00094.html )

Basically, reproduce that same setup. Now turn on M-x visual-line-mode and try to use M-x set-goal-column (C-x C-n).  It does not stick to the goal column you choose.

Martin Edstrom

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

> From: "Martin Edström" <meedstrom@runbox.eu>
> Date: Fri, 02 Aug 2024 12:35:32 +0200 (CEST)
> 
> There remains a niggling issue related to bug 61580 ( https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-03/msg00094.html )
> 
> Basically, reproduce that same setup. Now turn on M-x visual-line-mode and try to use M-x set-goal-column (C-x C-n).  It does not stick to the goal column you choose.

Thanks, but please show a full recipe for reproducing this, starting
from "emacs -Q".  The original setup talks about an Org file(is that
part necessary?) and some added text properties with absolute buffer
positions, so I'd rather not guess how to repeat that.  Please also
describe in more detail what you mean by "does not stick to the goal
column" -- which commands did you type that didn't honor the goal
column?

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Martin Edstrom]

Alright, I keep being mistaken about the reproducibility of my bug reports, but I'm reasonably sure the following steps are reproducible.


Step 0: Start emacs -Q  (emacs 29.4 if you have that version, Debian sid package version 1:29.4+1-3)

Step 1: Erase the scratch buffer, and paste this text:

* h1
** h2
- a.y.........
- x...........
*** h3
**** h4
- ....w.......
- z...........

Step 2: Use M-: to eval this expression:

(progn
  (add-text-properties 12 13 '(line-prefix "  "))
  (add-text-properties 27 28 '(line-prefix "  "))
  (add-text-properties 57 58 '(line-prefix "    "))
  (add-text-properties 72 73 '(line-prefix "    "))
  (add-text-properties 12 13 '(display "•"))
  (add-text-properties 27 28 '(display "•"))
  (add-text-properties 57 58 '(display "•"))
  (add-text-properties 72 73 '(display "•")))

Step 3: Run M-x visual-line-mode.

Step 4: Move point to "z", inside the last line, and type C-x C-n (set-goal-column). Say yes to the disabled-command prompt.

Now I would expect moving point upwards with C-p any number of times should still make point land on the text after the list bullet, but the goal column actually seems to be offset in some way influenced by the line prefix. Even using C-n to come back to the line that has "z....." does not place point on the same position as when you started out.


(Alternative reproduction steps: instead of step 2, use M-x org-mode RET M-x org-indent-mode RET.  That's how the bug was found.)

Martin Edstrom

On Sun, 04 Aug 2024 11:47:49 +0300, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: "Martin Edström" <meedstrom@runbox.eu>
> > Date: Fri, 02 Aug 2024 12:35:32 +0200 (CEST)
> > 
> > There remains a niggling issue related to bug 61580 ( https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-03/msg00094.html )
> > 
> > Basically, reproduce that same setup. Now turn on M-x visual-line-mode and try to use M-x set-goal-column (C-x C-n).  It does not stick to the goal column you choose.
> 
> Thanks, but please show a full recipe for reproducing this, starting
> from "emacs -Q".  The original setup talks about an Org file(is that
> part necessary?) and some added text properties with absolute buffer
> positions, so I'd rather not guess how to repeat that.  Please also
> describe in more detail what you mean by "does not stick to the goal
> column" -- which commands did you type that didn't honor the goal
> column?

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Martin Edstrom]

I want to note that some email clients collapse strings of more than 1 spaces to just 1 space, so if the expression (add-text-properties 72 73 '(line-prefix "    ")) seems to have a string with 1 space, try getting your client to show you the unformatted source of the email.

Martin Edstrom

On Tue, 06 Aug 2024 16:10:09 +0200 (CEST), "Martin Edstrom" <meedstrom@runbox.eu> wrote:

> Alright, I keep being mistaken about the reproducibility of my bug reports, but I'm reasonably sure the following steps are reproducible.
> 
> 
> Step 0: Start emacs -Q  (emacs 29.4 if you have that version, Debian sid package version 1:29.4+1-3)
> 
> Step 1: Erase the scratch buffer, and paste this text:
> 
> * h1
> ** h2
> - a.y.........
> - x...........
> *** h3
> **** h4
> - ....w.......
> - z...........
> 
> Step 2: Use M-: to eval this expression:
> 
> (progn
>   (add-text-properties 12 13 '(line-prefix "  "))
>   (add-text-properties 27 28 '(line-prefix "  "))
>   (add-text-properties 57 58 '(line-prefix "    "))
>   (add-text-properties 72 73 '(line-prefix "    "))
>   (add-text-properties 12 13 '(display "•"))
>   (add-text-properties 27 28 '(display "•"))
>   (add-text-properties 57 58 '(display "•"))
>   (add-text-properties 72 73 '(display "•")))
> 
> Step 3: Run M-x visual-line-mode.
> 
> Step 4: Move point to "z", inside the last line, and type C-x C-n (set-goal-column). Say yes to the disabled-command prompt.
> 
> Now I would expect moving point upwards with C-p any number of times should still make point land on the text after the list bullet, but the goal column actually seems to be offset in some way influenced by the line prefix. Even using C-n to come back to the line that has "z....." does not place point on the same position as when you started out.
> 
> 
> (Alternative reproduction steps: instead of step 2, use M-x org-mode RET M-x org-indent-mode RET.  That's how the bug was found.)
> 
> Martin Edstrom
> 
> On Sun, 04 Aug 2024 11:47:49 +0300, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > From: "Martin Edström" <meedstrom@runbox.eu>
> > > Date: Fri, 02 Aug 2024 12:35:32 +0200 (CEST)
> > > 
> > > There remains a niggling issue related to bug 61580 ( https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-03/msg00094.html )
> > > 
> > > Basically, reproduce that same setup. Now turn on M-x visual-line-mode and try to use M-x set-goal-column (C-x C-n).  It does not stick to the goal column you choose.
> > 
> > Thanks, but please show a full recipe for reproducing this, starting
> > from "emacs -Q".  The original setup talks about an Org file(is that
> > part necessary?) and some added text properties with absolute buffer
> > positions, so I'd rather not guess how to repeat that.  Please also
> > describe in more detail what you mean by "does not stick to the goal
> > column" -- which commands did you type that didn't honor the goal
> > column?

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

tags 72420 notabug
thanks

> From: "Martin Edstrom" <meedstrom@runbox.eu>
> CC: "72420" <72420@debbugs.gnu.org>
> Date: Tue, 06 Aug 2024 16:10:09 +0200 (CEST)
> 
> Alright, I keep being mistaken about the reproducibility of my bug reports, but I'm reasonably sure the following steps are reproducible.

I think they are, thanks.

> Step 3: Run M-x visual-line-mode.

Note: I get the same behavior without visual-line-mode, so I think
this Step 3 is not needed.

> Step 4: Move point to "z", inside the last line, and type C-x C-n (set-goal-column). Say yes to the disabled-command prompt.
> 
> Now I would expect moving point upwards with C-p any number of times should still make point land on the text after the list bullet, but the goal column actually seems to be offset in some way influenced by the line prefix. Even using C-n to come back to the line that has "z....." does not place point on the same position as when you started out.

Yes, the column is offset by the line-prefix, because line-prefix is
not considered to be part of the text-area.  You can see this already
when you type "C-x C-n" in Step 4: Emacs says the column at "z" is 2,
not 6.

This is the intended behavior, so there's no bug here.

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

> From: "Martin Edstrom" <meedstrom@runbox.eu>
> CC: "Eli Zaretskii" <eliz@gnu.org>, "72420" <72420@debbugs.gnu.org>
> Date: Tue, 06 Aug 2024 16:24:16 +0200 (CEST)
> 
> I want to note that some email clients collapse strings of more than 1 spaces to just 1 space, so if the expression (add-text-properties 72 73 '(line-prefix "    ")) seems to have a string with 1 space, try getting your client to show you the unformatted source of the email.

My email client is Emacs, so no such problems there ;-)

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Martin Edstrom]

But, it's odd that visual-line-mode does not affect it for you - it does for me. 

If I leave visual-line-mode off, then I get the behavior I expect (i.e. set-goal-column at column 2 is treated as column 6), which is useful.  Turning it on causes the command to behave in a way that is not useful, as I described.

Martin Edstrom

On Wed, 07 Aug 2024 14:01:18 +0300, Eli Zaretskii <eliz@gnu.org> wrote:

> tags 72420 notabug
> thanks
> 
> > From: "Martin Edstrom" <meedstrom@runbox.eu>
> > CC: "72420" <72420@debbugs.gnu.org>
> > Date: Tue, 06 Aug 2024 16:10:09 +0200 (CEST)
> > 
> > Alright, I keep being mistaken about the reproducibility of my bug reports, but I'm reasonably sure the following steps are reproducible.
> 
> I think they are, thanks.
> 
> > Step 3: Run M-x visual-line-mode.
> 
> Note: I get the same behavior without visual-line-mode, so I think
> this Step 3 is not needed.
> 
> > Step 4: Move point to "z", inside the last line, and type C-x C-n (set-goal-column). Say yes to the disabled-command prompt.
> > 
> > Now I would expect moving point upwards with C-p any number of times should still make point land on the text after the list bullet, but the goal column actually seems to be offset in some way influenced by the line prefix. Even using C-n to come back to the line that has "z....." does not place point on the same position as when you started out.
> 
> Yes, the column is offset by the line-prefix, because line-prefix is
> not considered to be part of the text-area.  You can see this already
> when you type "C-x C-n" in Step 4: Emacs says the column at "z" is 2,
> not 6.
> 
> This is the intended behavior, so there's no bug here.

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

> From: "Martin Edstrom" <meedstrom@runbox.eu>
> CC: "72420" <72420@debbugs.gnu.org>
> Date: Wed, 07 Aug 2024 14:07:45 +0200 (CEST)
> 
> But, it's odd that visual-line-mode does not affect it for you - it does for me. 
> 
> If I leave visual-line-mode off, then I get the behavior I expect (i.e. set-goal-column at column 2 is treated as column 6), which is useful.  Turning it on causes the command to behave in a way that is not useful, as I described.

If you leave visual-line-mode off, then type C-p twice from "z", don't
you see point go to the 3rd "*" of the line "**** h4"?  And if so,
isn't that what you meant by "the goal column actually seems to be
offset in some way influenced by the line prefix"?  Or did I
misunderstand what you consider a problem in the existing behavior?

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Martin Edstrom]

> > From: "Martin Edstrom" <meedstrom@runbox.eu>
> > CC: "72420" <72420@debbugs.gnu.org>
> > Date: Wed, 07 Aug 2024 14:07:45 +0200 (CEST)
> > 
> > But, it's odd that visual-line-mode does not affect it for you - it does for me. 
> > 
> > If I leave visual-line-mode off, then I get the behavior I expect (i.e. set-goal-column at column 2 is treated as column 6), which is useful.  Turning it on causes the command to behave in a way that is not useful, as I described.
> 
> If you leave visual-line-mode off, then type C-p twice from "z", don't
> you see point go to the 3rd "*" of the line "**** h4"?  And if so,
> isn't that what you meant by "the goal column actually seems to be
> offset in some way influenced by the line prefix"?  Or did I
> misunderstand what you consider a problem in the existing behavior?

Indeed, on that line, the behavior is the same with and without visual-line-mode, going to the 3rd "*".

However if I go up to a list item such as "- x...........", I observe different behavior.  With visual-line-mode, point ends up on the bullet, not on "x".

That is surprising, no?

Martin

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

> From: "Martin Edstrom" <meedstrom@runbox.eu>
> CC: "72420" <72420@debbugs.gnu.org>
> Date: Wed, 07 Aug 2024 16:03:40 +0200 (CEST)
> 
> > > From: "Martin Edstrom" <meedstrom@runbox.eu>
> > > CC: "72420" <72420@debbugs.gnu.org>
> > > Date: Wed, 07 Aug 2024 14:07:45 +0200 (CEST)
> > > 
> > > But, it's odd that visual-line-mode does not affect it for you - it does for me. 
> > > 
> > > If I leave visual-line-mode off, then I get the behavior I expect (i.e. set-goal-column at column 2 is treated as column 6), which is useful.  Turning it on causes the command to behave in a way that is not useful, as I described.
> > 
> > If you leave visual-line-mode off, then type C-p twice from "z", don't
> > you see point go to the 3rd "*" of the line "**** h4"?  And if so,
> > isn't that what you meant by "the goal column actually seems to be
> > offset in some way influenced by the line prefix"?  Or did I
> > misunderstand what you consider a problem in the existing behavior?
> 
> Indeed, on that line, the behavior is the same with and without visual-line-mode, going to the 3rd "*".
> 
> However if I go up to a list item such as "- x...........", I observe different behavior.  With visual-line-mode, point ends up on the bullet, not on "x".
> 
> That is surprising, no?

Not to me, it isn't, but then I've hacked on that code too much...

Anyway, the problem is the difference in behavior between
visual-line-mode on and off, and you consider the behavior with the
mode off as correct?  Because this was not what your original report
said, AFAICT.

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Martin Edstrom]

> > From: "Martin Edstrom" <meedstrom@runbox.eu>
> > CC: "72420" <72420@debbugs.gnu.org>
> > Date: Wed, 07 Aug 2024 16:03:40 +0200 (CEST)
> > 
> > > > From: "Martin Edstrom" <meedstrom@runbox.eu>
> > > > CC: "72420" <72420@debbugs.gnu.org>
> > > > Date: Wed, 07 Aug 2024 14:07:45 +0200 (CEST)
> > > > 
> > > > But, it's odd that visual-line-mode does not affect it for you - it does for me. 
> > > > 
> > > > If I leave visual-line-mode off, then I get the behavior I expect (i.e. set-goal-column at column 2 is treated as column 6), which is useful.  Turning it on causes the command to behave in a way that is not useful, as I described.
> > > 
> > > If you leave visual-line-mode off, then type C-p twice from "z", don't
> > > you see point go to the 3rd "*" of the line "**** h4"?  And if so,
> > > isn't that what you meant by "the goal column actually seems to be
> > > offset in some way influenced by the line prefix"?  Or did I
> > > misunderstand what you consider a problem in the existing behavior?
> > 
> > Indeed, on that line, the behavior is the same with and without visual-line-mode, going to the 3rd "*".
> > 
> > However if I go up to a list item such as "- x...........", I observe different behavior.  With visual-line-mode, point ends up on the bullet, not on "x".
> > 
> > That is surprising, no?
> 
> Not to me, it isn't, but then I've hacked on that code too much...
> 
> Anyway, the problem is the difference in behavior between
> visual-line-mode on and off, and you consider the behavior with the
> mode off as correct?  Because this was not what your original report
> said, AFAICT.

That is correct. Language is hard, sorry ;-) but it's what I meant when I wrote "Now I would expect moving point upwards with C-p any number of times should still make point land on the text after the list bullet", and by list bullet I could have clarified I meant the list items that start with "-".

Anyway, whichever behavior is considered correct... I don't think visual-line-mode has any business altering the behavior. That is a bug to me!

I noticed this bug because I habitually have Org files open with org-indent-mode, and I was going to use the goal-column trick to add some text to the beginning of several list items.  In practice with this bug, I have to move point forwards by some X characters before typing C-x C-n, which is just weird.  Let me show you:

Say as a toy case, I want to turn this list

** Stuff to do
- Get Igor to dispose of bodies
- Research pig blood
- Raid blood bank

into this

** Stuff to do
- [ ] Get Igor to dispose of bodies
- [ ] Research pig blood
- [ ] Raid blood bank

Everywhere else in Emacs, I can use set-goal-column as one of the many techniques to do this editing comfortably.  With visual-line-mode enabled, I have to move point to somewhere inside the word "Raid", before typing C-x C-n will have the intended effect of ensuring that point will land right after "- " on each line.

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Martin Edström]

Can we undo the "notabug" tag on this one?  The bug is with visual-line-mode.

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

> From: "Martin Edström" <meedstrom@runbox.eu>
> Date: Tue, 20 Aug 2024 10:28:44 +0200 (CEST)
> 
> Can we undo the "notabug" tag on this one?  The bug is with visual-line-mode.

I didn't yet have time to take another look at this, sorry.  When I
do, I will consider this aspect.

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

> Cc: 72420@debbugs.gnu.org
> Date: Tue, 20 Aug 2024 15:24:12 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: "Martin Edström" <meedstrom@runbox.eu>
> > Date: Tue, 20 Aug 2024 10:28:44 +0200 (CEST)
> > 
> > Can we undo the "notabug" tag on this one?  The bug is with visual-line-mode.
> 
> I didn't yet have time to take another look at this, sorry.  When I
> do, I will consider this aspect.

I've now made this test case behave the same both with and without
visual-line-mode on the master branch of the Emacs Git repository.
The patch is below (you will need to rebuild Emacs for it to be
effective, since simple.el is preloaded).

diff --git a/lisp/simple.el b/lisp/simple.el
index a9f8b58..1d3be2b 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8200,7 +8200,7 @@ line-move-finish
 
 	;; Move to the desired column.
         (if (and line-move-visual
-                 (not (or truncate-lines truncate-partial-width-windows)))
+                 (not (or truncate-lines (truncated-partial-width-window-p))))
             ;; Under line-move-visual, goal-column should be
             ;; interpreted in units of the frame's canonical character
             ;; width, which is exactly what vertical-motion does.

bug#72420: set-goal-column misbehaves with a line-prefix and visual-line-mode

[Eli Zaretskii]

> Cc: 72420@debbugs.gnu.org
> Date: Thu, 22 Aug 2024 17:33:16 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Cc: 72420@debbugs.gnu.org
> > Date: Tue, 20 Aug 2024 15:24:12 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: "Martin Edström" <meedstrom@runbox.eu>
> > > Date: Tue, 20 Aug 2024 10:28:44 +0200 (CEST)
> > > 
> > > Can we undo the "notabug" tag on this one?  The bug is with visual-line-mode.
> > 
> > I didn't yet have time to take another look at this, sorry.  When I
> > do, I will consider this aspect.
> 
> I've now made this test case behave the same both with and without
> visual-line-mode on the master branch of the Emacs Git repository.
> The patch is below (you will need to rebuild Emacs for it to be
> effective, since simple.el is preloaded).
> 
> diff --git a/lisp/simple.el b/lisp/simple.el
> index a9f8b58..1d3be2b 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -8200,7 +8200,7 @@ line-move-finish
>  
>  	;; Move to the desired column.
>          (if (and line-move-visual
> -                 (not (or truncate-lines truncate-partial-width-windows)))
> +                 (not (or truncate-lines (truncated-partial-width-window-p))))
>              ;; Under line-move-visual, goal-column should be
>              ;; interpreted in units of the frame's canonical character
>              ;; width, which is exactly what vertical-motion does.
> 

No further comments, so I assume the bug is indeed fixed, and I'm
closing this bug.