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

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

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

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 13:22:41 -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
> 
> 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.

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

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

[Juri Linkov]

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

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

[Juri Linkov]

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

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  5042@debbugs.gnu.org,
>   9917@debbugs.gnu.org,  monnier@iro.umontreal.ca,  dmoncayo@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.

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

[Juri Linkov]

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

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  5042@debbugs.gnu.org,  9917@debbugs.gnu.org,
>   monnier@iro.umontreal.ca,  dmoncayo@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.

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

[Juri Linkov]

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