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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 19 Sep 2020 21:33:59 +0300

> From: Lars Ingebrigtsen <[email-masked]>
> Date: Sat, 19 Sep 2020 19:42:04 +0200
> Cc: [email-masked], Stefan Monnier <[email-masked]>,
>  [email-masked]
> 
> Dani Moncayo <[email-masked]> 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.