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

Previous Next

Full log

View this message in rfc822 format

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: bug#9917: 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.

Previous Next

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