--- Begin Message ---
|
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'
--- End Message ---
--- Begin Message ---
|
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.
--- End Message ---