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

[Mark Lillibridge <mark.lillibridge@hp.com>]

In an attempt to make progress on this bug, I propose the following:

* all the relevant proposals require {esc}g to move by the line number
  shown by linum mode if it were on.  (they disagree about which
  numbering scheme(s) linum should use.)

* this means we need to redefine the behavior of {esc}g

* {esc}g currently calls goto-line, but a grep through the elisp sources
  of Emacs shows a lots of calls to goto-line, any of which might be
  broken by changing the behavior of goto-line

* Accordingly, I suggest introducing a new function, goto-numbered-line,
  which will replace the binding of {esc}g and the edit menu option.

* the current documentation for goto-line is:

    (goto-line line &optional buffer)
    
    Goto line, counting from line 1 at beginning of buffer.  Normally,
    move point in the current buffer, and leave mark at the previous
    position.  With just C-u as argument, move point in the most
    recently selected other buffer, and switch to it.  When called from
    Lisp code, the optional argument buffer specifies a buffer to switch
    to.
    
    If there's a number in the buffer at point, it is the default for
    line.

* I propose documentation for goto-numbered-line as:

    (goto-numbered-line line &optional buffer)
    
    Goto line with line number line; use linum mode to see what line
    numbers each line is assigned.
    Normally, move point in the current buffer, and leave mark at the
    previous position.  With just C-u as argument,
    move point in the most recently selected other buffer, and switch
    to it.  When called from Lisp code, the optional argument buffer
    specifies a buffer to switch to.
    
    If there's a number in the buffer at point, it is the default for
    line.

* for the initial implementation, goto-numbered-line would effectively
  be a copy of goto-line without the widening function.  (This is what
  linum mode currently does.)  Later, if we change how linum assigns
  line numbers, we can change goto-number-line in parallel.

What do people think?  This resolves the bug ({esc}g and linum numbering
lines differently) without forcing us to make a hard decision on exactly
how linum should number lines first.  

- Mark




I (Mark Lillibridge) wrote:  
>  Eli Zaretskii <eliz@gnu.org> wrote:
>  >  Mark Lillibridge <mark.lillibridge@hp.com> wrote:
>  >  >     The issue is that font-lock mode, goto-line, linum mode, and perhaps
>  >  > other features need to treat them differently.  These features want to
>  >  > widen to the "application" restriction when processing the current
>  >  > buffer, ignoring any temporary restriction.
>  >  
>  >  But if this is the problem you want to solve, you cannot solve it by
>  >  introducing yet another kind of restriction: there's always a chance
>  >  that a command will want to use the "application" restriction, when
>  >  one is already in place, because, e.g., you have font-lock or whatever
>  >  active.  And then you are back at the same problem.
>  >  
>  >  IOW, by introducing 2 kinds of restriction, you don't solve the
>  >  problem, you just push it a bit farther.
>  >  
>  >  Moreover, I'm not sure I see the problem that is grave enough to
>  >  justify this.  The 3 examples you mentioned can be solved by
>  >  programming the features to do what you want (I believe font-lock
>  >  already solved it, albeit not too elegantly).  I understand now the
>  >  difference between two classes of use of restriction (thanks to all
>  >  who labored to explain that to this old fart), but are there
>  >  _practical_ use-cases where the current situation gets in our way so
>  >  badly that such a new feature would be justified?  I wonder.
>  
>      Personally, the problem I need fixed is that goto-line and linum
>  mode number lines inconsistently.  Given that linum mode already numbers
>  the first line of a restriction starting with one and Info mode looks weird
>  if we start numbering at the beginning of the physical buffer, I think
>  the minimal change would be to change goto-line to number lines so that
>  the first line of the current restriction is 1.  
>  
>      Some wanted an option to control whether line numbers were numbered
>  from the beginning of the restriction or the beginning of the physical
>  buffer and some (others?) to solve this problem (which characters really
>  belong to the (logical) buffer) once and for all.