From: "Drew Adams" <drew.adams@oracle.com>
To: <1800@emacsbugs.donarmstrong.com>, "'Juri Linkov'" <juri@jurta.org>
Cc: emacs-pretest-bug@gnu.org, rms@gnu.org
Subject: bug#1800: 23.0.60; Changed meaning of * in buffer name completion
Date: Wed, 7 Jan 2009 08:48:26 -0800 [thread overview]
Message-ID: <000c01c970e7$c3bb2d30$c2b22382@us.oracle.com> (raw)
In-Reply-To: <000901c970e0$799e6a20$0200a8c0@us.oracle.com>
> > >> So implementing a message "[No match, type TAB again for * as
> > >> a wildcard]" will keep the traditional behavior just as you want.
> > >
> > > No, there are plenty of other annoyances/surprises for
> > > users in this new behavior, besides the `*' buffer one.
> > > I gave two good examples in the report for
> > > bug #1512, neither involving wildcards or necessarily buffers.
> > >
> > > http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1512
> >
> > Asking for another TAB before doing partial completion will solve
> > both your problems.
>
> That is not the case today. The inappropriate completions are
> presented immediately - exactly like RMS's case (but without
> wildcards). Are you referring to your suggestion that the
> implementation not try partial completion until the
> user confirms with a second TAB?
>
> That suggestion seemed to depend on the presence of wildcards
> (e.g. the message). Are you saying now that the implementation
> should _always_ require a second TAB before performing partial
> completion, when basic completion fails?
>
> If so, wouldn't that conflict with the desire by someone who
> really wants this new feature - someone who wants p.c. to
> happen automatically and immediately whenever traditional
> completion fails? Or would you add an option to indicate
> whether such confirmation is required? Required in all cases
> or just some (e.g. wildcards)?
>
> Rather than try, now, in a discussion with only two or three
> people, to redesign this new feature on the fly to counter
> some of the annoyances already encountered, why don't we just
> keep it as it is for now, but not make partial
> completion part of the _default_ behavior?
>
> Let people try it as something optional. They will likely
> have good suggestions,
> if need be, about how to counter, inhibit, or prevent some of
> the annoyances -
> when and how best to do that. They will have the benefit of
> experience, and
> experience with lots of different use cases (and potential
> annoyances/surprises).
>
> Honestly, I think that, _especially_ if you want this new
> feature to be accepted, it makes more sense to keep as an
> option for now, and let people discover its value (via
> some doc - still missing) and spread that news by word
> of mouth, than it does to impose it as the new default
> behavior. Doing the latter is likely to bring more
> resistance and bug reports - we've already seen a
> few. Doing the former is likely to attract people to it as
> something new and cool.
>
> Imagine if Kim had decided, as soon as he wrote Ido, that it
> should become the new default behavior for Emacs (had he
> alone been in a position to decide). Just add this new
> feature as an option. Time will tell whether it should
> become the default behavior.
One more thing to keep in mind -
This is not (necessarily) about partial completion. The new feature is that a
list of completion methods is used, in order, to try to complete user input.
That list is the value of `completion-styles', which by default is `(basic
partial-completion)'.
Hence it doesn't make sense to hard-code any interaction that depends on partial
completion. For example, what is a wildcard for partial completion might not be
for some other completion method that is an element of `completion-styles'.
next prev parent reply other threads:[~2009-01-07 16:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87skfslnlx.fsf@cyd.mit.edu>
2009-01-06 12:31 ` bug#1800: 23.0.60; Changed meaning of * in buffer name completion Richard M Stallman
2009-01-06 19:00 ` Juri Linkov
2009-01-06 22:14 ` Stefan Monnier
2009-01-06 22:54 ` Juri Linkov
2009-01-07 5:35 ` Drew Adams
2009-01-07 20:09 ` Richard M Stallman
2009-01-06 22:36 ` Drew Adams
2009-01-06 23:12 ` Juri Linkov
2009-01-07 5:35 ` Drew Adams
2009-01-07 12:07 ` Juri Linkov
2009-01-07 15:56 ` Drew Adams
2009-01-07 16:48 ` Drew Adams [this message]
2009-01-07 17:43 ` Juri Linkov
2009-01-07 18:05 ` Drew Adams
2009-01-07 19:30 ` Juri Linkov
2009-01-06 22:59 ` Richard M Stallman
2009-08-15 22:35 ` bug#1800: marked as done (23.0.60; Changed meaning of * in buffer name completion) Emacs bug Tracking System
2009-03-09 21:25 bug#1800: 23.0.60; Changed meaning of * in buffer name completion Xavier Maillard
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='000c01c970e7$c3bb2d30$c2b22382@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=1800@emacsbugs.donarmstrong.com \
--cc=emacs-pretest-bug@gnu.org \
--cc=juri@jurta.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.