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

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

[Mark Lillibridge]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


    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 (watch what happens when you try to go to line
10) or widen, which reveals that the first line is actually line number
five.

The bug is the use by linum of line-number-at-pos,

linum.el:129:
(defun linum-update-window (win)
  "Update line numbers for the portion visible in window WIN."
  (goto-char (window-start win))
  (let ((line (line-number-at-pos))
  ...

<help for line-number-at-pos>:
line-number-at-pos is a compiled Lisp function in `simple.el'.

(line-number-at-pos &optional pos)

Return (narrowed) buffer line number at position pos.
If pos is nil, use current buffer location.
Counting starts at (point-min), so the value refers
to the contents of the accessible portion of the buffer.


A simple fix is to change the line:

linum.el:132:
  (let ((line (line-number-at-pos))

to:

  (let ((line (save-restriction
		(widen)
		(line-number-at-pos)))


- Mark

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

[Juanma Barranquero]

X-Debbugs-CC: markus.triska@gmx.at
quit

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

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

[Mark Lillibridge]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]


>  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

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

[Juanma Barranquero]

On Thu, Dec 10, 2009 at 06:34, Mark Lillibridge <mark.lillibridge@hp.com> wrote:

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

Well, there are many definitions of useful. I find the current
behavior useful, because my main use of linum is knowing at a glance
how many lines there are in the file (or in the region, if narrowing
is in effect).

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

Yes. But linum allows you to use line numbers in a quite more flexible
way. You could do

(defvar num-of-lines nil)
(defvar num-format nil)
(make-variable-buffer-local 'num-of-lines)
(make-variable-buffer-local 'num-format)

(add-hook 'linum-before-numbering-hook
          (lambda ()
            (save-restriction
              (widen)
              (let ((lines (count-lines (point-min) (point-max))))
                (setq num-format (format "%%%dd" (length
(int-to-string lines))))
                (setq num-of-lines (1+ lines))))))

(setq linum-format
      (lambda (line)
        (format num-format (- num-of-lines line))))

if you fancied numbering lines in reverse, for example.

    Juanma

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

[Mark Lillibridge]

Okay, let us see where we stand:

* Juanma uses linum mode to know how many lines there are in a file (or
  a region, if narrowing is in effect) at a glance; they do not use go
  to line.

* Mark (aka, me) and others specify lines to act on by reading off line
  numbers provided by linum and use goto-line to implement voice
  commands; it is crucial for this purpose that the line numbers
  provided correspond to the line numbers goto-line uses in all cases,
  including for non-current buffers.

* linum mode currently does what Juanma wants.

* A somewhat non-obvious and fragile hook function can convert the
  current mode into what Mark wants:

(add-hook 'linum-before-numbering-hook
	   (function (lambda ()
		       (setq line (save-restriction
				    (widen) (line-number-at-pos))))))
  
  (line here is a local variable of the linum-update-window, bound
  shortly before the hook is called; needless to say, this modification
  is unlikely to continue working as the linum code evolves.)

* I think you can build a less fragile hook by using a custom version of
  linum-format, however, this interferes with the ability to use
  linum-format for any other purpose.

* Both modes produce surprises: Juanma's causes surprises when goto-line
  goes to the wrong line in some buffers and Mark's causes surprises
  when some buffers start with a line number greater than one.  Using
  Juanma's mode plus changing the behavior of goto-line would produce no
  obvious surprises, but I cannot be sure that changing goto-line
  does not mess something else up.


    I think that given that Mark's mode is likely to be useful enough of
the time and that implementing it is nontrivial, especially for
beginners, there should be an explicit option to switch between the
modes.  The default should probably depend on which surprise people
think is worse.  I can live with either way.  I am willing to take a
stab at trying to implement such an option if people think this is a
good idea.

- Mark

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

[Juanma Barranquero]

On Mon, Dec 21, 2009 at 07:59, Mark Lillibridge <mark.lillibridge@hp.com> wrote:

>    I think that given that Mark's mode is likely to be useful enough of
> the time and that implementing it is nontrivial, especially for
> beginners, there should be an explicit option to switch between the
> modes.  The default should probably depend on which surprise people
> think is worse.  I can live with either way.

I agree, and don't really  care which one is default; I don't mind
having to customize it on .emacs (I already do).

> I am willing to take a
> stab at trying to implement such an option if people think this is a
> good idea.

Perhaps it'd be better to ask Markus first. I'm Cc:ing him (the first
time it didn't work).

    Juanma

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

[Drew Adams]

> > there should be an explicit option to switch between the modes.
> I agree, and don't really  care which one is default

Yes, an option makes sense.

And it can happen that the same person wants both behaviors at different times.
For that, why not let `C-u linum-mode' use, in effect, the opposite of the
option value?

IOW, if you set the option to use absolute numbering (per the file lines), and
you use `C-u linum-mode', then you get relative numbering instead (per the
visible lines). If you then exit the mode and reenter it (without `C-u'), you
get the default numbering (i.e., per the option value - absolute numbering in
this case).

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

[Mark Lillibridge]

Juanma wrote:
> Mark Lillibridge wrote:
> > I am willing to take a stab at trying to implement such an option if
> > people think this is a good idea.
> 
> Perhaps it'd be better to ask Markus first. I'm Cc:ing him (the first
> time it didn't work).

Ok.


Drew wrote:
>  > > there should be an explicit option to switch between the modes.
>  
>  Yes, an option makes sense.
>  
>  And it can happen that the same person wants both behaviors at
>  different times.  For that, why not let `C-u linum-mode' use, in
>  effect, the opposite of the option value?

    That might be a good idea.  Would an absolute override be better
than a toggle?  E.g., a positive prefix uses absolute and a negative
prefix uses relative to start of restriction.

- Mark

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

[Drew Adams]

> Drew wrote:
> >  > > there should be an explicit option to switch between the modes.
> >  
> >  Yes, an option makes sense.
> >  
> >  And it can happen that the same person wants both behaviors at
> >  different times.  For that, why not let `C-u linum-mode' use, in
> >  effect, the opposite of the option value?
> 
> That might be a good idea.  Would an absolute override be better
> than a toggle?  E.g., a positive prefix uses absolute and a negative
> prefix uses relative to start of restriction.

I don't think so. Given the option's value, there already is a default behavior,
which makes one of your cases unnecessary. IOW, there is no override for one of
the two possibilities - the default behavior already corresponds to the
requested one.

If a given user prefers, in general, to use absolute numbering or relative
numbering, then s?he would set the option to reflect that. Then s?he need only
use `C-u' for the minority of times when s?he wants the alternative behavior.

FWIW, I do this kind of thing in some of my own code. Given the ability to
customize the default behavior, I see no reason for also being able to specify
the _default_ behavior explicitly via a particular prefix arg.

If, on the other hand, you were anticipating non-interactive use, then I'd say
that in that case all that's needed is to let-bind the variable (option) to give
it the value you want currently.

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

[Mark Lillibridge]

Drew wrote:
>  Mark wrote:
>  > That might be a good idea.  Would an absolute override be better
>  > than a toggle?  E.g., a positive prefix uses absolute and a negative
>  > prefix uses relative to start of restriction.
>  
>  I don't think so. Given the option's value, there already is a
>  default behavior, which makes one of your cases unnecessary. IOW,
>  there is no override for one of the two possibilities - the default
>  behavior already corresponds to the
>  requested one.
>  
>  If a given user prefers, in general, to use absolute numbering or
>  relative numbering, then s?he would set the option to reflect
>  that. Then s?he need only use `C-u' for the minority of times when
>  s?he wants the alternative behavior.
>  
>  FWIW, I do this kind of thing in some of my own code. Given the
>  ability to customize the default behavior, I see no reason for also
>  being able to specify the _default_ behavior explicitly via a
>  particular prefix arg.
>  
>  If, on the other hand, you were anticipating non-interactive use,
>  then I'd say that in that case all that's needed is to let-bind the
>  variable (option) to give it the value you want currently.

Ok.  

- Mark

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

[Stefan Monnier]

>> > there should be an explicit option to switch between the modes.
>> I agree, and don't really  care which one is default
> Yes, an option makes sense.
> And it can happen that the same person wants both behaviors at
> different times.

Indeed.  This goes back to the ambiguity of `narrow-to-region', which
can be used either to "pretend the rest of the buffer doesn't exist" (as
was used in Rmail for example), or to "temporarily focus on some
particular part of the buffer without pretending the rest doesn't
exist".


        Stefan

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

[Kevin Rodgers]

Stefan Monnier wrote:
>>>> there should be an explicit option to switch between the modes.
>>> I agree, and don't really  care which one is default
>> Yes, an option makes sense.
>> And it can happen that the same person wants both behaviors at
>> different times.
> 
> Indeed.  This goes back to the ambiguity of `narrow-to-region', which
> can be used either to "pretend the rest of the buffer doesn't exist" (as
> was used in Rmail for example), or to "temporarily focus on some
> particular part of the buffer without pretending the rest doesn't
> exist".

Should there be a separate function for "temporarily focus on some
particular part of the buffer without pretending the rest doesn't
exist"?  e.g. narrow-window-to-region

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Mark Lillibridge]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]


Markus?  We appear to be waiting on your opinion.
- Mark


>  On Mon, Dec 21, 2009 at 07:59, Mark Lillibridge <mark.lillibridge@hp.com> wrote:
>  
>  >    I think that given that Mark's mode is likely to be useful enough of
>  > the time and that implementing it is nontrivial, especially for
>  > beginners, there should be an explicit option to switch between the
>  > modes.  The default should probably depend on which surprise people
>  > think is worse.  I can live with either way.
>  
>  I agree, and don't really  care which one is default; I don't mind
>  having to customize it on .emacs (I already do).
>  
>  > I am willing to take a
>  > stab at trying to implement such an option if people think this is a
>  > good idea.
>  
>  Perhaps it'd be better to ask Markus first. I'm Cc:ing him (the first
>  time it didn't work).
>  
>      Juanma
>  

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

[Markus Triska]

Mark Lillibridge <mark.lillibridge@hp.com> writes:

>  waiting on your opinion.

In my opinion, a more general solution than only for linum.el would be
best, one that also makes for example line-number-mode show line numbers
that work as expected with M-x goto-line RET also for narrowed buffers.
Ideally, it should work without having to customize each of these
features (and new modes in the future) separately. I think a promising
suggestion (found in this thread) is to generalise narrowing itself,
possibly with a single new customization option instead of many.

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

[Mark Lillibridge]

Markus wrote:
>  In my opinion, a more general solution than only for linum.el would be
>  best, one that also makes for example line-number-mode show line numbers
>  that work as expected with M-x goto-line RET also for narrowed buffers.
>  Ideally, it should work without having to customize each of these
>  features (and new modes in the future) separately. I think a promising
>  suggestion (found in this thread) is to generalise narrowing itself,
>  possibly with a single new customization option instead of many.

    That's a good idea.  We could add a buffer local variable that
determines how to number lines when a restriction is in effect.  Rmail,
Info, and similar modes could set this variable for their buffers to
start numbering the visible restriction at 1.  Other buffers would
depend on the user's global customization setting.  goto-line, linum,
and related features would consult this variable.

    I don't know any good arguments for which way to set the global
default.


    What do people think of this plan?  The alternative KISS strategy is
to just make line numbering always start with one for restrictions; I
think this makes everybody happy.  The downside is that you can't see
the external line numbers of lines while you have restricted the buffer
and you can't go to lines by their external line number while you have
restricted the buffer.  I, at least, don't use narrow (interactively)
enough that that these drawbacks would matter.

- Mark

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

[Juanma Barranquero]

On Sun, Jan 10, 2010 at 02:32, Mark Lillibridge <mark.lillibridge@hp.com> wrote:

>    That's a good idea.  We could add a buffer local variable that
> determines how to number lines when a restriction is in effect.

I agree. (Post-release, of course.)

>    I don't know any good arguments for which way to set the global
> default.

Same here.

    Juanma

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

[Mark Lillibridge]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]


Juanma wrote:
> On Sun, Jan 10, 2010 at 02:32, Mark Lillibridge
> <mark.lillibridge@hp.com> wrote:
> 
> >    That's a good idea.  We could add a buffer local variable that
> > determines how to number lines when a restriction is in effect.
> 
> I agree. (Post-release, of course.)

    Okay, I will start working on an implementation of this.  Is there a
document somewhere on the preferred method for doing this?  E.g., pull
from the repository, edit, and post diffs?  

- Thanks,
  Mark

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

[Juanma Barranquero]

On Sat, Jan 16, 2010 at 23:08, Mark Lillibridge <mark.lillibridge@hp.com> wrote:

>    Okay, I will start working on an implementation of this.  Is there a
> document somewhere on the preferred method for doing this?  E.g., pull
> from the repository, edit, and post diffs?

Yes, that will work.

    Juanma

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

[Mark Lillibridge]

    Ok, I have pulled the source code from the CVS repository and I'm
starting to work on the new feature/bug fix.

    We are creating a new variable that determines whether or not to
restart numbering lines at the start of a restriction.  I suggest
calling this "restart-numbering-restriction" with possible values t and
nil (=false).  Is this naming convention/description okay?


    Second, this should clearly be a customizable variable, thus created
with defcustom in some group.  The question is, which group?  Some quick
browsing with M-x customize suggests the reasonable possibilities are:

   emacs > convenience > Linum
     "Show line numbers in the left margin."

   emacs > editing > editing basics group
     "most basic editing facilities."

The first group here really seems to only be for Linum features, which
this is not.  It does look like a reasonable place a a user might
search/discover this option.  I'm not sure if I can declare a variable
in that group without actually requiring Linum to be loaded first.

What do people think?
- Mark


(defcustum restart-numbering-restriction nil
    "How should the lines of a restriction be numbered?  Normally, they receive the same line numbers as if no restriction existed (e.g., if the first line of the restriction is line number 10 of the file then it receives line number 10.  If this variable is true, the lines of the restriction are instead numbered from 1."
    :group ???
    :type  '(boolean))

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

[Drew Adams]

> What do people think?

I think that the proper place to propose and discuss a potential Emacs
enhancement is emacs-devel@gnu.org, not in a specific (though relevant) bug
thread. 

There is no reason to manage this in the bug tracker, and no reason not to
manage (and archive) it in the normal discussion list.

Just one opinion.

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

[Mark Lillibridge]

>  > What do people think?
>  
>  I think that the proper place to propose and discuss a potential Emacs
>  enhancement is emacs-devel@gnu.org, not in a specific (though relevant) bug
>  thread. 
>  
>  There is no reason to manage this in the bug tracker, and no reason not to
>  manage (and archive) it in the normal discussion list.
>  
>  Just one opinion.

Good point.  I will move the discussion there.

- Mark

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

[Juanma Barranquero]

On Sun, Jan 24, 2010 at 00:28, Mark Lillibridge <mark.lillibridge@hp.com> wrote:

> I suggest
> calling this "restart-numbering-restriction" with possible values t and
> nil (=false).  Is this naming convention/description okay?

The name is OK, I think.

>   emacs > editing > editing basics group
>     "most basic editing facilities."
>
> The first group here really seems to only be for Linum features, which
> this is not.  It does look like a reasonable place a a user might
> search/discover this option.  I'm not sure if I can declare a variable
> in that group without actually requiring Linum to be loaded first.

Not in the linum group, no. This is not dependend on linum (though it
would use the variable); editing basics seems reasonable.

> (defcustum restart-numbering-restriction nil
>    "How should the lines of a restriction be numbered?  Normally, they receive the same line numbers as if no restriction existed (e.g., if the first line of the restriction is line number 10 of the file then it receives line number 10.  If this variable is true, the lines of the restriction are instead numbered from 1."
>    :group ???
>    :type  '(boolean))

More like this, I'd say:

(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 ???
  :type  'boolean)


    Juanma

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

[Lennart Borgman]

On Sun, Jan 10, 2010 at 2:32 AM, Mark Lillibridge
<mark.lillibridge@hp.com> wrote:
>
>    That's a good idea.  We could add a buffer local variable that
> determines how to number lines when a restriction is in effect.  Rmail,
> Info, and similar modes could set this variable for their buffers to
> start numbering the visible restriction at 1.  Other buffers would
> depend on the user's global customization setting.  goto-line, linum,
> and related features would consult this variable.
>
>    I don't know any good arguments for which way to set the global
> default.


External utilities will use the whole file. So if the file is to be
touched by external utilities (like grep) then I think  the default
should be to start numbering from the file's beginning.