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

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

[Lars Ingebrigtsen]

Dani Moncayo <dmoncayo@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 19 Sep 2020 19:42:04 +0200
> Cc: 9917@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
>  5042@debbugs.gnu.org
> 
> Dani Moncayo <dmoncayo@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.

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

[Eli Zaretskii]

> Date: Sat, 19 Sep 2020 12:27:13 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Dani Moncayo <dmoncayo@gmail.com>, 9917@debbugs.gnu.org,
>  5042@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.

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

[Drew Adams]

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

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

[Drew Adams]

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

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

[Eli Zaretskii]

> Date: Sat, 19 Sep 2020 14:10:55 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: monnier@iro.umontreal.ca, larsi@gnus.org, dmoncayo@gmail.com,
>         9917@debbugs.gnu.org, 5042@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Juri Linkov]

> 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

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

[Lars Ingebrigtsen]

Juri Linkov <juri@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

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: goto-line-relative.patch --]
[-- Type: text/x-diff, Size: 5295 bytes --]

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.

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.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@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

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.

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.

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 <drew.adams@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