GNU bug report logs - #6757
24.0.50; Search field in Customize

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6757 in the body.
You can then email your comments to 6757 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; Search field in Customize
Date: Thu, 29 Jul 2010 10:22:46 -0700

There is now apparently a Search field and button in Customize.
 
1. There is no doc for this new feature, AFAICT (except a mention in NEWS).
Even the tooltip does not say what kind of search (regexps, keywords) is
involved.  There is zero help for the user for this feature.
 
2. `customize-apropos' is in fact used for this search, but the interface
to `customize-apropos' here is pretty brain-dead.
 
Example: Click mouse-1 in the search field, then type, say, `.*fer'.
*IF* you could guess (without any doc) that `Search' runs
`customize-apropos', they you would expect that the regexp you entered,
`.*fer' would be passed to `customize-apropos'.
 
But no; it is not.  The entire Search field is prepopulated with spaces!
And the regexp that is passed to `customize-apropos' contains all of the
spaces before (but not after!) the text you typed: `.*fer'.  Example
(from the debugger):
 
* customize-apropos("                          .*fer")
 
That's ridiculous.  Why would anyone expect the leading whitespace (but
not the trailing whitespace) of this field to be significant, to be part
of the regexp?
 
More precisely, both leading and trailing whitespace that the user
enters (types) *should* be significant, but not the pseudo whitespace
provided by a prefilled field.
 
The field type used for the Search widget is currently `editable-field'.
At the very least it should probably be `regexp' instead.  But as I
said, something needs to be done to ignore the prepopulated spaces - so
maybe `regexp' is not quite the answer on its own.  I'm no expert on the
Customize code, so I'm not saying what the solution is.  I'm just
reporting that from a user point of view this is a sorry feature.
 
3. Also, in a virgin Search field (nothing typed), click Search.
Because of the current behavior of counting the leading whitespace but
not the trailing whitespace, the search string used is "" (no leading
whitespace because no non-whitespace char to lead).  So you get all of
the customize options or faces.
 
And this happens without any warning.  You click Search and off goes
Emacs around the bend, digging up all options or faces.  Again, this is
ridiculous.  If a user enters `.*' then yes, we should look for all
options, but not if the user enters nothing.
 
 
 
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-07-19 on 3249CTO
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.4) --no-opt --cflags
 -Ic:/xpm/include'
 

Message #10 received at 6757-done <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: 6757-done <at> debbugs.gnu.org
Subject: Re: 24.0.50; Search field in Customize
Date: Sun, 05 Feb 2012 21:27:36 +0800

> 1. There is no doc for this new feature,
>
> 2. Click mouse-1 in the search field, then type, say, `.*fer'.
>    *IF* you could guess (without any doc) that `Search' runs
>    `customize-apropos', they you would expect that the regexp you
>    entered, `.*fer' would be passed to `customize-apropos'.
> 
>    But no; it is not.  The entire Search field is prepopulated with
>    spaces!
>
> 3. Also, in a virgin Search field (nothing typed), click Search.
>    Because of the current behavior of counting the leading
>    whitespace but not the trailing whitespace, the search string
>    used is "" (no leading whitespace because no non-whitespace
>    char to lead).

All these appear to be fixed.  Closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.