bug#8397: 24.0.50; defcustom :type face

bug#8397: 24.0.50; defcustom :type face

[Drew Adams]

Emacs 22 represents a regression in user friendliness wrt previous
versions, when it comes to the Customize interface for type `face'.
 
Prior to Emacs 22, you could simply click the `Select Face' button and
then use TAB completion to see all faces and choose one.  IOW, that
button prompted you in the minibuffer for the face name, and hitting
TAB immediately (no need to type anything) showed you the names of all
faces.
 
Starting with Emacs 22, you must type some text into the face-name
field, then hit M-TAB.  So you must know some of the face name ahead of
time, instead of simply seeing all names as a reminder.
 
Please restore the more user-friendly interface of Emacs 21 and prior,
for choosing a face name.
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-03-21 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/imagesupport/include'
 

bug#8397: 24.0.50; defcustom :type face

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> Prior to Emacs 22, you could simply click the `Select Face' button and
> then use TAB completion to see all faces and choose one.  IOW, that
> button prompted you in the minibuffer for the face name, and hitting
> TAB immediately (no need to type anything) showed you the names of all
> faces.
>  
> Starting with Emacs 22, you must type some text into the face-name
> field, then hit M-TAB.  So you must know some of the face name ahead of
> time, instead of simply seeing all names as a reminder.

I don't see the problem: when the field is blank, M-TAB shows all faces
as completion alternatives.  There is no need to know any face name
ahead of time.

bug#8397: 24.0.50; defcustom :type face

[Drew Adams]

> > Prior to Emacs 22, you could simply click the `Select Face' 
> > button and then use TAB completion to see all faces and
> > choose one.  IOW, that button prompted you in the minibuffer
> > for the face name, and hitting TAB immediately (no need to
> > type anything) showed you the names of all faces.
> >  
> > Starting with Emacs 22, you must type some text into the face-name
> > field, then hit M-TAB.  So you must know some of the face 
> > name ahead of time, instead of simply seeing all names as a
> > reminder.
> 
> I don't see the problem: when the field is blank, M-TAB shows 
> all faces as completion alternatives.  There is no need to
> know any face name ahead of time.

I'm afraid my bug report isn't clear enough.  And it's been so long that I
cannot recall just what I had in mind wrt the Customize page in question.  I
don't know how to get to the field or button I reported about, unless what I
meant was the `Face:' field and `Select Face' button (for Emacs < 22) that is
associated (only?) with the `Inherit' field.  Do you happen to know ;-) how to
get to such a field/button otherwise?

If what I meant was only for `Inherit' then I agree with you that hitting M-TAB
with an empty edit field (empty input) does show all face names as completion
candidates. I don't know how I saw something different, but maybe that was the
case for an earlier Emacs 24 build or something - dunno.

FWIW, I still find the minibuffer completion easier than what M-TAB provides,
but that might be a personal preference.

One difference is this:

If you make the *Completions* window dedicated (e.g. (setq
special-display-regexps '("[ ]?[*][^*]+[*]"))), then M-TAB switches the focus to
the *Completions* frame each time you hit it.  That means you cannot just
continue to type text into the edit field - you must first reselect the
customize frame to give it focus.

With minibuffer completion, the same thing happens when the *Completions* frame
is first shown (created), but you only need to reselect the customize frame once
- thereafter you can continue to type into the edit field and hit TAB to update
*Completions*.  If you try to do that in Emacs 22+, each time you hit M-TAB the
*Completions* frame gets the focus anew, forcing you to reselect the customize
frame to type more text into the edit field.

I don't really have anything more to say about this bug.  If you feel like
closing it, go ahead.

However, there is an Emacs 24 bug here.  I tested the above with Emacs 22.  When
I try the same with Emacs 24 I see this problem:

M-TAB does NOT update *Completions* after you type more input in the edit field.
More precisely, with point at the end of your input it does not. You must move
point back to the _beginning_ of your input, and then hit M-TAB, to get the
completions of your input to show in *Completions*. I filed this as a separate
bug, #10721.  This is a regression wrt Emacs 23, which behaves normally.

bug#8397: 24.0.50; defcustom :type face

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> I don't know how to get to the field or button I reported about,
> unless what I meant was the `Face:' field and `Select Face' button
> (for Emacs < 22) that is associated (only?) with the `Inherit' field.
> Do you happen to know ;-) how to get to such a field/button otherwise?

Not ringing a bell, sorry.

> If you make the *Completions* window dedicated (e.g. (setq
> special-display-regexps '("[ ]?[*][^*]+[*]"))), then M-TAB switches
> the focus to the *Completions* frame each time you hit it.  That means
> you cannot just continue to type text into the edit field - you must
> first reselect the customize frame to give it focus.

This is an inherent limitation of special-display-regexps.  It is
possible to use display-buffer-alist to get the same effect while
leaving an exception for *Completions*.

bug#8397: 24.0.50; defcustom :type face

[Drew Adams]

> > If you make the *Completions* window dedicated (e.g. (setq
> > special-display-regexps '("[ ]?[*][^*]+[*]"))), then M-TAB switches
> > the focus to the *Completions* frame each time you hit it.  
> > That means you cannot just continue to type text into the
> > edit field - you must first reselect the customize frame
> > to give it focus.
> 
> This is an inherent limitation of special-display-regexps.  It is
> possible to use display-buffer-alist to get the same effect while
> leaving an exception for *Completions*.

Sorry, but that is just irrelevant.

Obviously, I _want_ *Completions* to be special-display, or I wouldn't have
provided a recipe that makes it so.

Saying that the problem I describe does not exist if you do not follow the
recipe that shows the problem is, well, a bit of a cop-out, don't you think?

The problem described is a problem with a special-display *Completions* buffer.
It is not a limitation of `special-display-regexps'.  There is nothing
particular that `display-buffer-alist' offers to solve this problem, AFAIK.
What's required is redirecting the *Completions* frame focus to the minibuffer.