bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17585: 24.4.50; vertical-motion erroneously adds points


From: Eli Zaretskii
Subject: bug#17585: 24.4.50; vertical-motion erroneously adds points
Date: Fri, 30 May 2014 09:47:17 +0300

> Date:  Thu, 29 May 2014 23:21:05 -0700
> From:  Keith David Bershatsky <address@hidden>
> Cc:  address@hidden
> 
> The `test` function yields the same result with Emacs built (--with-ns) from 
> the Trunk as of May 29, 2014 at 11:18 P.S.T.  Approximately when, please, 
> should I expect to see the fix merged into the Trunk?

It was merged to the trunk on May 26, as trunk revision 117154 (yes,
the same revision number as on the emacs-24 branch; it happens).

> I'm using macports / baazar:
> 
> /macports/bin/bzr branch --stacked bzr://bzr.savannah.gnu.org/emacs/trunk 
> emacs-trunk

Do you have revision 117154 in your bzr trunk branch?  If you do, you
should see this entry in src/ChangeLog:

  2014-05-26  Eli Zaretskii  <address@hidden>

          * xdisp.c (move_it_in_display_line_to): Don't record wrap position
          if we are iterating over an object that generates glyphs for
          marginal areas.  (Bug#17585)

With the latest trunk, vertical motion in the foo.txt buffer created
by your recipe works OK interactively (i.e. by using arrow keys or
M-:); it didn't work correctly before.  Please try that after your
'test' function finishes.

Your test case, which uses vertical-motion non-interactively, indeed
still moves point horizontally as well, but that's because linum-mode
does its line number display in a post-command hook, so it defers the
initial display of the line numbers until _after_ vertical-motion did
its thing.  You can see that by inserting (sit-for 1) before each call
to vertical-motion.  So I think this is an unrelated problem; if it
gives you trouble in some real-life use case, please describe that use
case.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]