[debbugs-tracker] bug#15090: closed (linum-mode and visual-line-mode (both defaults) have conflicting behavior)

[GNU bug Tracking System]

Your message dated Thu, 15 Aug 2013 18:22:26 +0300
with message-id <address@hidden>
and subject line Re: bug#15090: linum-mode and visual-line-mode (both defaults) 
have    conflicting behavior
has caused the debbugs.gnu.org bug report #15090,
regarding linum-mode and visual-line-mode (both defaults) have conflicting 
behavior
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
15090: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15090
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: linum-mode and visual-line-mode (both defaults) have conflicting behavior Date: Tue, 13 Aug 2013 15:52:53 -0500

When you set:

(global-visual-line-mode 1)

(global-linum-mode 1)

you sometimes get weird behavior.  If the [visual] line at the top of your window is not completely visible (i.e. some parts of it lie above your screen), you can sometimes trigger horizontal movement in that top line by performing random commands: moving, inserting text.  Most consistently (though not always), I've been able to do cause this behavior by scrolling down when my cursor is at the end of a file.

I am pretty sure this happens when linum "updates" the line number of the topmost line.  The problem only occurs during a linum-update, and after my workaround, that top line number is no longer visible.

Workaround (I'm not really sure it fixes the underlying problem):

Change the first line in function "linum-update-window" (I believe: linum.el, line 134) from:

  (goto-char (window-start win))

to:

  (goto-char (1- (window-start win)))

or, with indexing check:

(goto-char (let ((first-char (window-start win)))

                 (if (> first-char (point-min))

                     (1- first-char)

                     first-char)))

Partial Rationale: I knew that lines after the starting point didn't have this problem, so I was trying to make it start at the previous line.  It turns out that starting at the previous character fixes it.  I don't really know why.

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#15090: linum-mode and visual-line-mode (both defaults) have	conflicting behavior
>
>
>
>
> Date: 
>
> Thu, 15 Aug 2013 18:22:26 +0300
>
>
>
>
> > Date: Wed, 14 Aug 2013 22:47:37 -0500
> > From: Dave Kepler <address@hidden>
> > 
> > My apologies, that was a pretty serious omission.  My emacs version was
> > 24.3.1.  I've just tried it with trunk and -Q, and I think I found a
> > reliable way to duplicate it.
> > 
> > 1. emacs -Q, you start with a scratch file. Delete the text in the scratch
> > file.
> > 
> > 2. Paste the following string, not including quotations:
> > 
> > "abc def ghi jkl mno pqr stu vwz yzabc def ghi jkl mno pqr stu vwz yzabc
> > def ghi jkl mno pqr stu vwz yzabc def ghi jkl mno pqr stu vwz yzabc def ghi
> > jkl mno pqr stu vwz yzabc def ghi jkl mno pqr stu vwz yzabc def ghi jkl mno
> > pqr stu vwz yzabc def ghi jkl mno pqr abc def ghi jkl mno pqr stu vwz yzabc
> > def ghi jkl mno pqr stu vwz yzabc def ghi jkl mno pqr stu vwz yzabc def ghi
> > jkl mno pqr stu vwz yzabc def ghi jkl mno pqr stu vwz yzabc def ghi jkl mno
> > pqr stu vwz yzabc def ghi jkl mno pqr stu vwz yzabc def ghi jkl mno pqr
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > "
> > 
> > The exact string should not matter, but:
> > a. The top line should be many short words.  It should be long enough to
> > perform step 3.
> > b. It should be followed by many empty lines
> > 
> > 3. Scroll down so that the top of your window breaks that top line.  That
> > is, part of the top line should be above your window, so that you are only
> > able to see the ending of the top line.
> > 
> > 4. M-x linum-mode
> > 
> > 5. M-x visual-line-mode
> > 
> > 6. Move point to the end of the top line, and type anything
> > 
> > 
> > 
> > What should happen: the text in the topmost part of the top line is unmoved
> > as you append text to the end of line
> > 
> > What does happen: the text in the topmost part of the top line will move
> > horizontally as you append text.
> > 
> > 
> > Note: when I try creating a new file rather than using scratch, this bug
> > does not happen when I append to the end of the top line.  Rather, it
> > happens when I scroll using mouse.  If the bug duplication does not work as
> > planned, please also try the following for step 6:
> > 
> > a. Scrolling with mouse
> > b. Appending text far below the top line
> > c. Moving point downward while at EOF
> > 
> > while watching the top line.  Hopefully, my duplication instructions will
> > work, however.
>
> Thanks.  This is a very old bug, now fixed in trunk revision 113889.
>
> The reason was that we were computing the window start point
> incorrectly in this situation.
>
>
> --- End Message ---