Attached is a rather hacky patch for slime-apropos. If string is recognized as an Emacs regular expression then the result of calling SWANK:APROPOS-LIST-FOR-EMACS with "" instead of string is subsequently filtered by Emacs' string-match. Otherwise slime-apropos works as usual.

This is more a proof of concept than a patch intended to be applied by the SLIME maintainers. I'd like slime-apropos to be regex-aware but I'm not sure what would be the best way.

Some thoughts:

1. It'd probably be best if this regex behaviour of slime-apropos were optional. As the prefix arg is already used there are a couple of options:

- Make the regex behaviour another optional y-or-n-p argument like only-external-p.

- Let the user customize this behaviour via a variable like, er, slime-apropos-uses-regex-syntax-p.

- Define another function slime-regex-apropos and let the user bind it to C-c C-a if he so wishes.

2. My childish hack will be inaccetably slow on many machines and Lisps because in the regex case the Lisp always has to return all symbols and Emacs subsequently has to match them all. It'd be Lispier and much faster to do the regex matching on the Lisp side. CL-PPCRE, for instance, has a facility to do that but it would certainly be overkill to include such a big package with SLIME. (Plus, I think slime-apropos should use Emacs regex syntax as it is an Emacs package.)

[I'm offline while I write this but I seem to remember that I've somewhere (in CLOCC?) seen a CL package for Emacs Lisp. Does my memory serve me right? Does this package provide Emacs Lisp regular expressions for CL?]

3. My hack matches on the returned "designator" and thus a regex like "ke.*ns" will match a symbol like KERNEL:CONS-TYPE, i.e. package prefixes aren't currently treated consistently.

4. The hack pops up an empty *SLIME Apropos* buffer if there's no match - no good.

Anyway, what do you think about this?

Cheers, Edi.