unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>,
	"'Reuben Thomas'" <rrt@sc3d.org>
Cc: 8492@debbugs.gnu.org
Subject: bug#8492: 23.3; Time to use a different binding for completion?
Date: Wed, 20 Apr 2011 08:49:19 -0700	[thread overview]
Message-ID: <C2A2FF60CE5940B5B9D0ABDAA43B74CA@us.oracle.com> (raw)
In-Reply-To: <jwv8vv5rrsu.fsf-monnier+emacs@gnu.org>

> Currently, the "usable default" is ESC TAB.
> It's a bit longwinded, so it'd be good to find a better solution.

It's not very longwinded.  It was used for a very long time before ALT + TAB was
available for the same thing.  It was used by many perfectly capable and fast
programmers, including the one who wrote Emacs (practically overnight) and gcc.
;-)  Likewise `C-M-i' - not very longwinded, and long available for this.

And anyway it doesn't really matter all that much how longwinded a _default_
binding is.  (Yes, there is no reason to purposefully use longer bindings when
better, shorter ones can be found.)

> Since this problem has been around for a long time and no good key has
> popped up during this time, I believe that using TAB is the
> way forward, which means we need to figure out ways to make it work in
> the cases where it currently doesn't.

So your logic is that simply because you cannot find an available key you want
to complicate the behavior of the command so that it acts, in effect, as
multiple commands depending on the context.

That's not a good argument.  Occam stands with his razor against it - you are
multiplying things needlessly.

Keep it simple.  Find a key or let users find their own key for a simple,
straightforward command (i.e., that does only what M-TAB does currently).
Forget about combining 36 different behaviors on the same key.

In practice, so-called "DWIM" too often means lousy, half-baked compromises and
"do-what-some-programmer-who-thought-herself-clever-figured-would-be-innovative-
and-loved-by-everyone".  The "I" in DWIM is too seldom the user, and the "WIM"
is too seldom accurate.

Do I really care, for M-TAB or `completion-at-point'?  Not much.  I do care that
we needlessly complicate the behavior of keys with compromised,
not-so-clever-after-all DWIM-wittedness.

Please go back to the problem itself and look for a simple solution _to it_.

M-TAB is not easily available on several systems.  OK, so you want a different
key as the default binding for `completion-at-point' (or whatever).  OK, so pick
another key.  Problem solved.

But please do not redesign the behavior to become hydra-headed so it tries to
adapt to multiple contexts, just because you cannot think of a good default key.
That makes little sense.

And TAB, in particular, is *not* "the way forward for this".  If ever there was
a key *not* to double-up on for this (triple? quadruple? pentuple?), TAB is it.
It's just about the poorest choice possible here.

(Yes, I am aware that some users have done exactly what you suggest and like the
effect.  Pick any behavior and you will find some users who are happy with it to
the point of proselytizing.  But such a chimera is not a good solution for
vanilla Emacs.)

Just one opinion, and no, I do not really care much.  But this is misguided,
IMHO.






  parent reply	other threads:[~2011-04-20 15:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-13 17:26 bug#8492: 23.3; Time to use a different binding for completion? Reuben Thomas
2011-04-15 19:53 ` Stefan Monnier
2011-04-15 22:53   ` Reuben Thomas
2011-04-15 23:21     ` Lennart Borgman
2011-04-19 12:46       ` Stefan Monnier
2011-04-19 13:01         ` Lennart Borgman
2011-04-19 13:34           ` Stefan Monnier
2011-04-19 18:53             ` Lennart Borgman
2011-04-24 18:08   ` Chong Yidong
2011-04-24 19:43     ` Drew Adams
2011-04-24 19:55     ` Reuben Thomas
2011-04-19 10:52 ` Andrew W. Nosenko
2011-04-19 12:21   ` Lennart Borgman
2011-04-20 11:54   ` Reuben Thomas
2011-04-20 13:18     ` Stefan Monnier
2011-04-20 13:22       ` Reuben Thomas
2011-04-20 14:16         ` Stefan Monnier
2011-04-20 14:49           ` Sven Joachim
2011-04-20 16:41           ` David De La Harpe Golden
2011-04-20 17:11             ` Deniz Dogan
2011-04-20 18:28               ` David De La Harpe Golden
2011-04-20 22:02                 ` Lennart Borgman
2011-04-21  0:13               ` Sean Sieger
2011-04-21  6:02                 ` Deniz Dogan
2011-04-20 17:17             ` Eli Zaretskii
2011-04-20 22:03               ` Lennart Borgman
2011-04-21  6:43                 ` Eli Zaretskii
2011-04-20 21:59           ` Lennart Borgman
2011-04-20 14:07       ` Deniz Dogan
2011-04-20 15:49       ` Drew Adams [this message]
2011-04-20 18:28         ` Reuben Thomas
2011-04-20 22:48           ` Stefan Monnier
2011-04-20 22:49             ` Reuben Thomas
2011-04-20 21:56       ` Lennart Borgman
2011-04-20 22:49         ` Drew Adams
2011-04-20 22:51           ` Reuben Thomas
2011-04-21 12:42           ` Lennart Borgman
2011-04-21 14:13             ` Drew Adams
2011-04-21 18:49               ` Lennart Borgman
2011-04-21 19:34                 ` Reuben Thomas
2011-04-21 19:54                   ` Lennart Borgman
2011-04-21 20:14                     ` Reuben Thomas
2011-04-21 20:55                       ` Lennart Borgman
2011-04-21 21:08                         ` Reuben Thomas
2011-04-22 13:47                           ` Lennart Borgman
2011-04-22 17:33                             ` Reuben Thomas
2011-04-22 18:12                               ` Lennart Borgman
2011-04-22 21:01                     ` Sean Sieger
2011-04-22 21:09                       ` Lennart Borgman
2011-04-22 20:44                 ` Sean Sieger
2021-10-21 19:44 ` Stefan Kangas
2021-10-21 19:45   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-21 20:11     ` Stefan Kangas
2021-10-22  6:30   ` Phil Sainty
2021-10-22  8:12     ` Stefan Kangas
2022-04-29 12:38 ` Lars Ingebrigtsen
2022-04-29 13:22   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-29 13:25   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-29 13:33     ` Lars Ingebrigtsen
2022-04-29 15:14   ` Drew Adams

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C2A2FF60CE5940B5B9D0ABDAA43B74CA@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=8492@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rrt@sc3d.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).