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