all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 5042@debbugs.gnu.org, juri@linkov.net, 9917@debbugs.gnu.org,
	monnier@iro.umontreal.ca, dmoncayo@gmail.com, larsi@gnus.org
Subject: bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer
Date: Wed, 23 Sep 2020 11:09:53 -0700 (PDT)	[thread overview]
Message-ID: <ddbf05f3-7365-4edf-9585-866ce3fe7e86@default> (raw)
In-Reply-To: <<83zh5gvauy.fsf@gnu.org>>

> > > 3.2. 'goto-line-relative' is bound in Info mode to `M-g M-g'.
> >
> > I gave my opinion about this.  And it was a reason given
> > for having two different commands: Do not base which
> > command gets the standard key binding on anything to do
> > with the current context - in particular, on whether the
> > buffer is narrowed.
> >
> > Please do _not_ bind `M-g M-g' to anything different in Info.
> 
> Why not?  We do this kind of thing -- have mode-specific bindings --
> all the time in Emacs.

Because we will now have two commands, with two bindings,
to let users get the behavior they want - in any mode,
any context.

Changing the binding of one of those 2 commands to invoke
the other command, makes no sense.  It takes away a
possibility (one command gets two bindings; the other
gets zero bindings).  And it confuses users.

> > Emacs should not be second-guessing users about this.
> 
> It's not second-guessing.  Info shows narrowed line numbers in its
> buffers, so from the user POV the key sequence keeps invoking the same
> command.

Info uses narrowing to show a node.  Users can further
use narrowing within a node.  Users can widen, to see
all of a file.  That Info uses narrowing for this
special purpose might be seen as a kludge.  In any
case, it's a different use of narrowing from a user's.

From a user POV the key sequence `M-g M-g' does NOT
keep invoking the same command.  If it invoked the same
command then it would still move to an absolute position.

From a user POV, the user has _lost_ a key binding for
one of the commands, and the other command now has two
bindings.

> I see no problem and don't see why you object so much.

So much?  I just presented my objection; that's all.

I see no reason for this.  I see reasons against it,
both wrt the particular case (Info) and in terms of
setting a bad precedent.

I don't object "so much".  I do think it would be a
mistake.  And it's not necessary.

At the very least, if you insist on this "so much",
then please consider swapping the two command bindings
in Info mode, and advertising this (anomalous swap).





  parent reply	other threads:[~2020-09-23 18:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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         ` bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer 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                 ` Drew Adams [this message]
2020-09-23 19:40                   ` bug#5042: " Juri Linkov
2011-10-31 14:31 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                   ` bug#9917: " Drew Adams
2020-10-29  9:19           ` 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

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=ddbf05f3-7365-4edf-9585-866ce3fe7e86@default \
    --to=drew.adams@oracle.com \
    --cc=5042@debbugs.gnu.org \
    --cc=9917@debbugs.gnu.org \
    --cc=dmoncayo@gmail.com \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    /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.