bug#9591: 24.0.50; buffer name completion

[Richard Stallman]

If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'.
Killing that buffer was rather a screw.

I just fixed rmail so that won't be a screw. But I think this
completion is a bug in its own right, and should be fixed too.

I think it is a bug to complete to a buffer name that starts with a
space, when the user did not type an initial space in the buffer name.
These buffers are not supposed to be visible unless the user
specifically asks to see them.


In GNU Emacs 24.0.50.4 (mips64el-unknown-linux-gnu, GTK+ Version 2.12.12)
of 2011-09-22 on theobromine2
configured using `configure 'CFLAGS=-g -O1''

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: Emacs-Lisp

Minor modes in effect:
shell-dirtrack-mode: t
gpm-mouse-mode: t
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-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:
C-n C-n C-n ESC w C-u C-y ESC f ESC f - v i e w - b
f f DEL DEL u f f e r ESC d C-n C-a C-o TAB C-@ ESC
v C-g C-u C-u C-p C-u C-n C-n ESC f C-f C-@ ESC C-f
ESC w C-u C-@ C-u C-@ ( C-y ) ) C-l C-k C-k C-x C-s
C-a C-o TAB ; ; SPC U n s w a p SPC i r s t ESC b f
C-e , SPC s SPC DEL o SPC w e SPC d o n ' t SPC l o
s e SPC t h e SPC r e a l SPC b u f f e r SPC c o n
t e n t s . C-x C-s ESC v ESC v C-p C-p C-e ESC b ESC
b ESC b C-s C-w C-w C-w ESC < C-s C-s C-s C-s C-s C-s
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-a C-u C-p
C-p C-p C-p C-o TAB ( l e t SPC C-_ C-_ C-_ C-u C-v
C-u C-v C-u C-v C-u C-v C-u C-v C-u C-n C-u C-n C-u
C-n C-u C-n C-n C-n C-n C-o TAB ( s e t q SPC b DEL
k i l l - b u f f e r - h o o k C-a C-o TAB ( a d d
- o o DEL DEL h o o k SPC C-h f RET ESC d C-d ' C-e
SPC ' C-x 1 r m a i l - v i e w ESC - ESC / ESC / )
C-x C-s ESC x e m a c s ESC DEL r e p o r t SPC e m
a TAB RET

Recent messages:
Wrote /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el
Auto-saving...done
Saving file /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el...
Wrote /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el
Mark saved where search started
Mark set
Mark saved where search started
Undo! [3 times]
Saving file /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el...
Wrote /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el

Load-path shadows:
None found.

Features:
(shadow emacsbug find-func help-fns cc-mode cc-fonts cc-guess
cc-bytecomp cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs epa-mail log-edit easy-mmode pcvs-util add-log vc ediff-merg
ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init
ediff vc-dispatcher parse-time vc-cvs pcmpl-unix etags sgml-mode
arc-mode archive-mode mule-util cal-move cal-menu calendar
cal-loaddefs vc-bzr make-mode jka-compr ansi-color ind-util shell
pcomplete grep compile comint ring dired-aux ispell multi-isearch
rmailout dabbrev newcomment quail epa derived epg epg-config help-mode
view mailalias qp rmailmm message sendmail format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils dired regexp-opt t-mouse time-date battery paren
cus-start cus-load tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
loaddefs button faces cus-face files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar
gtk x-toolkit x multi-tty emacs)


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/

[Chong Yidong]

Richard Stallman <r...@gnu.org> writes:

> If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'.
> Killing that buffer was rather a screw.
>
> I just fixed rmail so that won't be a screw. But I think this
> completion is a bug in its own right, and should be fixed too.
>
> I think it is a bug to complete to a buffer name that starts with a
> space, when the user did not type an initial space in the buffer name.
> These buffers are not supposed to be visible unless the user
> specifically asks to see them.

Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer
so that after you type TAB, Emacs prompts with [Confirm] when you try to
exit the minibuffer immediately. `C-x b' already does this.

Maybe it would be good to enable this for "b" interactive codes.

[Richard Stallman]

Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer
so that after you type TAB, Emacs prompts with [Confirm] when you try to
exit the minibuffer immediately.

How would that change it? The buffer ` *message-viewer RMAIL*' did
exist.

Anyway, these buffers are supposed to be semi-hidden.
It isn't right for them to pop up due a completion
the user would not have expected.

[Lars Magne Ingebrigtsen]

Richard Stallman <r...@gnu.org> writes:

> Anyway, these buffers are supposed to be semi-hidden.
> It isn't right for them to pop up due a completion
> the user would not have expected.

Yeah, they ought to be hidden better than they are now. Otherwise the
distinction between "user buffers" and "hidden buffers" (i.e., the ones
that have name starting with a space) gets pretty meaningless.

But as a developer, I find that selecting the hidden buffers can be
meaningful. I think it would be a great feature is the hidden buffers
stay more hidden unless you request them, and if there was some kind of
command you could give to make them visible if you really want them to.

For instance, if you said `C-u C-x b', perhaps the hidden buffers would
be visible? And if you didn't say `C-u', the hidden buffers would be
totally hidden?

That would go for the normal `C-x b' and the ido version, too.

--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/

[Chong Yidong]

Richard Stallman <r...@gnu.org> writes:

> Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer
> so that after you type TAB, Emacs prompts with [Confirm] when you try to
> exit the minibuffer immediately.
>
> How would that change it? The buffer ` *message-viewer RMAIL*' did
> exist.

It would probably have stopped you from accidentally entering the
internal buffer by typing RET quickly after TAB.

I agree though that the completion behavior is a bit screwy: typing TAB
into the empty minibuffer does not bring up the hidden buffers in the
completion list, whereas the more agressive partial-completion method
does bring them up.

[Andreas Schwab]

Lars Magne Ingebrigtsen <la...@gnus.org> writes:

> For instance, if you said `C-u C-x b', perhaps the hidden buffers would
> be visible?

There is no need for a prefix, only to make a leading space special.

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Richard Stallman]

> Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer
> so that after you type TAB, Emacs prompts with [Confirm] when you try to
> exit the minibuffer immediately.
>
> How would that change it? The buffer ` *message-viewer RMAIL*' did
> exist.

It would probably have stopped you from accidentally entering the
internal buffer by typing RET quickly after TAB.

Why would it have done that? I don't follow.
I don't see how it would have altered anything in this scenario.

[Richard Stallman]

But as a developer, I find that selecting the hidden buffers can be
meaningful. I think it would be a great feature is the hidden buffers
stay more hidden unless you request them, and if there was some kind of
command you could give to make them visible if you really want them to.

There is supposed to be a simple way. You type a space at the beginning
of the minibuffer in order to specify these buffers.

I tried implementing this in internal-complete-buffer, but it had no effect
on the results: the hidden buffers were always visible anyway.
I guess the partial completion must have overridden it.

Partial completion is too powerful. Perhaps some extension of the
builtin completion is desirable by default, but this is too much.

[Lars Magne Ingebrigtsen]

Richard Stallman <r...@gnu.org> writes:

> There is supposed to be a simple way. You type a space at the beginning
> of the minibuffer in order to specify these buffers.

That works for the simple completion, but not for the partial completion
or ido completion.

But if the latter two were to treat initial spaces specially (to mean
just "include hidden buffers"), and then do partial/ido completion, that
would be great.

That is, if you have a buffer called " *thing*", `C-x b SPC ing TAB'
would complete to the " *thing*" buffer.

[Drew Adams]

> Partial completion is too powerful. Perhaps some extension of the
> builtin completion is desirable by default, but this is too much.

1+

It is not so much that it is too "powerful", but that it can lead to unexpected
and wildly off-the-mark completion candidates (as you point out from time to
time, apparently with new surprise each time).

The other problem, which compounds this problem, is that multiple types of
completion/matching are tried, one after the other, in hopes of finding
candidates.

The default list of matching types includes partial completion. When a whole
set of completion types (including partial) is tried in sequence, the result can
be even more disorienting than is the result of partial completion on its own.

Instead of letting a user know that a given type of matching has come up with
`[No match]', and thus letting the user decide what to do about that (e.g. try a
different type of matching - or not), it automatically assumes that the user
wants to complete the current input at all costs, so it blithely moves on to the
next type of matching in the list...

To me, it's an overly clever misfeature.

The user has no control over this, other than customization of the list of
matching types to be used automatically. Such a choice of matching method /
completion style should not be just a customization-time option.

Better would be to have only one kind of completion used at a time (no automatic
sequencing), and let users hit a minibuffer key (i.e., on demand) to change to
the next completion type.

IOW, let users choose at completion time which completion style(s) to use, on
demand. Each time they change methods they can complete anew and find out
whether there are matches using that method.

The info `[No match]' is often helpful to users. By silently skipping over
match failures, quietly moving on to try other, entirely different types of
matching, we do users a disservice. Better to give them feedback about match
failures, and give them (dynamic) control over which matching mechanism to use
at any time.

[Richard Stallman]

But if the latter two were to treat initial spaces specially (to mean
just "include hidden buffers"), and then do partial/ido completion, that
would be great.

Yes, that is what partial completion and ido completion ought to do
with buffer names.

[Stefan Monnier]

retitle 9591 Buffer substring completion matches hidden buffers.
thanks

> If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'.

Hmm... that's probably a bug of the `substring' completion-style (AFAIK
this doesn't happen with the partial-completion style).
I don't have a fix for it yet.

Stefan

[Eli Zaretskii]

> From: Stefan Monnier <mon...@iro.umontreal.ca>
> Date: Sun, 25 Sep 2011 21:18:30 -0400
> Cc: 95...@debbugs.gnu.org

>
> > If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'.
>
> Hmm... that's probably a bug of the `substring' completion-style

But `substring' is not in the default value of completion-styles. So
how does it come into play here?

By the way, this documentation of the `emacs22' style:

Prefix completion that only operates on the text before point.
I.e. when completing "foo_bar" (where _ is the position of point),
it will consider all completions candidates matching the glob
pattern "foo*" and will add back "bar" to the end of it.

and a similar doc string of `basic', are either inaccurate/wrong (it
never tells explicitly whether the "glob pattern" is interpreted as
starting at the beginning of each candidate, but if it doesn't, why
talk about "prefix"?), or there's a bug in the implementation of these
styles, because I just customized completion-styles to include only
one style, either `emacs22' or `basic', and I still see that "C-x b
Mes TAB" completes to "*Messages*". Did I do something wrong?

If these completion styles are _supposed_ to match the "glob pattern"
not only at the beginning, then we should have an additional style
that does.

I think that fixing this will go a long way towards resolving
Richard's problem, because he will then be able to customize
completion-styles and have what he wants: the traditional, less
"imaginative", but much more predictable style of completion.

P.S. FWIW, I have no problems with the default completion operation,
but that's me.

[Stephen Berman]

On Mon, 26 Sep 2011 01:35:50 -0400 Eli Zaretskii <el...@gnu.org> wrote:

>> From: Stefan Monnier <mon...@iro.umontreal.ca>
>> Date: Sun, 25 Sep 2011 21:18:30 -0400
>> Cc: 95...@debbugs.gnu.org
>>
>> > If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'.
>>
>> Hmm... that's probably a bug of the `substring' completion-style
>
> But `substring' is not in the default value of completion-styles. So
> how does it come into play here?

Via completion-category-overrides; with emacs -Q:

,----
| completion-category-overrides is a variable defined in `minibuffer.el'.
| Its value is ((buffer
| (styles basic substring)))
|
|
| Documentation:
| List of overrides for specific categories.
| Each override has the shape (CATEGORY . ALIST) where ALIST is
| an association list that can specify properties such as:
| - `styles': the list of `completion-styles' to use for that category.
| - `cycle': the `completion-cycle-threshold' to use for that category.
|
| You can customize this variable.
`----

Steve Berman

[Eli Zaretskii]

> From: Stephen Berman <stephen...@gmx.net>
> Cc: Stefan Monnier <mon...@iro.umontreal.ca>, r...@gnu.org, 95...@debbugs.gnu.org
> Date: Mon, 26 Sep 2011 09:56:12 +0200

>
> > But `substring' is not in the default value of completion-styles. So
> > how does it come into play here?
>
> Via completion-category-overrides; with emacs -Q:

Thanks. This variable should be mentioned in the doc string of
completion-styles, IMO.

Armed with this new knowledge, I customized
completion-category-overrides to nil and completion-styles to
`(emacs22), and the result is the kind of completion that Richard
wanted and expected.

[Drew Adams]

> I find arguments about defaults a waste of time.

Echoes of those who claim political discourse and politics in general are a
waste of time...

1. This thing about user surprise/confusion and lack of control is very much
about the default behavior. Someone who explicitly chooses something like
partial completion presumably knows what s?he's in for. Not necessarily so,
someone using the default settings.

You might not like discussing defaults (who does?), or you might think that
doing so is a waste of time (sometimes it is), but arguing against discussing
what the default behavior should be is simply an argument defending the status
quo without giving any reason. This is a very old story...

> I customized completion-category-overrides to nil and
> completion-styles to `(emacs22), and the result is the
> kind of completion that Richard wanted and expected.

2. That a given user such as Richard can customize away the default automatic
chaining of completion methods is not the point. The question (I raise) is
whether the default behavior should be to chain methods together.

This was a *big* change in default behavior, beyond just the differences
provided by any of the individual fancy matching methods (e.g. partial
completion matching). It was hardly discussed (discussion was more or less
discouraged, IMO).


3. My point in mentioning a user-controlled, on-demand approach (as, e.g., in
Icicles) is that:

3a. Users can still define the list of methods to try - exactly as is the case
now in Emacs (e.g. `completion-styles').

3b. Users can have Emacs *not* automatically chain these methods together. They
can have Emacs use only the first (or perhaps the last-used) method, by default.

3c. Users can nevertheless switch to the next method in the list - on demand.


4. We could also let an individual item in the methods list
(`completion-styles') be itself a list of methods, as an alternative to a single
method. When such a list item is chosen, its methods *would* be chained
together automatically. IOW, let users decide whether and how much to use
automatic chaining.


In sum:

A. Pick as the default behavior a single, simple/basic completion method, one
with few surprises.

B. Let users, as now, customize the list of available methods.

C. Let users switch to the next method in their list on demand, by hitting a
key.

D. Let users choose (opt in) to have Emacs automatically chain among some
methods, by using a list of those methods as an entry of the methods-list option
(`completion-styles').

For example (`completion-styles' values):

(basic emacs22 partial-completion) would you give basic completion by default,
and let you cycle to Emacs 22 completion on demand (only), and then to partial
completion and then back to basic..., by hitting a key in the minibuffer.

((basic partial-completion emacs22)) would give you the current,
automatic-chaining behavior by default, and would not provide for any
alternative (no other entry to cycle to, manually)

(basic (basic partial-completion emacs22)) would give you basic completion by
default, and would let you switch to the current default behavior of automatic
chaining among basic, partial, and emacs22 on demand.

And so on. Such an approach would give users control and flexibility. They
could choose whether and when switching between methods should be on-demand vs
automatic.

But the important thing is for us to choose the default behavior wisely. IMO,
the default should *not* use chaining and should probably not be partial
completion. Avoiding these would present users with fewer surprises and
gotchas, but they could still get all the bells and whistles available now - and
more - if they want.


P.S. As for polling the users, Richard said almost 3 years ago that they should
be polled for this:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1757#40

[Eli Zaretskii]

> Date: Mon, 26 Sep 2011 04:42:48 -0400
> From: Eli Zaretskii <el...@gnu.org>
> Cc: 95...@debbugs.gnu.org, r...@gnu.org

>
> > From: Stephen Berman <stephen...@gmx.net>
> > Cc: Stefan Monnier <mon...@iro.umontreal.ca>, r...@gnu.org, 95...@debbugs.gnu.org
> > Date: Mon, 26 Sep 2011 09:56:12 +0200
> >
> > > But `substring' is not in the default value of completion-styles. So
> > > how does it come into play here?
> >
> > Via completion-category-overrides; with emacs -Q:
>
> Thanks. This variable should be mentioned in the doc string of
> completion-styles, IMO.

Done (revision 105944 on the trunk).

[Stefan Monnier]

>> I think it is a bug to complete to a buffer name that starts with a
>> space, when the user did not type an initial space in the buffer name.
>> These buffers are not supposed to be visible unless the user
>> specifically asks to see them.

Having looked a bit more into it, I'm undecided:
we could go like you suggest and force users to type a leading space,
but at least for my own use this would be inconvenient, since I pretty
often need to get at hidden buffers, and often don't know the exact name
of the buffer I want (and I don't even always know whether it's a hidden
buffer or not, since Elisp authors aren't always very consistent about
it). So I find it very handy to just say "C-x b *foo TAB" (or indeed
just "C-x b foo TAB" in Emacs-24) and see all buffers that contain
"foo", regardless of whether they're hidden or not.
So it seems that both behaviors are desirable and I'm not sure how to
tell which to use when.

> Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer
> so that after you type TAB, Emacs prompts with [Confirm] when you try to

> exit the minibuffer immediately. `C-x b' already does this.

We could indeed do something like that when trying to kill a hidden
buffer (for C-x k it can't be a nonexistent buffer, of course).

> Maybe it would be good to enable this for "b" interactive codes.

confirm-nonexistent-file-or-buffer already found resistance when
I introduced it, so I expect people will complain if we generalize it to
all "b" interactive specs, tho admittedly, I haven't thought about it
very much.


Stefan

[Lars Ingebrigtsen]

Stefan Monnier <mon...@iro.umontreal.ca> writes:

> So I find it very handy to just say "C-x b *foo TAB" (or indeed just
> "C-x b foo TAB" in Emacs-24) and see all buffers that contain "foo",
> regardless of whether they're hidden or not. So it seems that both
> behaviors are desirable and I'm not sure how to tell which to use
> when.

The suggestion is that if you type `C-x b SPC foo TAB', you will then
see all buffers that have names containing the substring "foo", no
matter whether they have a leading space or not.

[Eli Zaretskii]

> From: Stefan Monnier <mon...@iro.umontreal.ca>
> Date: Thu, 29 Sep 2011 18:02:25 -0400
> Cc: r...@gnu.org, 95...@debbugs.gnu.org

>
> Having looked a bit more into it, I'm undecided:
> we could go like you suggest and force users to type a leading space,
> but at least for my own use this would be inconvenient, since I pretty
> often need to get at hidden buffers, and often don't know the exact name
> of the buffer I want (and I don't even always know whether it's a hidden
> buffer or not, since Elisp authors aren't always very consistent about

> it). So I find it very handy to just say "C-x b *foo TAB" (or indeed

> just "C-x b foo TAB" in Emacs-24) and see all buffers that contain
> "foo", regardless of whether they're hidden or not.
> So it seems that both behaviors are desirable and I'm not sure how to
> tell which to use when.

There's what Lars suggested, which sounds like it can cater to both
use cases.

Failing that, add some non-default completion style which behaves like
you want. I hope _you_ have no problems with customizing for
non-default behavior ;-)

> confirm-nonexistent-file-or-buffer already found resistance when
> I introduced it

I don't understand the resistance: that feature saved my a$$ a few
times, when my fingers were faster than my brain.

[Stefan Monnier]

>> Having looked a bit more into it, I'm undecided:
>> we could go like you suggest and force users to type a leading space,
>> but at least for my own use this would be inconvenient, since I pretty
>> often need to get at hidden buffers, and often don't know the exact name
>> of the buffer I want (and I don't even always know whether it's a hidden
>> buffer or not, since Elisp authors aren't always very consistent about
>> it). So I find it very handy to just say "C-x b *foo TAB" (or indeed
>> just "C-x b foo TAB" in Emacs-24) and see all buffers that contain
>> "foo", regardless of whether they're hidden or not.
>> So it seems that both behaviors are desirable and I'm not sure how to
>> tell which to use when.
> There's what Lars suggested, which sounds like it can cater to both
> use cases.

[ Going back to re-read it. ]
Ah, now I see what he meant.

I guess we could provide an ad-hoc completion style for buffers, but
that's kind of ugly: completion styles are supposed to be agnostic to the
underlying completion table and vice-versa.

> Failing that, add some non-default completion style which behaves like
> you want. I hope _you_ have no problems with customizing for
> non-default behavior ;-)

Indeed, I don't have a problem with that, tho I always prefer a solution
where no configuration is necessary (i.e. find a middle ground).


Stefan

[Richard Stallman]

The suggestion is that if you type `C-x b SPC foo TAB', you will then
see all buffers that have names containing the substring "foo", no
matter whether they have a leading space or not.

That seems like a reasonable thing for substring completion to do
on buffer names. I think substring completion should not be enabled
for buffer names by default, since it is too wild in its behavior.

[Richard Stallman]

I guess we could provide an ad-hoc completion style for buffers, but
that's kind of ugly: completion styles are supposed to be agnostic to the
underlying completion table and vice-versa.

For common UI features in Emacs, convenience is more important than
uniformity. This is one of them. Space at the start of a buffer
name has always had special treatment in several ways; turning off
the special treatment for completion is simply a bug.

[Eli Zaretskii]

> Date: Sat, 01 Oct 2011 10:05:02 -0400
> From: Richard Stallman <r...@gnu.org>
> CC: el...@gnu.org, 95...@debbugs.gnu.org

>
> I guess we could provide an ad-hoc completion style for buffers, but
> that's kind of ugly: completion styles are supposed to be agnostic to the
> underlying completion table and vice-versa.
>
> For common UI features in Emacs, convenience is more important than
> uniformity. This is one of them. Space at the start of a buffer
> name has always had special treatment in several ways; turning off
> the special treatment for completion is simply a bug.

I think you are, in fact, in agreement with Stefan, who pointed out
that making this special treatment the subject of a special style is
not a good idea.

[Richard Stallman]

I think you are, in fact, in agreement with Stefan, who pointed out
that making this special treatment the subject of a special style is
not a good idea.

I had a different interpretation for what he said, but I suppose
he will make his position clear.

[Stefan Monnier]

> I think you are, in fact, in agreement with Stefan, who pointed out
> that making this special treatment the subject of a special style is
> not a good idea.
> I had a different interpretation for what he said, but I suppose
> he will make his position clear.

I've installed a change which should solve your problem by only showing
internal buffers when the user requested them explicitly.


Stefan