From: Drew Adams <drew.adams@oracle.com>
To: Robert Pluim <rpluim@gmail.com>
Cc: 5042@debbugs.gnu.org, Juri Linkov <juri@linkov.net>,
9917@debbugs.gnu.org, monnier@iro.umontreal.ca,
dmoncayo@gmail.com, Lars Ingebrigtsen <larsi@gnus.org>
Subject: bug#9917: 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) [thread overview]
Message-ID: <2ba7ee86-bd69-4299-9e40-b8ee79675c99@default> (raw)
In-Reply-To: <m2sgb739pg.fsf@gmail.com>
> >> 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.
next prev parent reply other threads:[~2020-09-24 17:31 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-31 14:31 bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer Dani Moncayo
2011-11-01 9:35 ` Juri Linkov
2011-11-01 17:56 ` Stefan Monnier
2011-11-01 22:35 ` Juri Linkov
2011-11-01 23:22 ` Drew Adams
2011-11-02 9:48 ` Juri Linkov
2011-11-02 12:59 ` Drew Adams
2011-11-02 9:46 ` Juri Linkov
2020-09-19 17:42 ` bug#5042: " Lars Ingebrigtsen
2020-09-19 18:01 ` Stefan Monnier
2020-09-19 19:27 ` bug#9917: bug#5042: " Drew Adams
2020-09-19 19:56 ` Eli Zaretskii
2020-09-19 18:33 ` Eli Zaretskii
2020-09-20 9:28 ` Lars Ingebrigtsen
2020-09-21 19:03 ` Juri Linkov
2020-09-22 14:37 ` Lars Ingebrigtsen
2020-09-22 18:08 ` Juri Linkov
2020-09-22 20:10 ` Drew Adams
2020-09-23 14:14 ` bug#5042: bug#9917: " Eli Zaretskii
2020-09-23 13:18 ` Lars Ingebrigtsen
2020-09-23 17:58 ` Drew Adams
2020-09-24 7:39 ` Robert Pluim
2020-09-24 17:31 ` Drew Adams [this message]
2020-10-29 9:19 ` bug#9917: " Juri Linkov
2020-10-29 14:31 ` Eli Zaretskii
2020-10-30 7:27 ` Juri Linkov
2020-10-30 8:19 ` Eli Zaretskii
2020-10-29 16:44 ` bug#5042: " Drew Adams
2020-10-30 9:49 ` Lars Ingebrigtsen
2020-10-31 19:28 ` Juri Linkov
2020-10-31 20:00 ` bug#5042: " Eli Zaretskii
2020-10-27 20:52 ` Juri Linkov
2020-10-28 9:48 ` bug#5042: " Lars Ingebrigtsen
2020-10-28 11:58 ` Dmitry Gutov
2020-10-30 9:44 ` Lars Ingebrigtsen
[not found] <<CAH8Pv0jBbJoyJfW+Xh-m3kqGQnVc0eO2+kM40SJ23JOKiBrx-A@mail.gmail.com>
[not found] ` <<877dspmzo3.fsf@gnus.org>
[not found] ` <<jwv4kntbqep.fsf-monnier+emacs@gnu.org>
[not found] ` <<28534d1c-6652-4cfe-acb4-f0a30624f878@default>
[not found] ` <<83tuvt1qwq.fsf@gnu.org>
2020-09-19 20:22 ` Drew Adams
2020-09-19 20:27 ` bug#9917: " Eli Zaretskii
[not found] ` <<83zh5l1uqw.fsf@gnu.org>
[not found] ` <<87wo0osspd.fsf@gnus.org>
[not found] ` <<87lfh3dtoj.fsf@mail.linkov.net>
[not found] ` <<878sd1j2rv.fsf@gnus.org>
[not found] ` <<871ritbs6t.fsf@mail.linkov.net>
[not found] ` <<cd8f2969-6705-46c8-b090-03e284b0ba0c@default>
[not found] ` <<83zh5gvauy.fsf@gnu.org>
2020-09-23 18:09 ` bug#5042: " Drew Adams
2020-09-23 19:40 ` Juri Linkov
[not found] <<<CAH8Pv0jBbJoyJfW+Xh-m3kqGQnVc0eO2+kM40SJ23JOKiBrx-A@mail.gmail.com>
[not found] ` <<<877dspmzo3.fsf@gnus.org>
[not found] ` <<<jwv4kntbqep.fsf-monnier+emacs@gnu.org>
[not found] ` <<<28534d1c-6652-4cfe-acb4-f0a30624f878@default>
[not found] ` <<<83tuvt1qwq.fsf@gnu.org>
[not found] ` <<1cfba469-3adf-4287-a1fa-647e4e5e83e2@default>
[not found] ` <<83pn6h1pie.fsf@gnu.org>
2020-09-19 21:10 ` Drew Adams
2020-09-20 5:34 ` bug#9917: " Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ba7ee86-bd69-4299-9e40-b8ee79675c99@default \
--to=drew.adams@oracle.com \
--cc=5042@debbugs.gnu.org \
--cc=9917@debbugs.gnu.org \
--cc=dmoncayo@gmail.com \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.