Dear Eli Ok, it is a different problem. Thanks. Miguel. On Thu, Sep 22, 2011 at 12:07 AM, Eli Zaretskii wrote: > > From: "Miguel V. S. Frasson" > > Date: Wed, 21 Sep 2011 18:22:50 -0300 > > > > I checkout again today, recompiled, and part of the problem is solved, > but > > not completely. > > > > How to reproduce the bug: > > > > 1) emacs -Q > > > > 2) in some buffer insert the following text (3 lines of text, each ending > > with words endlineN): > > > > longlines longlines longlines longlines longlines longlines longlines > > longlines longlines longlines longlines longlines endline1 > > longlines longlines longlines longlines longlines longlines longlines > > longlines endline2 > > longlines longlines longlines longlines >< endline3 > > > > 3) M-x longlines-mode > > > > The text becomes 5 lines that looks like > > longlines longlines longlines longlines longlines longlines longlines > > longlines longlines longlines longlines longlines endline1 > > longlines longlines longlines longlines longlines longlines longlines > > longlines endline2 > > longlines longlines longlines longlines >< endline3 > > > > 4) M-x longlines-show-hard-newlines > > > > 5) put point between in the middle of >< in last line > > > > 6) type UP 2 times and observe that point goes to beginning of 4th line, > > strangely > > > > 7) type UP again e text behaves normally. > > > > 8) now put the point in the end of last line > > > > 9) type UP and point strangely goes to beginning of line, and next UPs > > always put point ant beginning of lines. > > Don't you see the same behavior in Emacs 23? I do, and so the above > is an entirely different problem, inherent to how C-n and C-p deduce > what column to use as a temporary goal for placing point on the next > or previous line. For an even uglier manifestation of this problem, > see the 2nd problem described in bug #9254. > > You are welcome to file a new bug about these issues with C-n/C-p, but > the current bug should remain closed, because the problem with the > cursor jumping to a completely unrelated place (the end of the 1st > screen line) was resolved. > -- Miguel Vinicius Santini Frasson mvsfrasson@gmail.com