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

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

[Richard M Stallman]

The change to treat * as a wildcard is often a pain in the neck.
Such changes should not be made without polling the users first.

Please undo this change, poll the users, and redo the change
if they generally want it.



In GNU Emacs 23.0.60.16 (mipsel-unknown-linux-gnu, GTK+ Version 2.12.11)
 of 2009-01-03 on lemote-yeeloong
configured using `configure  'CFLAGS=-O0 -g -Wno-pointer-sign' 'mipsel-unknown-linux-gnu' 'build_alias=mipsel-unknown-linux-gnu' 'host_alias=mipsel-unknown-linux-gnu' 'target_alias=mipsel-unknown-linux-gnu''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  gpm-mouse-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
R e a s o n SPC a s SPC a SPC c r i m e C-n C-n C-n 
C-n DEL C-x o ESC v C-x o I SPC w i s h SPC I SPC c 
o u d SPC DEL DEL l d SPC g o SPC t o SPC y o u r SPC 
t a l , SPC DEL DEL k , SPC b u t SPC s i n c e SPC 
I SPC a m SPC n t SPC DEL DEL o t SPC i n SPC C a l 
i r o f DEL DEL DEL f o r n i a , RET I SPC c a n ' 
t . ESC q SPC SPC H a v e SPC y o u SPC w r i t t e 
n SPC a b o u t SPC t h i s ? RET RET I SPC w o u d 
SPC DEL DEL ESC DEL c o u l d SPC t r y SPC t o SPC 
f i g u r e SPC o DEL i t SPC o u t SPC f o r m SPC 
DEL DEL SPC m y s e l f , SPC b u t SPC I SPC a m SPC 
n o t s u r e RET C-u C-b C-b SPC C-n t h a t SPC w 
o u l d SPC b e SPC l a w f u l . RET C-u C-u C-p C-n 
C-n C-n C-o b c c : SPC r e s p w C-c C-c C-d m e m 
a c s C-g ESC x r e p o r t SPC e m a c s SPC b u g 
RET

Recent messages:
Sending...
Wrote /home/rms/outgoing/out-36
Sending...done
Expunging deleted messages...done
Expunging deleted messages...done
Mark set [2 times]
Auto-saving...done
Sending...
Wrote /home/rms/outgoing/out-37
Sending...done
Quit

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

[Juri Linkov]

> The change to treat * as a wildcard is often a pain in the neck.
> Such changes should not be made without polling the users first.
>
> Please undo this change, poll the users, and redo the change
> if they generally want it.

This is a nice feature, but I have the same problems with it.
Trying to switch to a killed buffer that had `*' at the beginning
of its name (e.g. *grep*) typing `* g TAB' displays a large list
of irrelevant buffer names.

Regular expressions allow a backslash before `*' for a literal character.
So `\ * g TAB' could try completion literally without interpreting
`*' as a wildcard.  But I think this would be inconvenient.

A better variant is to provide two-step completion.  So when there is
no buffer matching `*g' literally then display a message like

  [No match, type TAB again for * as a wildcard]

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

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

[Stefan Monnier]

> Trying to switch to a killed buffer that had `*' at the beginning
> of its name (e.g. *grep*) typing `* g TAB' displays a large list
> of irrelevant buffer names.
[...]
>   [No match, type TAB again for * as a wildcard]

Here's another option: only treat * as a wildcard if it doesn't match
anything existing.  I.e. if you have buffers that start with "*", then
"*g" will not treat the * as a wildcard.  To force the use of
a wildcard, we could let the user type "**g".


        Stefan

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

[Juri Linkov]

>> Trying to switch to a killed buffer that had `*' at the beginning
>> of its name (e.g. *grep*) typing `* g TAB' displays a large list
>> of irrelevant buffer names.
> [...]
>>   [No match, type TAB again for * as a wildcard]
>
> Here's another option: only treat * as a wildcard if it doesn't match
> anything existing.  I.e. if you have buffers that start with "*", then
> "*g" will not treat the * as a wildcard.  To force the use of
> a wildcard, we could let the user type "**g".

It seems unlikely not to have a buffer that starts with "*".
There are always such buffers as *scratch*, *Messages*, *Completions*.
OTOH, "**g" will help, but it has the same drawback as using "\*g"
for a literal character *, i.e. it is not as obvious as using a single *.

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

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

[Drew Adams]

> >> Trying to switch to a killed buffer that had `*' at the beginning
> >> of its name (e.g. *grep*) typing `* g TAB' displays a large list
> >> of irrelevant buffer names.
> >> [No match, type TAB again for * as a wildcard]
> >
> > Here's another option: only treat * as a wildcard if it 
> > doesn't match anything existing.  I.e. if you have buffers
> > that start with "*", then "*g" will not treat the * as a
> > wildcard.  To force the use of a wildcard, we could let
> > the user type "**g".
> 
> It seems unlikely not to have a buffer that starts with "*".
> There are always such buffers as *scratch*, *Messages*, *Completions*.
> OTOH, "**g" will help, but it has the same drawback as using "\*g"
> for a literal character *, i.e. it is not as obvious as using 
> a single *.

I don't agree that this ad hoc escaping is a good solution, but I'm not going to
argue about it here and now. This is the kind of thing that can be discussed
rationally and by a larger group - after the release and with this in practice
as an option, not as the new default.

IOW, keep the default behavior as it has always been, add the new feature, and,
after the release, discuss the possible problems it introduces and possibile
solutions, with the added experience and input of a user base.

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

[Richard M Stallman]

    Here's another option: only treat * as a wildcard if it doesn't match
    anything existing.  I.e. if you have buffers that start with "*", then
    "*g" will not treat the * as a wildcard.  To force the use of
    a wildcard, we could let the user type "**g".

That too would more or less solve the problem.

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

[Drew Adams]

> > The change to treat * as a wildcard is often a pain in the neck.
> > Such changes should not be made without polling the users first.
> >
> > Please undo this change, poll the users, and redo the change
> > if they generally want it.
> 
> This is a nice feature, but I have the same problems with it.
> Trying to switch to a killed buffer that had `*' at the beginning
> of its name (e.g. *grep*) typing `* g TAB' displays a large list
> of irrelevant buffer names.
> 
> Regular expressions allow a backslash before `*' for a literal
> character. So `\ * g TAB' could try completion literally
> without interpreting `*' as a wildcard.  But I think this would
> be inconvenient.
> 
> A better variant is to provide two-step completion.  So when there is
> no buffer matching `*g' literally then display a message like
> [No match, type TAB again for * as a wildcard]

I don't think we should start making special treatment here for buffer names.

SM> Here's another option: only treat * as a wildcard if it doesn't match
SM> anything existing.  I.e. if you have buffers that start with "*", then
SM> "*g" will not treat the * as a wildcard.  To force the use of
SM> a wildcard, we could let the user type "**g".

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.)

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

[Juri Linkov]

> 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/

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

[Drew Adams]

> > 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.

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

Beyond the multiple possibilities of surprise or confusing behavior, what's the
hurry? Why bend over backwards to force this upon users as the new default
behavior? Even if we take as given that the new behavior is interesting and can
be useful, why the need to suddenly switch to this behavior?

What's wrong with offering this as an option? There already is a user option
that controls this. All that's needed is to change the default value of that
option to the singleton list '(basic), to keep the traditional behavior as the
default.

We can then also document well the possibility of the new behavior that combines
basic with partial completion etc. - nothing wrong with advertizing this. What's
wrong is to make it the default with no track record, no discussion, no poll.

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

[Juri Linkov]

>> 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.

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

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

[Drew Adams]

> >> 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.

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

[Drew Adams]

> > >> 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'.

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

[Juri Linkov]

> 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)'.

I think we should replace `partial-completion' in the default
value of `completion-styles' with a new completion method, e.g.
`confirm-partial-completion'.

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

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

[Drew Adams]

> > 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)'.
> 
> I think we should replace `partial-completion' in the default
> value of `completion-styles' with a new completion method, e.g.
> `confirm-partial-completion'.

Providing `confirm-partial-completion' as another alternative completion style
is fine, but why make it the default behavior? What's wrong with the traditional
behavior as default?

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

[Juri Linkov]

>> > 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)'.
>>
>> I think we should replace `partial-completion' in the default
>> value of `completion-styles' with a new completion method, e.g.
>> `confirm-partial-completion'.
>
> Providing `confirm-partial-completion' as another alternative completion style
> is fine, but why make it the default behavior? What's wrong with the traditional
> behavior as default?

More users will be able to use all the benefits of partial completion
without its annoyances.

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

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

[Richard M Stallman]

    A better variant is to provide two-step completion.  So when there is
    no buffer matching `*g' literally then display a message like

      [No match, type TAB again for * as a wildcard]

That is a good idea.  It would provide the same benefit of the
existing feature, but without the inconvenience.

bug#1800: marked as done (23.0.60; Changed meaning of * in buffer name completion)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]


Your message dated Sat, 15 Aug 2009 18:27:06 -0400
with message-id <87skfslnlx.fsf@cyd.mit.edu>
and subject line Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion
has caused the Emacs bug report #1800,
regarding 23.0.60; Changed meaning of * in buffer name completion
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1800: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1800
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3385 bytes --]

From: Richard M Stallman <rms@gnu.org>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; Changed meaning of * in buffer name completion
Date: Tue, 06 Jan 2009 07:31:14 -0500
Message-ID: <E1LKB5W-0007uA-Hw@fencepost.gnu.org>

The change to treat * as a wildcard is often a pain in the neck.
Such changes should not be made without polling the users first.

Please undo this change, poll the users, and redo the change
if they generally want it.



In GNU Emacs 23.0.60.16 (mipsel-unknown-linux-gnu, GTK+ Version 2.12.11)
 of 2009-01-03 on lemote-yeeloong
configured using `configure  'CFLAGS=-O0 -g -Wno-pointer-sign' 'mipsel-unknown-linux-gnu' 'build_alias=mipsel-unknown-linux-gnu' 'host_alias=mipsel-unknown-linux-gnu' 'target_alias=mipsel-unknown-linux-gnu''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  gpm-mouse-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
R e a s o n SPC a s SPC a SPC c r i m e C-n C-n C-n 
C-n DEL C-x o ESC v C-x o I SPC w i s h SPC I SPC c 
o u d SPC DEL DEL l d SPC g o SPC t o SPC y o u r SPC 
t a l , SPC DEL DEL k , SPC b u t SPC s i n c e SPC 
I SPC a m SPC n t SPC DEL DEL o t SPC i n SPC C a l 
i r o f DEL DEL DEL f o r n i a , RET I SPC c a n ' 
t . ESC q SPC SPC H a v e SPC y o u SPC w r i t t e 
n SPC a b o u t SPC t h i s ? RET RET I SPC w o u d 
SPC DEL DEL ESC DEL c o u l d SPC t r y SPC t o SPC 
f i g u r e SPC o DEL i t SPC o u t SPC f o r m SPC 
DEL DEL SPC m y s e l f , SPC b u t SPC I SPC a m SPC 
n o t s u r e RET C-u C-b C-b SPC C-n t h a t SPC w 
o u l d SPC b e SPC l a w f u l . RET C-u C-u C-p C-n 
C-n C-n C-o b c c : SPC r e s p w C-c C-c C-d m e m 
a c s C-g ESC x r e p o r t SPC e m a c s SPC b u g 
RET

Recent messages:
Sending...
Wrote /home/rms/outgoing/out-36
Sending...done
Expunging deleted messages...done
Expunging deleted messages...done
Mark set [2 times]
Auto-saving...done
Sending...
Wrote /home/rms/outgoing/out-37
Sending...done
Quit



[-- Attachment #3: Type: message/rfc822, Size: 1285 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: 1800-done@emacsbugs.donarmstrong.com
Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion
Date: Sat, 15 Aug 2009 18:27:06 -0400
Message-ID: <87skfslnlx.fsf@cyd.mit.edu>

> Trying to switch to a killed buffer that had `*' at the beginning
> of its name (e.g. *grep*) typing `* g TAB' displays a large list
> of irrelevant buffer names.

This has been fixed for a while, so I'm closing this bug.