GNU bug report logs - #5042
23.1; linum-mode gives incorrect line numbers with narrowed buffers

Previous Next

To reply to this bug, email your comments to 5042 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; linum-mode gives incorrect line numbers with narrowed buffers
Date: Wed, 25 Nov 2009 16:39:29 -0800

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

Message #10 received at 5042 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: mark.lillibridge <at> hp.com
Cc: 5042 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Tue, 1 Dec 2009 01:32:26 +0100

X-Debbugs-CC: markus.triska <at> gmx.at
quit

On Thu, Nov 26, 2009 at 01:39, Mark Lillibridge <mark.lillibridge <at> 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

Message #15 received at 5042 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: lekktu <at> gmail.com
Cc: 5042 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Wed, 9 Dec 2009 21:34:28 -0800

>  On Thu, Nov 26, 2009 at 01:39, Mark Lillibridge <mark.lillibridge <at> 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

Message #20 received at 5042 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: mark.lillibridge <at> hp.com
Cc: 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Thu, 10 Dec 2009 12:41:21 +0100

On Thu, Dec 10, 2009 at 06:34, Mark Lillibridge <mark.lillibridge <at> 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

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: lekktu <at> gmail.com
Cc: 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Sun, 20 Dec 2009 22:59:43 -0800

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

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: mark.lillibridge <at> hp.com
Cc: 5042 <at> debbugs.gnu.org, Markus Triska <markus.triska <at> gmx.at>
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Mon, 21 Dec 2009 11:37:52 +0100

On Mon, Dec 21, 2009 at 07:59, Mark Lillibridge <mark.lillibridge <at> 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

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juanma Barranquero'" <lekktu <at> gmail.com>, <5042 <at> debbugs.gnu.org>,
	<mark.lillibridge <at> hp.com>
Cc: 5042 <at> debbugs.gnu.org, 'Markus Triska' <markus.triska <at> gmx.at>
Subject: RE: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Mon, 21 Dec 2009 07:50:52 -0800

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

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: drew.adams <at> oracle.com
Cc: 5042 <at> debbugs.gnu.org, lekktu <at> gmail.com, markus.triska <at> gmx.at,
	5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Wed, 23 Dec 2009 12:49:21 -0800

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

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <mark.lillibridge <at> hp.com>
Cc: 5042 <at> debbugs.gnu.org, lekktu <at> gmail.com, markus.triska <at> gmx.at,
	5042 <at> debbugs.gnu.org
Subject: RE: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Wed, 23 Dec 2009 13:01:10 -0800

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

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: drew.adams <at> oracle.com
Cc: 5042 <at> debbugs.gnu.org, lekktu <at> gmail.com, markus.triska <at> gmx.at,
	5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Wed, 23 Dec 2009 13:44:31 -0800

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

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Wed, 23 Dec 2009 22:49:53 -0500

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

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

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#5042: 23.1;   linum-mode gives incorrect line numbers with
	narrowed buffers
Date: Tue, 29 Dec 2009 00:02:40 -0700

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

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: markus.triska <at> gmx.at
Cc: lekktu <at> gmail.com, 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Wed, 6 Jan 2010 21:38:51 -0800

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


>  On Mon, Dec 21, 2009 at 07:59, Mark Lillibridge <mark.lillibridge <at> 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
>  

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

From: Markus Triska <markus.triska <at> gmx.at>
To: mark.lillibridge <at> hp.com
Cc: lekktu <at> gmail.com, 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Fri, 08 Jan 2010 00:30:28 +0100

Mark Lillibridge <mark.lillibridge <at> 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.

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: markus.triska <at> gmx.at
Cc: lekktu <at> gmail.com, 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Sat, 9 Jan 2010 17:32:18 -0800

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

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: mark.lillibridge <at> hp.com
Cc: 5042 <at> debbugs.gnu.org, markus.triska <at> gmx.at
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Sun, 10 Jan 2010 02:56:00 +0100

On Sun, Jan 10, 2010 at 02:32, Mark Lillibridge <mark.lillibridge <at> 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

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: mark.lillibridge <at> hp.com, 5042 <at> debbugs.gnu.org
Cc: lekktu <at> gmail.com, markus.triska <at> gmx.at, 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Sun, 10 Jan 2010 03:05:58 +0100

On Sun, Jan 10, 2010 at 2:32 AM, Mark Lillibridge
<mark.lillibridge <at> 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.

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: lekktu <at> gmail.com
Cc: 5042 <at> debbugs.gnu.org, markus.triska <at> gmx.at
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Sat, 16 Jan 2010 14:08:10 -0800

Juanma wrote:
> On Sun, Jan 10, 2010 at 02:32, Mark Lillibridge
> <mark.lillibridge <at> 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

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: mark.lillibridge <at> hp.com
Cc: 5042 <at> debbugs.gnu.org, markus.triska <at> gmx.at
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Sun, 17 Jan 2010 00:03:34 +0100

On Sat, Jan 16, 2010 at 23:08, Mark Lillibridge <mark.lillibridge <at> 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

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: lekktu <at> gmail.com
Cc: 5042 <at> debbugs.gnu.org, markus.triska <at> gmx.at
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Sat, 23 Jan 2010 15:28:21 -0800

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

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Mark Lillibridge'" <mark.lillibridge <at> hp.com>, <lekktu <at> gmail.com>
Cc: 5042 <at> debbugs.gnu.org, markus.triska <at> gmx.at
Subject: RE: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Sat, 23 Jan 2010 16:07:04 -0800

> What do people think?

I think that the proper place to propose and discuss a potential Emacs
enhancement is emacs-devel <at> 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.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: mark.lillibridge <at> hp.com
Cc: 5042 <at> debbugs.gnu.org, markus.triska <at> gmx.at
Subject: Re: bug#5042: 23.1; linum-mode gives incorrect line numbers with 
	narrowed buffers
Date: Sun, 24 Jan 2010 10:21:10 +0100

On Sun, Jan 24, 2010 at 00:28, Mark Lillibridge <mark.lillibridge <at> 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

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: lekktu <at> gmail.com, markus.triska <at> gmx.at, 5042 <at> debbugs.gnu.org
Subject: Re: bug#5042: 23.1;
	linum-mode gives incorrect line numbers with  narrowed buffers
Date: Tue, 02 Feb 2010 21:01:51 -0800

>  > What do people think?
>  
>  I think that the proper place to propose and discuss a potential Emacs
>  enhancement is emacs-devel <at> 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 9917 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: 24.0.90; Make `goto-line' consistent with the line
 number from the minibuffer
Date: Sat, 19 Sep 2020 19:42:04 +0200

Dani Moncayo <dmoncayo <at> gmail.com> writes:

> This discrepancy is quite confusing for users, so my proposal is
> obvious: adjust the behaviour of `goto-line' to make it consistent
> with the line number showed in the minibuffer, i.e, to consider its
> LINE argument relative to the narrowed part if there's one, or else to
> the whole buffer.

The suggestion here is to make the interactive `goto-line' go to the
narrowed-to line instead of the absolute line.  I can see the reasoning
here -- especially after `display-line-numbers-mode' was added,
displaying line numbers seems to be getting more popular, and having
`M-x goto-char' not going to the number you're seeing (if the buffer is
narrowed) sounds confusing.

But it is a breaking change -- somewhat.  `goto-line' isn't supposed to
be used in code, and isn't used in-tree, but who knows what people have
done out there...

We could bind `M-g g' (and friends) to a new command that acts this new
way?

Anybody got any opinions here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#9917: 24.0.90; Make `goto-line' consistent with the line
 number from the minibuffer
Date: Sat, 19 Sep 2020 14:01:07 -0400

> The suggestion here is to make the interactive `goto-line' go to the
> narrowed-to line instead of the absolute line.  I can see the reasoning
> here -- especially after `display-line-numbers-mode' was added,
> displaying line numbers seems to be getting more popular, and having
> `M-x goto-char' not going to the number you're seeing (if the buffer is
> narrowed) sounds confusing.

I agree that the same should be used for `M-g g` and for the numbers
displayed in `display-line-numbers-mode' or in the mode-line.  I think
all those need some common way to decide if the first line is at
`point-min` or somewhere else.

> But it is a breaking change -- somewhat.  `goto-line' isn't supposed to
> be used in code, and isn't used in-tree, but who knows what people have
> done out there...

Agree.  We used to have calls to `goto-line` in our code, so there's
probably more in the wild.

> We could bind `M-g g' (and friends) to a new command that acts this
> new way?

Fine by me,


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90;
 Make `goto-line' consistent with the line number from the minibuffer
Date: Sat, 19 Sep 2020 21:33:59 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 19 Sep 2020 19:42:04 +0200
> Cc: 9917 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  5042 <at> debbugs.gnu.org
> 
> Dani Moncayo <dmoncayo <at> gmail.com> writes:
> 
> > This discrepancy is quite confusing for users, so my proposal is
> > obvious: adjust the behaviour of `goto-line' to make it consistent
> > with the line number showed in the minibuffer, i.e, to consider its
> > LINE argument relative to the narrowed part if there's one, or else to
> > the whole buffer.
> 
> The suggestion here is to make the interactive `goto-line' go to the
> narrowed-to line instead of the absolute line.  I can see the reasoning
> here -- especially after `display-line-numbers-mode' was added,
> displaying line numbers seems to be getting more popular, and having
> `M-x goto-char' not going to the number you're seeing (if the buffer is
> narrowed) sounds confusing.
> 
> But it is a breaking change -- somewhat.  `goto-line' isn't supposed to
> be used in code, and isn't used in-tree, but who knows what people have
> done out there...

The alternative POV, whereby line numbers are absolute disregarding
the narrowing, is also valid.  What's more important, it was there
first.

So I think it has to be a different command.  If someone wants to
rebind "M-g g" to that new command, they can always do that.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen
 <larsi <at> gnus.org>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 Dani Moncayo <dmoncayo <at> gmail.com>
Subject: RE: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Sat, 19 Sep 2020 12:27:13 -0700 (PDT)

In any buffer, including Info, a user can
want to go to a line counted from bob or from
point-min (current narrowing/restriction).

(Stefan mentioned the use case of an Info node
that's further narrowed.  There's also the
case of an Info buffer that a user has widened
intentionally.) 

There's no good way to read a user's mind
about this.

We can have a reasonable _default_ behavior,
and provide the other behavior as an
alternative.

We can do that using a prefix arg (I suggested
a negative one).  Or we can do it by providing
two separate commands.  Or in some other way.

And we could decide to have the default
behavior depend on something (type of buffer
or whatever).  But this might not be the best
approach.  (I think it's probably not.)

In any case, we should give users a way to
choose what they want, whatever the buffer.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90;
 Make `goto-line' consistent with the line number from the minibuffer
Date: Sat, 19 Sep 2020 22:56:53 +0300

> Date: Sat, 19 Sep 2020 12:27:13 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: Dani Moncayo <dmoncayo <at> gmail.com>, 9917 <at> debbugs.gnu.org,
>  5042 <at> debbugs.gnu.org
> 
> In any buffer, including Info, a user can
> want to go to a line counted from bob or from
> point-min (current narrowing/restriction).

If that is the main use case for this issue, we could have a different
binding for "M-g g" in Info mode.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: RE: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Sat, 19 Sep 2020 13:22:41 -0700 (PDT)

> > In any buffer, including Info, a user can
> > want to go to a line counted from bob or from
> > point-min (current narrowing/restriction).
> 
> If that is the main use case for this issue, we could
> have a different binding for "M-g g" in Info mode.

It's not about Info mode, or any particular mode.
It's not about whether the buffer happens to be
narrowed.  It's about what the users wants in the
current context.

My point is that a user can want _either_ behavior,
and there's no way to know which behavior is wanted
at any given moment, in any given buffer, whether
narrowed or not.

IMO, we need either two different commands (& keys)
or a command with different prefix-arg behaviors.

We need _some_ way for a user to be able to get
either behavior, regardless of what a "default"
behavior might be.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Sat, 19 Sep 2020 23:27:05 +0300

> Date: Sat, 19 Sep 2020 13:22:41 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: monnier <at> iro.umontreal.ca, larsi <at> gnus.org, dmoncayo <at> gmail.com,
>         9917 <at> debbugs.gnu.org, 5042 <at> debbugs.gnu.org
> 
> My point is that a user can want _either_ behavior,
> and there's no way to know which behavior is wanted
> at any given moment, in any given buffer, whether
> narrowed or not.
> 
> IMO, we need either two different commands (& keys)
> or a command with different prefix-arg behaviors.

I suggested the former up-thread (and thought that your response meant
you are unhappy about that for some reason).  Different prefix-arg
behaviors would be tricky in this case, I think, because goto-line
accepts a numeric argument already.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: RE: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Sat, 19 Sep 2020 14:10:55 -0700 (PDT)

> > My point is that a user can want _either_ behavior,
> > and there's no way to know which behavior is wanted
> > at any given moment, in any given buffer, whether
> > narrowed or not.
> >
> > IMO, we need either two different commands (& keys)
> > or a command with different prefix-arg behaviors.
> 
> I suggested the former up-thread (and thought that your response meant
> you are unhappy about that for some reason).  Different prefix-arg
> behaviors would be tricky in this case, I think, because goto-line
> accepts a numeric argument already.

From the outset (and typically), I've been for users
being able to specify the behavior they want, either
on the fly or (if it makes sense) by option.

In the bug #9917 thread I suggested this (in 2011):

> > when someone says "see the line 42 in window.c"
> > then `goto-line' should visit by the absolute line number,
> > ignoring any narrowing in effect.  But when someone says
> > "see the line 42 in the Info node" then it should be relative
> > to the node's beginning.
> 
> For `goto-line':
> 
> Let a negative prefix arg use line numbering wrt the
> restriction (region), and let a positive prefix arg
> use line numbering wrt the buffer (widened).
> 
> Likewise for a number read at the prompt: negative for
> restriction numbering, positive for full-buffer numbering.

But, as I said recently here, two separate commands
(and keys) is OK too.

What I think would be inferior would be _only_ a dwimmy
behavior that doesn't give users a way to control what
happens when it doesn't correspond to some simple
conditional that the dwim relies on.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Sun, 20 Sep 2020 08:34:53 +0300

> Date: Sat, 19 Sep 2020 14:10:55 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: monnier <at> iro.umontreal.ca, larsi <at> gnus.org, dmoncayo <at> gmail.com,
>         9917 <at> debbugs.gnu.org, 5042 <at> debbugs.gnu.org
> 
> > Let a negative prefix arg use line numbering wrt the
> > restriction (region), and let a positive prefix arg
> > use line numbering wrt the buffer (widened).
> > 
> > Likewise for a number read at the prompt: negative for
> > restriction numbering, positive for full-buffer numbering.

IMO, this would be a highly confusing behavior, especially for those
who want goto-line to work in terms of narrowed lines.

> But, as I said recently here, two separate commands
> (and keys) is OK too.

Then let's have that.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with
 the line number from the minibuffer
Date: Sun, 20 Sep 2020 11:28:14 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> So I think it has to be a different command.  If someone wants to
> rebind "M-g g" to that new command, they can always do that.

I'm sympathetic to the idea of not disrupting anybody's workflow.
However if the keystroke isn't useful as it is today, then changing how
it works (so that it's useful) is an option.

So: Is `M-g g' (in a narrowed buffer) useful today?  `M-g g 2' will
almost inevitably take you to the start of the buffer, so that's not
useful, and I think is what people are complaining about, because it
just seems to...  unhelpful.

However, if people have a narrowed buffer, and are looking at (say) the
compilation output that says "error on like 45" in a shell, then `M-g g
45' will definitely do the wrong thing is we change the command to start
counting from the start of the narrowed region.

So a new command and keystroke seems warranted.  How about...
`M-g M-v'?   (The mnemonic is "goto visual line".)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with
 the line number from the minibuffer
Date: Mon, 21 Sep 2020 22:03:44 +0300

> However, if people have a narrowed buffer, and are looking at (say) the
> compilation output that says "error on like 45" in a shell, then `M-g g
> 45' will definitely do the wrong thing is we change the command to start
> counting from the start of the narrowed region.

In this case another option is to widen the buffer before going to that line.
This is what for example help-function-def--button-function does:

            ;; Widen the buffer if necessary to go to this position.
            (when (or (< position (point-min))
                      (> position (point-max)))
              (widen))
            (goto-char position)

Unfortunately, xref doesn't provide such nice feature,
so 'M-.' fails to navigate in a narrowed buffer.

For 'M-g M-g' this means removing 'save-restriction' from 'goto-line'.

> So a new command and keystroke seems warranted.  How about...
> `M-g M-v'?   (The mnemonic is "goto visual line".)

Or to add a new key to narrow-map 'C-x n' that currently
contains only 4 keys:

  C-x n d         narrow-to-defun
  C-x n n         narrow-to-region
  C-x n p         narrow-to-page
  C-x n w         widen

where a new key could be:

  C-x n g         go to narrowed line

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with
 the line number from the minibuffer
Date: Tue, 22 Sep 2020 16:37:40 +0200

Juri Linkov <juri <at> linkov.net> writes:

>> So a new command and keystroke seems warranted.  How about...
>> `M-g M-v'?   (The mnemonic is "goto visual line".)
>
> Or to add a new key to narrow-map 'C-x n' that currently
> contains only 4 keys:
>
>   C-x n d         narrow-to-defun
>   C-x n n         narrow-to-region
>   C-x n p         narrow-to-page
>   C-x n w         widen
>
> where a new key could be:
>
>   C-x n g         go to narrowed line

Perhaps both?  The keystroke makes sense in both contexts -- as a
variation on `M-g M-g', and in the group of narrowing keystroke.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with
 the line number from the minibuffer
Date: Tue, 22 Sep 2020 21:08:10 +0300

[Message part 1 (text/plain, inline)]

>>> So a new command and keystroke seems warranted.  How about...
>>> `M-g M-v'?   (The mnemonic is "goto visual line".)
>>
>>   C-x n g         go to narrowed line
>
> Perhaps both?  The keystroke makes sense in both contexts -- as a
> variation on `M-g M-g', and in the group of narrowing keystroke.

Yep, having both is a win-win situation.

Here is the patch that:

1. leaves the existing 'goto-line' completely backward-compatible
   (actually a small difference is that in a narrowed buffer it displays
    now the prompt "Goto absolute line:" instead of just "Goto line:")
2. adds two optional args RELATIVE and WIDEN to 'goto-line';
3. adds two new commands 'goto-line-absolute' and 'goto-line-relative':
3.1. 'goto-line-absolute' widens the buffer and doesn't narrow it back;
3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'.

If this is ok, then 'goto-line-relative' could be bound to
`M-g M-v' and `C-x n g'.

[goto-line-relative.patch (text/x-diff, inline)]

diff --git a/lisp/info.el b/lisp/info.el
index e4f75b481f..20633fd059 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4053,6 +4053,7 @@ Info-mode-map
     (define-key map "^" 'Info-up)
     (define-key map "," 'Info-index-next)
     (define-key map "\177" 'Info-scroll-down)
+    (define-key map [remap goto-line] 'goto-line-relative)
     (define-key map [mouse-2] 'Info-mouse-follow-nearest-node)
     (define-key map [follow-link] 'mouse-face)
     (define-key map [XF86Back] 'Info-history-back)
diff --git a/lisp/simple.el b/lisp/simple.el
index 050c81a410..724d2d96aa 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1231,7 +1231,38 @@ goto-line-history
   "History of values entered with `goto-line'.")
 (make-variable-buffer-local 'goto-line-history)
 
-(defun goto-line (line &optional buffer)
+(defun goto-line-read-args (&optional relative)
+  "Read arguments for `goto-line' related commands."
+  (if (and current-prefix-arg (not (consp current-prefix-arg)))
+      (list (prefix-numeric-value current-prefix-arg))
+    ;; Look for a default, a number in the buffer at point.
+    (let* ((default
+	     (save-excursion
+	       (skip-chars-backward "0-9")
+	       (if (looking-at "[0-9]")
+		   (string-to-number
+		    (buffer-substring-no-properties
+		     (point)
+		     (progn (skip-chars-forward "0-9")
+			    (point)))))))
+	   ;; Decide if we're switching buffers.
+	   (buffer
+	    (if (consp current-prefix-arg)
+		(other-buffer (current-buffer) t)))
+	   (buffer-prompt
+	    (if buffer
+		(concat " in " (buffer-name buffer))
+	      "")))
+      ;; Read the argument, offering that number (if any) as default.
+      (list (read-number (format "Goto%s line%s: "
+                                 (if (= (point-min) 1) ""
+                                   (if relative " relative" " absolute"))
+                                 buffer-prompt)
+                         (list default (line-number-at-pos))
+                         'goto-line-history)
+	    buffer))))
+
+(defun goto-line (line &optional buffer relative widen)
   "Go to LINE, counting from line 1 at beginning of buffer.
 If called interactively, a numeric prefix argument specifies
 LINE; without a numeric prefix argument, read LINE from the
@@ -1241,6 +1272,12 @@ goto-line
 move to line LINE there.  If called interactively with \\[universal-argument]
 as argument, BUFFER is the most recently selected other buffer.
 
+If optional argument RELATIVE is non-nil, counting is relative
+from the beginning of the narrowed buffer.
+
+If optional argument WIDEN is non-nil, cancel narrowing
+and leave all lines accessible.
+
 Prior to moving point, this function sets the mark (without
 activating it), unless Transient Mark mode is enabled and the
 mark is already active.
@@ -1252,32 +1289,7 @@ goto-line
 If at all possible, an even better solution is to use char counts
 rather than line counts."
   (declare (interactive-only forward-line))
-  (interactive
-   (if (and current-prefix-arg (not (consp current-prefix-arg)))
-       (list (prefix-numeric-value current-prefix-arg))
-     ;; Look for a default, a number in the buffer at point.
-     (let* ((default
-	      (save-excursion
-		(skip-chars-backward "0-9")
-		(if (looking-at "[0-9]")
-		    (string-to-number
-		     (buffer-substring-no-properties
-		      (point)
-		      (progn (skip-chars-forward "0-9")
-			     (point)))))))
-	    ;; Decide if we're switching buffers.
-	    (buffer
-	     (if (consp current-prefix-arg)
-		 (other-buffer (current-buffer) t)))
-	    (buffer-prompt
-	     (if buffer
-		 (concat " in " (buffer-name buffer))
-	       "")))
-       ;; Read the argument, offering that number (if any) as default.
-       (list (read-number (format "Goto line%s: " buffer-prompt)
-                          (list default (line-number-at-pos))
-                          'goto-line-history)
-	     buffer))))
+  (interactive (goto-line-read-args))
   ;; Switch to the desired buffer, one way or another.
   (if buffer
       (let ((window (get-buffer-window buffer)))
@@ -1286,12 +1298,28 @@ goto-line
   ;; Leave mark at previous position
   (or (region-active-p) (push-mark))
   ;; Move to the specified line number in that buffer.
-  (save-restriction
-    (widen)
-    (goto-char (point-min))
-    (if (eq selective-display t)
-	(re-search-forward "[\n\C-m]" nil 'end (1- line))
-      (forward-line (1- line)))))
+  (if (and (not relative) (not widen))
+      ;; Useless case because it just moves point to the edge of visible portion.
+      (save-restriction
+        (widen)
+        (goto-char (point-min))
+        (if (eq selective-display t)
+	    (re-search-forward "[\n\C-m]" nil 'end (1- line))
+          (forward-line (1- line))))
+    (progn
+      (unless relative (widen))
+      (goto-char (point-min))
+      (if (eq selective-display t)
+	  (re-search-forward "[\n\C-m]" nil 'end (1- line))
+        (forward-line (1- line))))))
+
+(defun goto-line-absolute (line &optional buffer)
+  (interactive (goto-line-read-args))
+  (goto-line line buffer nil t))
+
+(defun goto-line-relative (line &optional buffer)
+  (interactive (goto-line-read-args t))
+  (goto-line line buffer t t))
 
 (defun count-words-region (start end &optional arg)
   "Count the number of words in the region.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 dmoncayo <at> gmail.com
Subject: RE: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Tue, 22 Sep 2020 13:10:09 -0700 (PDT)

> 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'.

I gave my opinion about this.  And it was a reason given
for having two different commands: Do not base which
command gets the standard key binding on anything to do
with the current context - in particular, on whether the
buffer is narrowed.

Please do _not_ bind `M-g M-g' to anything different in Info.

Emacs should not be second-guessing users about this.
The point of having two commands (and two key bindings)
is to let users get the behavior they want, in any
context.  Please do not have the same key bound to
different behaviors for going to a line.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with
 the line number from the minibuffer
Date: Wed, 23 Sep 2020 15:18:45 +0200

Juri Linkov <juri <at> linkov.net> writes:

> 1. leaves the existing 'goto-line' completely backward-compatible
>    (actually a small difference is that in a narrowed buffer it displays
>     now the prompt "Goto absolute line:" instead of just "Goto line:")
> 2. adds two optional args RELATIVE and WIDEN to 'goto-line';
> 3. adds two new commands 'goto-line-absolute' and 'goto-line-relative':
> 3.1. 'goto-line-absolute' widens the buffer and doesn't narrow it back;
> 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'.
>
> If this is ok, then 'goto-line-relative' could be bound to
> `M-g M-v' and `C-x n g'.

Sounds good to me.  Drew objected to rebinding the keystroke in Info
mode, but I think that's probably fine -- nobody is ever going to refer
to an absolute line in Info.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 5042 <at> debbugs.gnu.org, juri <at> linkov.net, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com, larsi <at> gnus.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90;
 Make `goto-line' consistent with the line number from the minibuffer
Date: Wed, 23 Sep 2020 17:14:29 +0300

> Date: Tue, 22 Sep 2020 13:10:09 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
>  5042 <at> debbugs.gnu.org
> 
> > 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'.
> 
> I gave my opinion about this.  And it was a reason given
> for having two different commands: Do not base which
> command gets the standard key binding on anything to do
> with the current context - in particular, on whether the
> buffer is narrowed.
> 
> Please do _not_ bind `M-g M-g' to anything different in Info.

Why not?  We do this kind of thing -- have mode-specific bindings --
all the time in Emacs.

> Emacs should not be second-guessing users about this.

It's not second-guessing.  Info shows narrowed line numbers in its
buffers, so from the user POV the key sequence keeps invoking the same
command.

I see no problem and don't see why you object so much.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Juri Linkov <juri <at> linkov.net>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 dmoncayo <at> gmail.com
Subject: RE: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Wed, 23 Sep 2020 10:58:11 -0700 (PDT)

> Drew objected to rebinding the keystroke in Info
> mode, but I think that's probably fine -- nobody is ever going to refer
> to an absolute line in Info.

Why do you think so?

The principle is general.  Logically, this has
nothing to do with the mode or context, except if
the user thinks it does.  No such coupling should
be done automatically (hard-coded).  Just give users
two commands/keys and let them use whichever they
feel is appropriate in any given mode/context.

You're setting a bad precedent by overruling users
here.  `M-g M-g' should do the same thing, wherever.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 5042 <at> debbugs.gnu.org, juri <at> linkov.net, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com, larsi <at> gnus.org
Subject: RE: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Wed, 23 Sep 2020 11:09:53 -0700 (PDT)

> > > 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'.
> >
> > I gave my opinion about this.  And it was a reason given
> > for having two different commands: Do not base which
> > command gets the standard key binding on anything to do
> > with the current context - in particular, on whether the
> > buffer is narrowed.
> >
> > Please do _not_ bind `M-g M-g' to anything different in Info.
> 
> Why not?  We do this kind of thing -- have mode-specific bindings --
> all the time in Emacs.

Because we will now have two commands, with two bindings,
to let users get the behavior they want - in any mode,
any context.

Changing the binding of one of those 2 commands to invoke
the other command, makes no sense.  It takes away a
possibility (one command gets two bindings; the other
gets zero bindings).  And it confuses users.

> > Emacs should not be second-guessing users about this.
> 
> It's not second-guessing.  Info shows narrowed line numbers in its
> buffers, so from the user POV the key sequence keeps invoking the same
> command.

Info uses narrowing to show a node.  Users can further
use narrowing within a node.  Users can widen, to see
all of a file.  That Info uses narrowing for this
special purpose might be seen as a kludge.  In any
case, it's a different use of narrowing from a user's.

From a user POV the key sequence `M-g M-g' does NOT
keep invoking the same command.  If it invoked the same
command then it would still move to an absolute position.

From a user POV, the user has _lost_ a key binding for
one of the commands, and the other command now has two
bindings.

> I see no problem and don't see why you object so much.

So much?  I just presented my objection; that's all.

I see no reason for this.  I see reasons against it,
both wrt the particular case (Info) and in terms of
setting a bad precedent.

I don't object "so much".  I do think it would be a
mistake.  And it's not necessary.

At the very least, if you insist on this "so much",
then please consider swapping the two command bindings
in Info mode, and advertising this (anomalous swap).

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

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 dmoncayo <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Wed, 23 Sep 2020 22:40:17 +0300

> That Info uses narrowing for this special purpose might be seen as
> a kludge.

Indeed, Info narrowing is an implementation detail irrelevant for most users.
And BTW Info-mode is the only mode that sets widen-automatically to nil.

Now I pushed this change to the trunk because two maintainers confirmed that
this is the right thing to do.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 5042 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with
 the line number from the minibuffer
Date: Thu, 24 Sep 2020 09:39:07 +0200

>>>>> On Wed, 23 Sep 2020 10:58:11 -0700 (PDT), Drew Adams <drew.adams <at> oracle.com> said:

    >> Drew objected to rebinding the keystroke in Info
    >> mode, but I think that's probably fine -- nobody is ever going to refer
    >> to an absolute line in Info.

    Drew> Why do you think so?

    Drew> The principle is general.  Logically, this has
    Drew> nothing to do with the mode or context, except if
    Drew> the user thinks it does.  No such coupling should
    Drew> be done automatically (hard-coded).  Just give users
    Drew> two commands/keys and let them use whichever they
    Drew> feel is appropriate in any given mode/context.

    Drew> You're setting a bad precedent by overruling users
    Drew> here.  `M-g M-g' should do the same thing, wherever.

If I turn on display-line-numbers-mode in an *info* buffer, or have the
line number displayed in the mode line, those numbers are the narrowed
line numbers. Having M-g M-g go to the absolute line number there
would be very confusing as they donʼt match the visual information
provided (how many people even know that *info* buffers are narrowed?
They behave like a linked set of buffers).

Robert

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 5042 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the
 line number from the minibuffer
Date: Thu, 24 Sep 2020 10:31:17 -0700 (PDT)

>     >> Drew objected to rebinding the keystroke in Info
>     >> mode, but I think that's probably fine -- nobody is
>     >> ever going to refer to an absolute line in Info.
> 
>     Drew> Why do you think so?
> 
>     Drew> The principle is general.  Logically, this has
>     Drew> nothing to do with the mode or context, except if
>     Drew> the user thinks it does.  No such coupling should
>     Drew> be done automatically (hard-coded).  Just give users
>     Drew> two commands/keys and let them use whichever they
>     Drew> feel is appropriate in any given mode/context.
> 
>     Drew> You're setting a bad precedent by overruling users
>     Drew> here.  `M-g M-g' should do the same thing, wherever.
> 
> If I turn on display-line-numbers-mode in an *info* buffer, or have the
> line number displayed in the mode line, those numbers are the narrowed
> line numbers. Having M-g M-g go to the absolute line number there
> would be very confusing as they donʼt match the visual information
> provided (how many people even know that *info* buffers are narrowed?
> They behave like a linked set of buffers).

Either Info should be made to NOT use narrowing
to simulate what you describe as "a linked set of
buffers", or ordinary considerations of narrowing
apply.

How do you know that an Info buffer is narrowed?
Same way as any other buffer: the mode line says
"(Info Narrow)".  Nothing new here.

Someone decided that relative line numbering was
appropriate as the default behavior for Info.
That's not bad.

And yes, if a user is _not aware_ that line
numbering is relative, and that the buffer is
narrowed, then s?he may mistakenly use `M-g M-g'
to go to what s?he thinks is a normal, i.e.,
absolute line number.

Info is between two chairs.  It should instead be
handled consistently (pick a chair) - either:

1. As an explicitly narrowed buffer, with relative
   line numbers - and a user would then use the
   (new) command and key for going to a relative
   line number.  A user would get that the buffer
   is narrowed, and relative line numbers are
   appropriate.

or

2. As an widened buffer (or with narrowing completely
   imperceptible by users), with absolute line numbers
   - and a user would then use good old `goto-line'
   and its key, `M-g M-g'.

Currently, half the indications for users are that
Info IS narrowed (by default), which it is, and half
of them are that Info is NOT narrowed (which is
incorrect).

We now have two ways to show line numbers and two keys
for going to a line number: relative and absolute.
A user is free to show relative but goto absolute,
or the opposite, or either of the two same-type
combinations - 4 combinations altogether.

A user who is used to `M-g M-g' being goto absolute
will not expect it to sometimes instead become goto
relative behind her back (invisibly).

That a user might not know that Info is narrowed is
a separate problem, which should maybe be addressed.

The fact is that Info IS narrowed (by default).
And Emacs tells you so, pretty clearly.  If you're
aware of that then you're not surprised that Emacs
has chosen to show you relative line numbers (by
default).  But you _will_ be surprised to discover
that `M-g M-g' has changed silently.  And that there
is no longer any key for `goto-line'.

What's needed is some better alignment of things.
Plus better informing of users of what the state is.

As for the goto keys and their commands: they should
be kept separate, and both available at all times.

I mentioned the possibility of swapping the bindings
in the Info setting.  I'm not in favor of any such
key changes, but certainly it's better to swap (if
someone insists that `M-g M-g' needs to become
relative), rather than to just give both keys to
relative goto.

Again, I don't feel strongly about any of this.  I
do, however, think we're making a mistake by doing
what's being done.  In particular because it sets
a bad precedent.

Someone may say that Info is a very special case,
and there won't ever be another like it, and we
have no plan to change how Info represents nodes
(that is, we'll continue to just narrow - it's not
a bad approach, even if it's a bit rudimentary),
and so therefore it's OK to make this special
exception.

Will it continue to be regarded as a special case?
Or will other modes where someone thinks that the
default expectation will be going to relative line
numbers also get `M-g M-g' hijacked for relative
goto?  I unfortunately have to bet on the latter.

If we continue to narrow to Info nodes, and if we
think that the mode-line indication isn't strong
enough, here's a suggestion:

My library zones.el has a Boolean option,
`zz-narrowing-use-fringe-flag', to highlight the
fringe when the buffer is narrowed.  It's then
pretty obvious when you narrow a buffer.  But
until a user has done that, and noticed the
effect, s?he might not get it when just going to
a buffer, like Info, that's already narrowed.

Another possibility is to highlight `Narrow' in
the mode line, at least for Info.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Tue, 27 Oct 2020 22:52:10 +0200

> This is what for example help-function-def--button-function does:
>
>             ;; Widen the buffer if necessary to go to this position.
>             (when (or (< position (point-min))
>                       (> position (point-max)))
>               (widen))
>             (goto-char position)
>
> Unfortunately, xref doesn't provide such nice feature,
> so 'M-.' fails to navigate in a narrowed buffer.

Here is the fix for xref:

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index eed73f5791..c7ff351845 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -897,8 +897,10 @@ xref-location-marker
     (let ((buffer-point (find-function-search-for-symbol symbol type file)))
       (with-current-buffer (car buffer-point)
         (save-excursion
-          (goto-char (or (cdr buffer-point) (point-min)))
-          (point-marker))))))
+          (save-restriction
+            (widen)
+            (goto-char (or (cdr buffer-point) (point-min)))
+            (point-marker)))))))
 
 (cl-defmethod xref-location-group ((l xref-elisp-location))
   (xref-elisp-location-file l))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 5042 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Wed, 28 Oct 2020 10:48:36 +0100

Juri Linkov <juri <at> linkov.net> writes:

> Here is the fix for xref:

[...]

> -          (goto-char (or (cdr buffer-point) (point-min)))
> -          (point-marker))))))
> +          (save-restriction
> +            (widen)
> +            (goto-char (or (cdr buffer-point) (point-min)))
> +            (point-marker)))))))

Hm...  Does Dmitry have any comments here?  (Added to Cc.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Juri Linkov <juri <at> linkov.net>
Cc: dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Wed, 28 Oct 2020 13:58:03 +0200

On 28.10.2020 11:48, Lars Ingebrigtsen wrote:
> Juri Linkov <juri <at> linkov.net> writes:
> 
>> Here is the fix for xref:
> 
> [...]
> 
>> -          (goto-char (or (cdr buffer-point) (point-min)))
>> -          (point-marker))))))
>> +          (save-restriction
>> +            (widen)
>> +            (goto-char (or (cdr buffer-point) (point-min)))
>> +            (point-marker)))))))

If this works, sure, please install. This piece by itself makes sense.

> Hm...  Does Dmitry have any comments here?  (Added to Cc.)

I'm subscribed to the bug tracker, but I skip over a number of 
discussions automatically (and an extra email in a thread is relatively 
easy to miss, too).

In case I don't respond in similar circumstances in the future, may I 
ask for a personal email? One without 'debbugs.gnu.org' in the From/To/Cc.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Thu, 29 Oct 2020 11:19:11 +0200

>>> So a new command and keystroke seems warranted.  How about...
>>> `M-g M-v'?   (The mnemonic is "goto visual line".)
>>
>> Or to add a new key to narrow-map 'C-x n' where a new key could be:
>>
>>   C-x n g         go to narrowed line
>
> Perhaps both?  The keystroke makes sense in both contexts -- as a
> variation on `M-g M-g', and in the group of narrowing keystroke.

I've added a more localized key binding 'C-x n g',
but still not sure about the global 'M-g' key bindings.
Here are some possible variants:

1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g'
   bound to goto-line that currently uses absolute line numbers
   (btw, this fact should be mentioned in its docstring);

2. Re-bind 'M-g g' to goto-line-relative as many asked to do
   with the reasoning that 'M-g g' should use by default the
   same numbering scheme as is displayed by display-line-numbers-mode;

3. Leave the existing 'M-g g' bound to goto-line, but allow changing
   the numbering scheme using a prefix arg and a user option.
   Or another idea: maybe it should depend on whether
   display-line-numbers-mode is enabled or not?
   When display-line-numbers-mode is enabled, then use
   relative line numbers that are displayed on the left side (WYSIWYG).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Thu, 29 Oct 2020 16:31:58 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  5042 <at> debbugs.gnu.org,
>   9917 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca,  dmoncayo <at> gmail.com
> Date: Thu, 29 Oct 2020 11:19:11 +0200
> 
> 2. Re-bind 'M-g g' to goto-line-relative as many asked to do
>    with the reasoning that 'M-g g' should use by default the
>    same numbering scheme as is displayed by display-line-numbers-mode;

Two comments:

 1) display-line-numbers-mode by default behaves the same as
    line-number-mode
 2) display-line-numbers-mode has the display-line-numbers-widen
    option which disregards narrowing, so if you want to follow
    display-line-numbers-mode, you will need to heed that option as
    well

> 3. Leave the existing 'M-g g' bound to goto-line, but allow changing
>    the numbering scheme using a prefix arg and a user option.

I like this the best.

>    Or another idea: maybe it should depend on whether
>    display-line-numbers-mode is enabled or not?

That sounds wrong to me: there's no real relation between these two,
and having the same command behave differently in two buffers doesn't
sound right to me.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 5042 <at> debbugs.gnu.org
Subject: RE: bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Thu, 29 Oct 2020 09:44:18 -0700 (PDT)

> >>> So a new command and keystroke seems warranted.  How about...
> >>> `M-g M-v'?   (The mnemonic is "goto visual line".)
> >>
> >> Or to add a new key to narrow-map 'C-x n' where a new key could be:
> >>
> >>   C-x n g         go to narrowed line
> >
> > Perhaps both?  The keystroke makes sense in both contexts -- as a
> > variation on `M-g M-g', and in the group of narrowing keystroke.
> 
> I've added a more localized key binding 'C-x n g',
> but still not sure about the global 'M-g' key bindings.
> Here are some possible variants:
> 
> 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g'
>    bound to goto-line that currently uses absolute line numbers
>    (btw, this fact should be mentioned in its docstring);
> 
> 2. Re-bind 'M-g g' to goto-line-relative as many asked to do
>    with the reasoning that 'M-g g' should use by default the
>    same numbering scheme as is displayed by display-line-numbers-mode;
> 
> 3. Leave the existing 'M-g g' bound to goto-line, but allow changing
>    the numbering scheme using a prefix arg and a user option.
>    Or another idea: maybe it should depend on whether
>    display-line-numbers-mode is enabled or not?
>    When display-line-numbers-mode is enabled, then use
>    relative line numbers that are displayed on the left side (WYSIWYG).

FWIW, I think this belongs on `M-g', and not on
`C-x n' (and not on both).

The aim of the command is to go to a line.  IIUC,
it's not a command that is essentially an action on
the buffer restriction (narrowing).

Users will think of this as a goto-line action, and
they will look for it on a key related to going to
a line number.

As others have pointed out, some users won't even
recognize that Info shows a node by narrowing the
overall buffer (the manual).  They won't look for
the key on `C-x n' (and they shouldn't).

Functions that act on relative, instead of absolute,
file names are still basically about file names or
files, and their names and keys generally reflect
that.  Similarly here - this about going to a
relative line number.  Why a user would most likely
want to do that in Info (answer: because it's
narrowed) is secondary, and can almost remain
unremarked.
___


Which brings us back perhaps to _swapping_ relative
and absolute whenever the buffer is narrowed - the
Info case is just a special case of that.

What about doing that (advertising it prominently)?

By default (add an option, to let users choose),
when the buffer is narrowed the regular absolute
goto-line key goes to a relative line number, and
the regular goto-relative line key goes to an
absolute line number.

That would mentally cement the natural relation
between relative line numbering and narrowed buffer.

But by _swapping_ (and certainly not letting one of
the behaviors grab both keys, as was suggested here),
users always have both behaviors available on keys
(including in Info).

Yes, such swapping would be perhaps a first for
Emacs.  But I think it would end up being pretty
natural, even expected.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Fri, 30 Oct 2020 09:27:43 +0200

>> 2. Re-bind 'M-g g' to goto-line-relative as many asked to do
>>    with the reasoning that 'M-g g' should use by default the
>>    same numbering scheme as is displayed by display-line-numbers-mode;
>
> Two comments:
>
>  1) display-line-numbers-mode by default behaves the same as
>     line-number-mode
>  2) display-line-numbers-mode has the display-line-numbers-widen
>     option which disregards narrowing, so if you want to follow
>     display-line-numbers-mode, you will need to heed that option as
>     well
>
>> 3. Leave the existing 'M-g g' bound to goto-line, but allow changing
>>    the numbering scheme using a prefix arg and a user option.
>
> I like this the best.

If making the current goto-line 'M-g g' more DWIM is not easy to do,
maybe really a user option could help with such choices:

- always use absolute line numbers;
- always use relative line numbers;
- follow the value of display-line-numbers-widen;
...

Also more explicit keys are needed, e.g.:

M-g l a   - with mnemonics: goto line absolute
M-g l r   - with mnemonics: goto line relative

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Fri, 30 Oct 2020 10:19:46 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org,  5042 <at> debbugs.gnu.org,  9917 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca,  dmoncayo <at> gmail.com
> Date: Fri, 30 Oct 2020 09:27:43 +0200
> 
> >> 3. Leave the existing 'M-g g' bound to goto-line, but allow changing
> >>    the numbering scheme using a prefix arg and a user option.
> >
> > I like this the best.
> 
> If making the current goto-line 'M-g g' more DWIM is not easy to do,
> maybe really a user option could help with such choices:
> 
> - always use absolute line numbers;
> - always use relative line numbers;
> - follow the value of display-line-numbers-widen;
> ...

That's also a possibility, but I think "M-1 M-g g" would still be
useful, even with these options, because sometimes the need in
narrow-relative line numbers is a one-time thing.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 5042 <at> debbugs.gnu.org, 9917 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 dmoncayo <at> gmail.com, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Fri, 30 Oct 2020 10:44:24 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> In case I don't respond in similar circumstances in the future, may I
> ask for a personal email? One without 'debbugs.gnu.org' in the
> From/To/Cc.

OK, will try to remember.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Fri, 30 Oct 2020 10:49:12 +0100

Juri Linkov <juri <at> linkov.net> writes:

> I've added a more localized key binding 'C-x n g',
> but still not sure about the global 'M-g' key bindings.
> Here are some possible variants:
>
> 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g'
>    bound to goto-line that currently uses absolute line numbers
>    (btw, this fact should be mentioned in its docstring);

This makes most sense to me -- sometimes you want to go relative (when
you're working on stuff wrt. the buffer) and sometimes you want to go
absolute (when you're looking at external data, like error reports and
the like).

So two commands (and keystrokes), and document the difference properly.

> 3. Leave the existing 'M-g g' bound to goto-line, but allow changing
>    the numbering scheme using a prefix arg and a user option.
>    Or another idea: maybe it should depend on whether
>    display-line-numbers-mode is enabled or not?
>    When display-line-numbers-mode is enabled, then use
>    relative line numbers that are displayed on the left side (WYSIWYG).

I'm not opposed to this, but I wonder whether it'd be used much (if we
have two keystrokes, which I think we should have anyway).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Sat, 31 Oct 2020 21:28:41 +0200

>> 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g'
>>    bound to goto-line that currently uses absolute line numbers
>>    (btw, this fact should be mentioned in its docstring);
>
> This makes most sense to me -- sometimes you want to go relative (when
> you're working on stuff wrt. the buffer) and sometimes you want to go
> absolute (when you're looking at external data, like error reports and
> the like).
>
> So two commands (and keystrokes), and document the difference properly.

What do you think about binding upper-case 'M-G G' to goto-line,
where the big G has mnemonics of more global absolute line numbers,
and binding lower-case 'M-g g' to goto-line-relative where
the little g means more local relative addressing.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, dmoncayo <at> gmail.com, 9917 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, 5042 <at> debbugs.gnu.org
Subject: Re: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line'
 consistent with the line number from the minibuffer
Date: Sat, 31 Oct 2020 22:00:59 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  5042 <at> debbugs.gnu.org,
>   9917 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca,  dmoncayo <at> gmail.com
> Date: Sat, 31 Oct 2020 21:28:41 +0200
> 
> What do you think about binding upper-case 'M-G G' to goto-line,

It's harder to type.

Previous Next

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