Confusing completion for buffer names

Confusing completion for buffer names

[Richard Stallman]

I just found out that someone made * act as a wildcard in completion.
I cannot find this in etc/NEWS.  If it is there and I am overlooking it,
can someone show me the entry that pertains to it?

That feature can be useful, and does no harm when the
completion list does not include items that contain *s.  On buffer
names, however, it leads to frequent bizarre results.

Please turn off this feature when the completion list includes a
literal match for the *.  For instance, when reading a buffer name,
if you type * l TAB, the * should be treated as literal because
there are buffer names which start with *.

If there is no buffer name starting with `*l', I want it to say
`[No match]' -- not give me `*mail*'.

Re: Confusing completion for buffer names

[Stefan Monnier]

> If there is no buffer name starting with `*l', I want it to say
> `[No match]' -- not give me `*mail*'.

One way to do that would be to have read-buffer change
`completion-styles'.  E.g. it could replace partial-completion by
substring (which I think is also more useful for buffer completion).


        Stefan

Re: Confusing completion for buffer names

[Richard Stallman]

    > If there is no buffer name starting with `*l', I want it to say
    > `[No match]' -- not give me `*mail*'.

    One way to do that would be to have read-buffer change
    `completion-styles'.  E.g. it could replace partial-completion by
    substring (which I think is also more useful for buffer completion).

That would do the job.  However, I think the general change I proposed
is better.  It is, "If a * can be interpreted as a literal match,
interpret it that way.  Otherwise it can be the special completion feature."