bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Christoph Scholtes]

Start with emacs -Q.
Don't maximize frame.
Open a file that has more lines than the current frame.
M-x linum-mode
Maximize frame.
Line numbers are only drawn where the original, visible frame boundary
was.
Press down arrow key.
Line numbers are redrawn for the entire frame.

The same thing happens when narrowing on a function and then widen
again.  Only the narrowed piece has the new line numbers until the next
explicit redraw.


In GNU Emacs 24.1.50.1 (i386-mingw-nt6.1.7601)
 of 2012-05-16 on MARVIN
Bzr revision: 108249 eggert@cs.ucla.edu-20120516022253-altheqksrkjfoosr
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Stefan Monnier]

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

> Start with emacs -Q.
> Don't maximize frame.
> Open a file that has more lines than the current frame.
> M-x linum-mode
> Maximize frame.
> Line numbers are only drawn where the original, visible frame boundary
> was.
> Press down arrow key.
> Line numbers are redrawn for the entire frame.

> The same thing happens when narrowing on a function and then widen
> again.  Only the narrowed piece has the new line numbers until the next
> explicit redraw.

You may have more luck with my reimplementation of linum which uses
jit-lock, which hopefully fixes those problems (tho it may come with
others of course).


        Stefan

[-- Attachment #2: nlinum.el --]
[-- Type: application/emacs-lisp, Size: 4183 bytes --]

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Christoph Scholtes]

On 5/16/2012 8:40 PM, Stefan Monnier wrote:

> You may have more luck with my reimplementation of linum which uses
> jit-lock, which hopefully fixes those problems (tho it may come with
> others of course).

Sweet! Works like it should. Thank you. :)

Would it be hard to add the "relative line number" feature with your 
code? Like this:

4 foo
3 bar
2 foo
1 baz
0 -> point
1 foo
2 bla
3 zupp

I used vim recently and found this pretty handy to move around with 
prefix arguments.

Thanks,
Christoph

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Stefan Monnier]

> Would it be hard to add the "relative line number" feature with your code?

Depends on how badly you want it and how reliable you want it.
`jit-lock' is not triggered by mere cursor movement, so you need to use
another hook to detect when we move to another line, after which you'll
have to flush all the nlinum overlays and recompute them, and since we
want jit-lock to recompute them (so that all (but only) visible parts of
the buffer get recomputed), that means telling jit-lock to redo the
buffer, which will make it re-font-lock as well.
So it'll be a bit costly.

IOW, you need to hook into nlinum.el's display so it puts relative
numbers (easy), and then add something like

  (add-hook 'post-command-hook
    (lambda () (if (current-line-number-changed-p)
                   (remove-text-properties (point-min) (point-max)
                   '(fontified nil)))))

And of course, post-command-hook will not always be sufficient.


        Stefan


PS: And of course, there's the problem (also present in the linum.el hack)
that the cursor position is a window-property so when the buffer is
shown in various windows the relative line numbers may not make that
much sense in other buffers.  So maybe you'd really want this relative
numbering to be different for every window.

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Juanma Barranquero]

On Thu, May 17, 2012 at 4:40 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> You may have more luck with my reimplementation of linum which uses
> jit-lock, which hopefully fixes those problems (tho it may come with
> others of course).

The first one is that it displays the line numbers using only as many
columns as needed for the largest line number it has already shown; it
does not take into account the number of lines in the buffer. This is
quite noticeable, for example, in

  emacs -Q -f view-emacs-news -f linum-mode

vs.

  emacs -Q -f view-emacs-mode -l nlinum -f nlinum-mode

Also, linum mode's linum-before-numbering-hook and linum-format are
quite useful for non-standard line numbering. Equivalent functionality
would be nice.

    Juanma

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Stefan Monnier]

> The first one is that it displays the line numbers using only as many
> columns as needed for the largest line number it has already shown; it
> does not take into account the number of lines in the buffer.

Yes, that's a difference.  I don't see why it would be considered a problem.

> Also, linum mode's linum-before-numbering-hook and linum-format are
> quite useful for non-standard line numbering. Equivalent functionality
> would be nice.

;-)


        Stefan

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You may have more luck with my reimplementation of linum which uses
> jit-lock, which hopefully fixes those problems (tho it may come with
> others of course).

A question:

Why doesn't linum-mode (nor anything else) use
`window-text-change-functions', since that hook was added specifically
to support linum?

(See old threads in emacs-devel.)

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[martin rudalics]

 > Start with emacs -Q.
 > Don't maximize frame.
 > Open a file that has more lines than the current frame.
 > M-x linum-mode
 > Maximize frame.
 > Line numbers are only drawn where the original, visible frame boundary
 > was.
 > Press down arrow key.
 > Line numbers are redrawn for the entire frame.

A trivial bug: linum should run `linum-after-config' when the window
configuration changes.

 > The same thing happens when narrowing on a function and then widen
 > again.  Only the narrowed piece has the new line numbers until the next
 > explicit redraw.

That's a different issue.

martin

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[martin rudalics]

 > A trivial bug: linum should run `linum-after-config' when the window
 > configuration changes.

I was misguided.  While linum should update all windows when the window
configuration changes, it won't help in this specific case.

martin

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Eli Zaretskii]

> Date: Thu, 17 May 2012 12:12:10 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 11496@debbugs.gnu.org
> 
>  > A trivial bug: linum should run `linum-after-config' when the window
>  > configuration changes.
> 
> I was misguided.  While linum should update all windows when the window
> configuration changes, it won't help in this specific case.

It looks like some problem with redisplay, or maybe linum-mode is not
forcing redisplay when it should.  In any case, similar problems exist
in Emacs 23.3, so this is not exactly a regression.  I will try to
take a closer look when I have time (it's tricky to debug this because
any command that causes redisplay makes the problem disappear).  Ideas
are welcome.

bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

[Stefan Monnier]

>> > A trivial bug: linum should run `linum-after-config' when the window
>> > configuration changes.
>> I was misguided.  While linum should update all windows when the window
>> configuration changes, it won't help in this specific case.
> It looks like some problem with redisplay, or maybe linum-mode is not
> forcing redisplay when it should.  In any case, similar problems exist
> in Emacs 23.3, so this is not exactly a regression.  I will try to
> take a closer look when I have time (it's tricky to debug this because
> any command that causes redisplay makes the problem disappear).  Ideas
> are welcome.

I wouldn't waste too much time on it: linum.el suffers from the same
kinds of problems as lazy-lock because it similarly combines several
"somewhat related" hooks to try and cover most cases.
I think that using jit-lock is a much better way to go about it since
that hook is much better focused, hence my nlinum.el rewrite.


        Stefan