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: Juri Linkov
Subject: bug#1800: 23.0.60; Changed meaning of * in buffer name completion
Date: Wed, 07 Jan 2009 01:12:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu)

> And I don't think we should adopt the behavior that if there are no matches
> under some interpretation of the input then we should try another 
> interpretation
> (and another,...). That's exactly the strategy behind the "annoyance". It can 
> be
> useful to get feedback that your input doesn't match.
>
> To me, the thing to do is keep this new behavior as an optional feature, but 
> not
> make it the default behavior. People who opt in for this will know what 
> they're
> getting, and no one will be annoyed/surprised.
>
> In a future release, if people generally prefer the optional behavior, it 
> could
> become the new default. It doesn't make sense to change the default behavior 
> now
> to something that (a) not many users have even tried, (b) was never even
> discussed at emacs-devel, and (c) is hardly documented. (The novelty and
> sometime annoyance/surprise is the main disqualifier, of course, not the lack 
> of
> adequate doc and discussion.)

There is no harm in a feature if it has no annoyance/surprise.  You said
in http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1757

    With the traditional behavior, if there are no buffers
    with prefix `*', you are told so immediately: [No match].
    With the new, partial-completion behavior, you are given possible
    completions that do not complete `*' in the normal way
    (as a literal prefix).

So implementing a message "[No match, type TAB again for * as a wildcard]"
will keep the traditional behavior just as you want.

-- 
Juri Linkov
http://www.jurta.org/emacs/






reply via email to

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