unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior
@ 2013-08-13 20:52 Dave Kepler
  2013-08-13 21:33 ` Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Dave Kepler @ 2013-08-13 20:52 UTC (permalink / raw)
  To: 15090

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1753 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior
  2013-08-13 20:52 bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior Dave Kepler
@ 2013-08-13 21:33 ` Stefan Monnier
  2013-08-14  2:51 ` Eli Zaretskii
  2013-08-15  3:47 ` Dave Kepler
  2 siblings, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2013-08-13 21:33 UTC (permalink / raw)
  To: Dave Kepler; +Cc: 15090

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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior
  2013-08-13 20:52 bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior Dave Kepler
  2013-08-13 21:33 ` Stefan Monnier
@ 2013-08-14  2:51 ` Eli Zaretskii
  2013-08-15  3:47 ` Dave Kepler
  2 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2013-08-14  2:51 UTC (permalink / raw)
  To: Dave Kepler; +Cc: 15090

> Date: Tue, 13 Aug 2013 15:52:53 -0500
> From: Dave Kepler <lalop.lmao@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.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior
  2013-08-13 20:52 bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior Dave Kepler
  2013-08-13 21:33 ` Stefan Monnier
  2013-08-14  2:51 ` Eli Zaretskii
@ 2013-08-15  3:47 ` Dave Kepler
  2013-08-15 15:22   ` Eli Zaretskii
  2 siblings, 1 reply; 5+ messages in thread
From: Dave Kepler @ 2013-08-15  3:47 UTC (permalink / raw)
  To: 15090

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2578 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior
  2013-08-15  3:47 ` Dave Kepler
@ 2013-08-15 15:22   ` Eli Zaretskii
  0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2013-08-15 15:22 UTC (permalink / raw)
  To: Dave Kepler; +Cc: 15090-done

> Date: Wed, 14 Aug 2013 22:47:37 -0500
> From: Dave Kepler <lalop.lmao@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.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-08-15 15:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-13 20:52 bug#15090: linum-mode and visual-line-mode (both defaults) have conflicting behavior Dave Kepler
2013-08-13 21:33 ` Stefan Monnier
2013-08-14  2:51 ` Eli Zaretskii
2013-08-15  3:47 ` Dave Kepler
2013-08-15 15:22   ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).