all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <rms@gnu.org>, "'Lars Magne Ingebrigtsen'" <larsi@gnus.org>
Cc: 9591@debbugs.gnu.org
Subject: bug#9591: 24.0.50; buffer name completion
Date: Sun, 25 Sep 2011 11:45:05 -0700	[thread overview]
Message-ID: <E5667BC0F60545249C7DA85E5713E62E@us.oracle.com> (raw)
In-Reply-To: <E1R7sau-00022C-FY@fencepost.gnu.org>

> Partial completion is too powerful.  Perhaps some extension of the
> builtin completion is desirable by default, but this is too much.

1+

It is not so much that it is too "powerful", but that it can lead to unexpected
and wildly off-the-mark completion candidates (as you point out from time to
time, apparently with new surprise each time).

The other problem, which compounds this problem, is that multiple types of
completion/matching are tried, one after the other, in hopes of finding
candidates.

The default list of matching types includes partial completion.  When a whole
set of completion types (including partial) is tried in sequence, the result can
be even more disorienting than is the result of partial completion on its own.

Instead of letting a user know that a given type of matching has come up with
`[No match]', and thus letting the user decide what to do about that (e.g. try a
different type of matching - or not), it automatically assumes that the user
wants to complete the current input at all costs, so it blithely moves on to the
next type of matching in the list...

To me, it's an overly clever misfeature.

The user has no control over this, other than customization of the list of
matching types to be used automatically.  Such a choice of matching method /
completion style should not be just a customization-time option.

Better would be to have only one kind of completion used at a time (no automatic
sequencing), and let users hit a minibuffer key (i.e., on demand) to change to
the next completion type.

IOW, let users choose at completion time which completion style(s) to use, on
demand.  Each time they change methods they can complete anew and find out
whether there are matches using that method.

The info `[No match]' is often helpful to users.  By silently skipping over
match failures, quietly moving on to try other, entirely different types of
matching, we do users a disservice.  Better to give them feedback about match
failures, and give them (dynamic) control over which matching mechanism to use
at any time.






  parent reply	other threads:[~2011-09-25 18:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-24 12:28 bug#9591: 24.0.50; buffer name completion Richard Stallman
2011-09-24 18:44 ` Chong Yidong
2011-09-24 23:52   ` Richard Stallman
2011-09-25  0:19     ` Lars Magne Ingebrigtsen
2011-09-25  8:35       ` Andreas Schwab
2011-09-25 17:34       ` Richard Stallman
2011-09-25 17:52         ` Lars Magne Ingebrigtsen
2011-09-26  1:00           ` Richard Stallman
2011-09-25 18:45         ` Drew Adams [this message]
2011-09-25  1:04     ` Chong Yidong
2011-09-25 17:34       ` Richard Stallman
2011-09-29 22:02   ` Stefan Monnier
2011-09-29 22:39     ` Lars Ingebrigtsen
2011-09-30 21:03       ` Richard Stallman
2011-09-30  6:42     ` Eli Zaretskii
2011-09-30 19:39       ` Stefan Monnier
2011-10-01 14:05         ` Richard Stallman
2011-10-01 14:15           ` Eli Zaretskii
2011-10-01 20:54             ` Richard Stallman
2011-10-02  0:27               ` Stefan Monnier
2011-09-26  1:18 ` Stefan Monnier
2011-09-26  5:35   ` Eli Zaretskii
2011-09-26  7:56     ` Stephen Berman
2011-09-26  8:42       ` Eli Zaretskii
2011-09-27 17:45         ` Drew Adams
2011-09-27 18:52         ` 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=E5667BC0F60545249C7DA85E5713E62E@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=9591@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=rms@gnu.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 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.