bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1800: 23.0.60; Changed meaning of * in buffer name completion


From: Drew Adams
Subject: bug#1800: 23.0.60; Changed meaning of * in buffer name completion
Date: Wed, 7 Jan 2009 08:48:26 -0800

> > >> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]