bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer
Date: Thu, 24 Sep 2020 10:31:17 -0700 (PDT)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]