GNU bug report logs -
#11126
24.0.94; `customize-apropos' does not seem to work for a list of words
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Thu, 29 Mar 2012 19:19:01 UTC
Severity: minor
Found in version 24.0.94
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 11126 <at> debbugs.gnu.org (full text, mbox):
> This backtrace shows where the problem is.
> Debugger entered--returning value: nil
> string-match("\\(emacs\\|avoid\\).*?\\(emacs\\|avoid\\)" "avoid")
So the problem is apparently that the constructed regexp is not something that
is usefully tested against any single symbol name. The regexp requires at least
two words, for it to match. Well, yes, because a symbol name can contain
non-word characters, there are some symbols whose names include multiple words.
But that is hardly a general case or something to be expected by reading the
doc.
Is the behavior is intentional? In that case it is the doc that is wrong
(misleading, to put it mildly).
"If it is a list of words, search for matches for any two (or more) of those
words."
Matches against what? Against the set of names of customize things? Or against
only a single such name?
Who would guess that those "words" that the user inputs are matched _not_ as
words but as multiple substrings within a single customize object?
What I expected, and which would be more useful (especially since a user can
already enter a regexp), would be to be able to enter a list of words (or just
strings) and have them matched (either as words or as substrings), together,
against the set of customize objects. Not against each single such object.
Hence I expected that typing "avoid emacs" would look for all customize objects
matching either "avoid" or "emacs".
This bug report was last modified 11 years and 102 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.