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

[Drew Adams <drew.adams@oracle.com>]

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