Jambunathan K <kjambunathan@gmail.com> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> E.g., in the code I cited, if a user does not want the same defaulting
>> behavior for commands `occur', `how-many', etc., she can set option
>> `search/replace-default-fn' to a function that distinguishes them
>> (e.g., using `this-command', as Jambunathan suggested).
>
> Interesting suggestion there.
>
> This makes me think that there is no need for multiple
> `hi-lock-read-regexp-defaults-function' and a separate
> `occur-read-regexp-defaults-function' etc.  But a single
> `read-regexp-defaults-function' that cases on `this-command'.
>
> The function can return a symbol token like `t' for `this-command's
> which it doesn't want to meddle with but return nil or a regexp or list
> of regexps for commands it wants to insinuate.
>
> Is there any problem with this `read-regexp-defaults-function'
> approach?

EXPERIMENTAL and ABANDONED PATCH

Use of `this-command' is very fragile and flaky.  Consider
`multi-occur-in-matching-buffers' which does multiple `read-regexp' -
one for the buffers and one for the actual regexp.  It is not possible
to return a two different regexps for the same `this-command'.

Interestingly, I am attaching a long from *Messages* buffer and it looks
like `this-command' is not reliable (Do you see `exit-minibuffer' in the
logs.)

So `this-command' could work for simple commands like highlighting
commands but will be flaky to be applied in general.

Anyways good to experiment and see where an idea takes us...

----------------------------------------------------------------
Customization

    (custom-set-variables
     '(read-regexp-user-defaults 
       (quote ((highlight-regexp find-tag-default-as-regexp)
               (highlight-phrase find-tag-default)
               (multi-occur-in-matching-buffers find-tag-default)))))

----------------------------------------------------------------