GNU bug report logs - #15090
linum-mode and visual-line-mode (both defaults) have conflicting behavior

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15090 in the body.
You can then email your comments to 15090 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dave Kepler <lalop.lmao <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: linum-mode and visual-line-mode (both defaults) have conflicting
 behavior
Date: Tue, 13 Aug 2013 15:52:53 -0500

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Message #8 received at 15090 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dave Kepler <lalop.lmao <at> gmail.com>
Cc: 15090 <at> debbugs.gnu.org
Subject: Re: bug#15090: linum-mode and visual-line-mode (both defaults) have
 conflicting behavior
Date: Tue, 13 Aug 2013 17:33:55 -0400

Thanks for your report and for providing a workaround/fix.
Just for the sake of it, do you see the same kind of problems with nlinum
(available via list-packages / package-install)?


        Stefan

Message #11 received at 15090 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dave Kepler <lalop.lmao <at> gmail.com>
Cc: 15090 <at> debbugs.gnu.org
Subject: Re: bug#15090: linum-mode and visual-line-mode (both defaults)
 have	conflicting behavior
Date: Wed, 14 Aug 2013 05:51:37 +0300

> Date: Tue, 13 Aug 2013 15:52:53 -0500
> From: Dave Kepler <lalop.lmao <at> gmail.com>
> 
> 
> [1:text/plain Hide]
> 
> When you set:
> 
> (global-visual-line-mode 1)
> (global-linum-mode 1)
> 
> you sometimes get weird behavior.

You didn't say in what version of Emacs does this happen, and didn't
use "M-x report-emacs-bug" (which would have collected that
information for you).

If this is not in the latest trunk, then please try the latest
development trunk if you can.  If the trunk version also has this
problem, I'd appreciate a minimal reproduction recipe starting with
"emacs -Q".

Thanks.

Message #14 received at 15090 <at> debbugs.gnu.org (full text, mbox):

From: Dave Kepler <lalop.lmao <at> gmail.com>
To: 15090 <at> debbugs.gnu.org
Subject: Re: bug#15090: linum-mode and visual-line-mode (both defaults) have
 conflicting behavior
Date: Wed, 14 Aug 2013 22:47:37 -0500

[Message part 1 (text/plain, inline)]

I forgot to CC this to the bugtracker yesterday.  Another rookie mistake :{

=========

From: Dave Kepler <lalop.lmao <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Date: Tue, 13 Aug 2013 23:43:59 -0500

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 for your patience,
Dave

[Message part 2 (text/html, inline)]

Message #19 received at 15090-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dave Kepler <lalop.lmao <at> gmail.com>
Cc: 15090-done <at> debbugs.gnu.org
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 <lalop.lmao <at> gmail.com>
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.