bug#13892: 24.3.50; Provide for customizing default regexp in hi-lock commands

[Jambunathan K <kjambunathan@gmail.com>]

Juri Linkov <juri@jurta.org> writes:

>> +(defvar hi-lock-read-regexp-defaults-function
>> +  'hi-lock-read-regexp-defaults
>> +  "Function that provides default regexp(s) for highlighting commands.
>> +This function should take one argument OP and return one of nil,
>> +a regexp or a list of regexps for use with highlighting command
>> +OP.  OP, a symbol, can be one of `phrase', `line' or `nil'
>> +signifying commands `hi-lock-face-phrase-buffer',
>> +`hi-lock-line-face-buffer' and `hi-lock-face-buffer'
>> +respectively.
>
> Requiring an additional argument `op' means that we wouldn't
> be able to customize `hi-lock-read-regexp-defaults-function'
> to just `find-tag-default' or `find-tag-default-as-regexp'.
> I think there is no need to distinguish between different
> hi-lock commands since one user would very likely prefer
> the one way to get the default for all hi-lock commands,
> so you could call `hi-lock-read-regexp-defaults-function'
> without arguments.

I had the same thought but ended up with having an OP.

If we want to remove OP but still want the ability to choose the regexp
based on the highlighting command, then may be `this-command' can take
the place of OP.

ps: Does EmacsLisp have notion of function pointers (as in C).  Here the
function pointer is not declared and the function pointer could well be
set in a .emacs file.  So there is no way the byte-compiler can complain
based on arity.  Does runtime check for arity? (I don't think so).  May
be (i.e., technically) it is OK to call a function that takes no
argument with a single argument?  I don't know.  Let's see what others
think.