bug#13446: 24.2; Fix loop test in linum.el

[Nathan Trapuzzano <nbtrap@nbtrap.com>]

The behavior you describe is actually doable using a combination of
`linum-before-numbering-hook' and `linum-format'.  (In particular, I'm
talking about setting `linum-format' to a symbol, which will cause linum
to call the function with that symbol's name to retrieve the line number
as a string.)  I know because I've implemented it, or something very
similar to it, myself.

Indeed, given these two variables, linum is actually very capable.  On
the other hand, one seeminly irreparable problem with linum is _when_ it
applies the overlays--or when it doesn't.  I'm not sure if there's a bug
report for this, but faily often linum won't display the overlays at
all, or will only display the line numbers on some of the lines in the
window.  This happens especially frequently when bouncing on balanced
parens/brackets via `forward-' and `backward-sexp'.  If something is
going to replace linum, I'd be very interested to know whether it fixes
this problem.  Do you happen to know?

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

> BTW, in nlinum-mode, the default behavior is half-way between the two:
> we don't try to accommodate the largest line number there can be
> (partly to avoid scanning the whole buffer, which can be a performance
> problem in itself), so we grow the margin only when we display a larger
> number, but we don't shrink it back when moving back to the beginning of
> the file with shorter line numbers.