bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Dani Moncayo
Hi,

When you are in a narrowed buffer (e.g. an Info buffer), the line
number that you see in the mode-line is relative to the narrowed
portion, whereas the `goto-line' (M-g g) command requires you to
supply an absolute line number.

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.


In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601)
 of 2011-10-27 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.5)'

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Juri Linkov
> When you are in a narrowed buffer (e.g. an Info buffer), the line
> number that you see in the mode-line is relative to the narrowed
> portion, whereas the `goto-line' (M-g g) command requires you to
> supply an absolute line number.
>
> 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.

Just removing `(widen)' from `goto-line' will fix this.  But the question is
why it's here.  What was the intention of adding `(widen)' here.



Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Stefan Monnier
> Just removing `(widen)' from `goto-line' will fix this.  But the question is
> why it's here.  What was the intention of adding `(widen)' here.

Because depending on the use of narrow-to-region, you'll want widen
or not.  Some code was written with some particular uses in mind, while
other code was written with other uses in mind, hence
the inconsistencies.

The difference is whether narrow-to-region really wants to pretend the
text outside the region doesn't exist at all (e.g. in Rmail or Info), or
whether it is just meant to temporarily only display a subpart
(e.g. most other cases).

Then things get interesting when the user uses narrow-to-region in Info
or Rmail.  Currently the only data we have to distinguish the two cases
is font-lock-dont-widen, but clearly it's not sufficient to handle the
"user narrowing in Info" case.


        Stefan



Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Juri Linkov
> Because depending on the use of narrow-to-region, you'll want widen
> or not.  Some code was written with some particular uses in mind, while
> other code was written with other uses in mind, hence
> the inconsistencies.

Yes, I can confirm this: 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.



Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

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




Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Juri Linkov
In reply to this post by Stefan Monnier
> The difference is whether narrow-to-region really wants to pretend the
> text outside the region doesn't exist at all (e.g. in Rmail or Info), or
> whether it is just meant to temporarily only display a subpart
> (e.g. most other cases).

While fixing `Info-revert-find-node' for bug#9915, I noticed the
following comment in `Info-revert-find-node':

          ;; note goto-line is no good, we want to measure from point-min
          (goto-char (point-min))
          (forward-line wline)

This means that `goto-line' should be fixed even for non-interactive use
in Info.



Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Juri Linkov
In reply to this post by Drew Adams
> 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.

A negative line number usually means counting from the end of the buffer.



Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Drew Adams
> > 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.
>
> A negative line number usually means counting from the end of
> the buffer.

Dunno what "usually" means here.  It certainly does not mean that for
`goto-line'.  Currently, using a negative prefix arg seems to just move to line
1.

We can define what a negative arg means for `goto-line' to be anything we want.

Consistency is all well and good, especially when there are other, supporting,
good reasons to keep it up.  But it sometimes happens that "usually" gets
"established" more or less by accident/default, no better alternative having
occurred to the designer at the time.

Other suggestions welcome.  I think it would be good to be able to quickly say
whether you want numbering relative to the restriction or the whole buffer.

Of course another possibility is to simply have a separate command for that.
The only reason to use the same command and, say, a prefix arg, would be to save
keys (and user memory).  A separate `goto-line-in-restriction' is a reasonable
solution, IMO.




Reply | Threaded
Open this post in threaded view
|

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Lars Ingebrigtsen
In reply to this post by Dani Moncayo
Dani Moncayo <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

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




Reply | Threaded
Open this post in threaded view
|

bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Eli Zaretskii
In reply to this post by Lars Ingebrigtsen
> From: Lars Ingebrigtsen <[hidden email]>
> Date: Sat, 19 Sep 2020 19:42:04 +0200
> Cc: [hidden email], Stefan Monnier <[hidden email]>,
>  [hidden email]
>
> Dani Moncayo <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Juri Linkov-2
> 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



Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Lars Ingebrigtsen
Juri Linkov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Juri Linkov-2
>>> 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'.


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.
Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

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



Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Eli Zaretskii
> Date: Tue, 22 Sep 2020 13:10:09 -0700 (PDT)
> From: Drew Adams <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email],
>  [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Drew Adams
In reply to this post by Juri Linkov-2
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

Robert Pluim
>>>>> On Wed, 23 Sep 2020 10:58:11 -0700 (PDT), Drew Adams <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

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