recenter and visual-line-mode

recenter and visual-line-mode

[Milan Stanojević]

I don't know if this is a bug or an expected behavior.

With visual-line-mode on, running (recenter 0) doesn't always put the
point on the top-most line in the window.

I experimented a bit and it seems that (recenter 0) doesn't work if
the point is on the portion of the word that was moved down because of
word-wrapping.

For example, I have word "foobar" where "bar" can't fit on the line.
With visual-line-mode off (and truncate-lines nil), "foo" will be one
visual line and then "bar" on the next. If I turn on visual-line-mode,
the whole "foobar" would move to the next visual line. If I then run
(recenter 0) while point is inside "foo", the lines will move such
that point ends up on line 2, but if I do it while the point is inside
"bar" then the point will end up on line 1. I think the correct
behavior would be to move to line 1 always.

Is this a bug?

I'm using emacs 24.4.1 with Motif toolkit.

Re: recenter and visual-line-mode

[Eli Zaretskii]

> From: Milan Stanojević <milanst@gmail.com>
> Date: Tue, 7 Apr 2015 16:14:59 -0400
> 
> With visual-line-mode on, running (recenter 0) doesn't always put the
> point on the top-most line in the window.
> 
> I experimented a bit and it seems that (recenter 0) doesn't work if
> the point is on the portion of the word that was moved down because of
> word-wrapping.
> 
> For example, I have word "foobar" where "bar" can't fit on the line.
> With visual-line-mode off (and truncate-lines nil), "foo" will be one
> visual line and then "bar" on the next. If I turn on visual-line-mode,
> the whole "foobar" would move to the next visual line. If I then run
> (recenter 0) while point is inside "foo", the lines will move such
> that point ends up on line 2, but if I do it while the point is inside
> "bar" then the point will end up on line 1. I think the correct
> behavior would be to move to line 1 always.
> 
> Is this a bug?
> 
> I'm using emacs 24.4.1 with Motif toolkit.

I cannot reproduce this, not in "emacs -Q".  Can you provide a
complete self-contained recipe for reproducing the problem, starting
from "emacs -Q"?

Re: recenter and visual-line-mode

[Milan Stanojević]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

Here is the elisp code illustrating the issue. Run "emacs -Q" and make
sure your window manager won't mess up with size of the frame (e.g. if
you are using xmonad like I am, just make the frame floating).

Open the attached file and do M-x eval-buffer.

I get the following output
A was on 1, after recenter it is on 1
B was on 1, after recenter it is on 1
C was on 1, after recenter it is on 1
D was on 1, after recenter it is on 1
E was on 1, after recenter it is on 0
F was on 1, after recenter it is on 0
G was on 1, after recenter it is on 0
H was on 1, after recenter it is on 0

This shows that running (recenter 0) at different points of the same
screen line leads to different behavior and it seems that the
difference comes from where the point would be without
visual-line-mode. I think in all cases the point should be at the top
of the line, but that is not the case for ABCD.




On Wed, Apr 8, 2015 at 2:43 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Milan Stanojević <milanst@gmail.com>
>> Date: Tue, 7 Apr 2015 16:14:59 -0400
>>
>> With visual-line-mode on, running (recenter 0) doesn't always put the
>> point on the top-most line in the window.
>>
>> I experimented a bit and it seems that (recenter 0) doesn't work if
>> the point is on the portion of the word that was moved down because of
>> word-wrapping.
>>
>> For example, I have word "foobar" where "bar" can't fit on the line.
>> With visual-line-mode off (and truncate-lines nil), "foo" will be one
>> visual line and then "bar" on the next. If I turn on visual-line-mode,
>> the whole "foobar" would move to the next visual line. If I then run
>> (recenter 0) while point is inside "foo", the lines will move such
>> that point ends up on line 2, but if I do it while the point is inside
>> "bar" then the point will end up on line 1. I think the correct
>> behavior would be to move to line 1 always.
>>
>> Is this a bug?
>>
>> I'm using emacs 24.4.1 with Motif toolkit.
>
> I cannot reproduce this, not in "emacs -Q".  Can you provide a
> complete self-contained recipe for reproducing the problem, starting
> from "emacs -Q"?
>
>

[-- Attachment #2: test-recenter.el --]
[-- Type: text/x-emacs-lisp, Size: 740 bytes --]

(let ((saved-frame-width (frame-width))
      (word "ABCDEFGH"))
  (with-temp-buffer
    (switch-to-buffer (current-buffer))
    (delete-other-windows)
    (set-frame-width (selected-frame) 15)
    (visual-line-mode 1)
    (insert (concat "0123456789 " word))
    (dolist (ch (append (vconcat word) nil)) 
      (goto-char (point-min))
      (recenter 0)
      (search-forward (char-to-string ch)) (backward-char)
      (let (old-row new-row)
        (setq old-row (cdr (posn-col-row (posn-at-point))))
        (recenter 0)
        (setq new-row (cdr (posn-col-row (posn-at-point))))
        (message "%c was on %d, after recenter it is on %d"
                 ch old-row new-row))))
  (set-frame-width (selected-frame) saved-frame-width))

Re: recenter and visual-line-mode

[Milan Stanojević]

Btw, I get slightly different output if I ran emacs in terminal, i.e.
emacs -Q -nw
A was on 1, after recenter it is on 1
B was on 1, after recenter it is on 1
C was on 1, after recenter it is on 1
D was on 1, after recenter it is on 0
E was on 1, after recenter it is on 0
F was on 1, after recenter it is on 0
G was on 1, after recenter it is on 0
H was on 1, after recenter it is on 0

which I think confirms my suspicion because in terminal mode the last
character on the long line is backslash, so D is moved down, whereas
in graphical mode instead of backslash the fringe is used as an
indicator that logical line is too long.

On Wed, Apr 8, 2015 at 3:59 PM, Milan Stanojević <milanst@gmail.com> wrote:
> Here is the elisp code illustrating the issue. Run "emacs -Q" and make
> sure your window manager won't mess up with size of the frame (e.g. if
> you are using xmonad like I am, just make the frame floating).
>
> Open the attached file and do M-x eval-buffer.
>
> I get the following output
> A was on 1, after recenter it is on 1
> B was on 1, after recenter it is on 1
> C was on 1, after recenter it is on 1
> D was on 1, after recenter it is on 1
> E was on 1, after recenter it is on 0
> F was on 1, after recenter it is on 0
> G was on 1, after recenter it is on 0
> H was on 1, after recenter it is on 0
>
> This shows that running (recenter 0) at different points of the same
> screen line leads to different behavior and it seems that the
> difference comes from where the point would be without
> visual-line-mode. I think in all cases the point should be at the top
> of the line, but that is not the case for ABCD.
>
>
>
>
> On Wed, Apr 8, 2015 at 2:43 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Milan Stanojević <milanst@gmail.com>
>>> Date: Tue, 7 Apr 2015 16:14:59 -0400
>>>
>>> With visual-line-mode on, running (recenter 0) doesn't always put the
>>> point on the top-most line in the window.
>>>
>>> I experimented a bit and it seems that (recenter 0) doesn't work if
>>> the point is on the portion of the word that was moved down because of
>>> word-wrapping.
>>>
>>> For example, I have word "foobar" where "bar" can't fit on the line.
>>> With visual-line-mode off (and truncate-lines nil), "foo" will be one
>>> visual line and then "bar" on the next. If I turn on visual-line-mode,
>>> the whole "foobar" would move to the next visual line. If I then run
>>> (recenter 0) while point is inside "foo", the lines will move such
>>> that point ends up on line 2, but if I do it while the point is inside
>>> "bar" then the point will end up on line 1. I think the correct
>>> behavior would be to move to line 1 always.
>>>
>>> Is this a bug?
>>>
>>> I'm using emacs 24.4.1 with Motif toolkit.
>>
>> I cannot reproduce this, not in "emacs -Q".  Can you provide a
>> complete self-contained recipe for reproducing the problem, starting
>> from "emacs -Q"?
>>
>>

Re: recenter and visual-line-mode

[Eli Zaretskii]

> From: Milan Stanojević <milanst@gmail.com>
> Date: Wed, 8 Apr 2015 15:59:16 -0400
> Cc: help-gnu-emacs@gnu.org
> 
> Here is the elisp code illustrating the issue.

Thanks.

For the future, please try to produce test cases that leave the
offending contents on display, instead of doing everything in a
temporary buffer that is killed when the code completes.  That's
because one cannot debug display problems without having the stuff
displayed.

> This shows that running (recenter 0) at different points of the same
> screen line leads to different behavior and it seems that the
> difference comes from where the point would be without
> visual-line-mode. I think in all cases the point should be at the top
> of the line, but that is not the case for ABCD.

What was missing from your original report was that the first visual
line must be _shorter_ than what the window can display on a single
screen line.  IOW, there should be a whitespace character on which
visual-line-mode can break the line _before_ the last (rightmost)
column in the window.  If that whitespace character is exactly at the
last column, the problem doesn't happen (which is what I tried here,
and thus didn't see the problem).

And yes, it's a (very old) bug.  Shouldn't be hard to fix, I think.

Thanks.

Re: recenter and visual-line-mode

[Eli Zaretskii]

> Date: Thu, 09 Apr 2015 11:30:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> And yes, it's a (very old) bug.  Shouldn't be hard to fix, I think.

Now fixed in the Emacs repository for Emacs 25.1.

Re: recenter and visual-line-mode

[Milan Stanojević]

On Fri, Apr 10, 2015 at 6:13 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 09 Apr 2015 11:30:52 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>> And yes, it's a (very old) bug.  Shouldn't be hard to fix, I think.
>
> Now fixed in the Emacs repository for Emacs 25.1.

Thanks a lot! That was quick.

Re: recenter and visual-line-mode

[Eli Zaretskii]

> From: Milan Stanojević <milanst@gmail.com>
> Date: Fri, 10 Apr 2015 11:38:00 -0400
> Cc: help-gnu-emacs@gnu.org
> 
> On Fri, Apr 10, 2015 at 6:13 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Thu, 09 Apr 2015 11:30:52 +0300
> >> From: Eli Zaretskii <eliz@gnu.org>
> >>
> >> And yes, it's a (very old) bug.  Shouldn't be hard to fix, I think.
> >
> > Now fixed in the Emacs repository for Emacs 25.1.
> 
> Thanks a lot! That was quick.

You are welcome.

Like I suspected, it wasn't hard to fix.  For some unclear reason, we
still used the old pre-Emacs-21 code for recentering when the argument
was non-negative, and that old code doesn't support visual-line-mode.