bug#5042: 23.1; linum-mode gives incorrect line numbers with narrowed buffers

[Mark Lillibridge]

>  On Thu, Nov 26, 2009 at 01:39, Mark Lillibridge <mark.lillibridge@hp.com> 
> wrote:
>  
>  > Â  Â Linum-mode does not work correctly with buffers that have been
>  > narrowed. Â As a simple example, type ^h i. Â You will note that the first
>  > line is assigned line number one. Â You can verify that this is wrong
>  > either by using goto-line
>  
>  Let's hear Markus' opinion, but IMHO that's not necessarily a bug.
>  Linum's function is to add line numbers, but these do not have to
>  correspond to buffer lines. For example, nothing stops you from doing
>  
>    (defvar my-num 1000)
>    (make-variable-buffer-local 'my-num)
>  
>    (setq linum-format (lambda (n) (format "%4d" (+ n my-num))))
>  
>  
>      Juanma

    The entire point of having line numbers is that they correspond to
something useful.  Either an external program's line number (e.g., a gcc
error number) or an internal Emacs notion such as that provided by
goto-line.  The current behavior does neither.

    Note that other line numbering modes like wb-line-number implement
the behavior that I describe as correct.

    I cannot see any useful circumstance where linum and goto-line
should disagree about what line number a given line has.  I can see an
argument that some buffers like RMAIL and info might want to start
numbering lines at one for the visible part of the buffer; I see this as
a possible feature request where say a buffer local variable specifies
this behavior.

    Note that that feature might be hard to implement correctly because
there is no hook for changing the buffer restriction visible to the
user.  That is, even if you believe that feature should be the
default/only behavior, the current code is still broken because changing
the restriction does not update the line numbers correctly.

- Mark