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"?
>>
>>