Emacs's handling of line numbers [from bug#5042]

[Mark Lillibridge]

[Moved here from bug tracker bug #5042; subject line was "RE: bug#5042:
23.1;linum-mode gives incorrect line numbers with  narrowed buffers"]


    Gnu emacs's assignment of line numbers to lines is inconsistent when
a buffer is narrowed:

  * goto-line and (not part of standard emacs) wb-line-number.el always
    starts numbering lines from the start of the buffer

but,

  * line-number-at-pos and linum mode start numbering lines from
    (point-min) so a given line's line number depends on what
    restriction (if any) is in effect at the moment.

This has a number of bad consequences; perhaps most importantly, it is
not possible to reliably jump to a on-screen line using goto-line and
its displayed line number.  (This is a crucial primitive for
controlling emacs via voice.)


    After some discussion on the bug tracker list, it was agreed that
all of these functions should be made consistent.  Because both methods
of numbering lines have defenders and uses:

  * always numbering from the start of the buffer makes it easy to see
    that you're in a restriction and to compare to external line numbers
    (e.g., as produced by gcc)

  * numbering from the start of a restriction makes it easy to see how
    big the restriction is; it also makes modes like Rmail or info have
    "normal" line numbers.  (Otherwise, you get counterintuitive effects
    like Rmail messages starting with line number 242634.)

the consensus was that the method of line numbering should be
customizable/settable on a per buffer basis.  


    To be concrete, the current proposal is to add something like:

(defcustom restart-numbering-restriction nil
  "If true, lines inside a restriction are numbered starting from 1.
If false, line numbers correspond to position inside the buffer."
  :group 'editing-basics
  :type  'boolean)

goto-line, line-number-at-pos, and linum mode would then use the current
value of this variable to decide how to number lines.  Modes like Rmail
and info would make this variable buffer local and set it to t.

    There was no strong consensus on the default value for this variable
other than that no one felt strongly about its value.  A weak
preference was expressed for nil.

    Opinions?  If this proposal is acceptable, I volunteer to produce a
draft patch implementing it.

- Mark