GNU bug report logs - #13446
24.2; Fix loop test in linum.el

Previous Next

Full log

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

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13446 <at> debbugs.gnu.org
Subject: Re: bug#13446: 24.2; Fix loop test in linum.el
Date: Sun, 27 Oct 2013 15:36:07 -0400

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 <at> 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.

Previous Next

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