all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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'.








  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.