Perhaps a bug in line-move-1

Perhaps a bug in line-move-1

[David PONCE]

Hello,

Since this change to line-move-1 in simple.el:

2005-06-23  Richard M. Stallman  <rms@gnu.org>

	* simple.el (set-variable): Args renamed; doc fix.
	(line-move-1): When there are overlays around, use
	vertical-motion.


When I use the up/down button to move the cursor to the previous/next
line, it actually move it up/down 2 lines.  I looked at the
implementation and it seems that when there are overlays around the
text moved over (which is the case in buffers where semantic is
enabled), the code unconditionally calls forward-line, then
`vertical-motion', which looks like a bug.

The following patch seems to have fixed the problem.

Hope it will help.
Sincerely,
David

Index: simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.733
diff -c -r1.733 simple.el
*** simple.el	23 Jun 2005 21:26:31 -0000	1.733
--- simple.el	24 Jun 2005 14:11:36 -0000
***************
*** 3442,3455 ****
  		  (when (and (not done)
  			     (not (integerp selective-display))
  			     (not (line-move-invisible-p (point))))
- 		    ;; We avoid vertical-motion when possible
- 		    ;; because that has to fontify.
- 		    (forward-line 1)
  		    ;; If there are overlays in and around
  		    ;; the text we moved over, we need to be
  		    ;; sophisticated.
  		    (unless (overlays-in (max (1- pos-before) (point-min))
  					 (min (1+ (point)) (point-max)))
  		      (setq line-done t)))
  		  ;; Otherwise move a more sophisticated way.
  		  ;; (What's the logic behind this code?)
--- 3442,3455 ----
  		  (when (and (not done)
  			     (not (integerp selective-display))
  			     (not (line-move-invisible-p (point))))
  		    ;; If there are overlays in and around
  		    ;; the text we moved over, we need to be
  		    ;; sophisticated.
  		    (unless (overlays-in (max (1- pos-before) (point-min))
  					 (min (1+ (point)) (point-max)))
+ 		      ;; We avoid vertical-motion when possible
+ 		      ;; because that has to fontify.
+ 		      (forward-line 1)
  		      (setq line-done t)))
  		  ;; Otherwise move a more sophisticated way.
  		  ;; (What's the logic behind this code?)
***************
*** 3473,3481 ****
  		  (when (and (not done)
  			     (not (integerp selective-display))
  			     (not (line-move-invisible-p (1- (point)))))
- 		    (forward-line -1)
  		    (unless (overlays-in (max (1- (point)) (point-min))
  					 (min (1+ pos-before) (point-max)))
  		      (setq line-done t)))
  		  (and (not done) (not line-done)
  		       (zerop (vertical-motion -1))
--- 3473,3481 ----
  		  (when (and (not done)
  			     (not (integerp selective-display))
  			     (not (line-move-invisible-p (1- (point)))))
  		    (unless (overlays-in (max (1- (point)) (point-min))
  					 (min (1+ pos-before) (point-max)))
+ 		      (forward-line -1)
  		      (setq line-done t)))
  		  (and (not done) (not line-done)
  		       (zerop (vertical-motion -1))

Re: Perhaps a bug in line-move-1

[Richard M. Stallman]

Thanks.