bug#11095: [PATCH] Re: bug#11095: 24.0.94; hi-lock-face-buffer/unhighlight-regexp': Augment?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> -(defface hi-yellow
> +(defface hi-lock-1

I'm not sure it's an improvement.  When choosing a face in
hi-lock-face-buffer, "hi-lock-1" doesn't speak much to me contrary to
"hi-yellow".

So, could you expand on your motivations for this change, so we can find
another solution that satisfies your use case and mine?

I've installed your second patch (the hi-lock-auto-select-face, tho
using `pop' to simplify the code), but when hi-lock-auto-select-face is
t the user can't specify a face any more, which I think is too drastic,
which should provide a C-u override or something.

I also installed the 4th patch (the defaults for unhighlight), tho
I removed the docstring change (we usually don't document which default
is used in minibuffer arguments).  Also I moved your code to a separate
function, to clarify the code.  Furthermore I did not install your
change to the completion table so only the regexps that match at point
get completed.  Instead the list of regexps is passed as a list
of defaults.

BTW the hi-lock-auto-select-face should be fixed to just hash-cons (aka
uniquify) regexps, so you don't need your maphash loop to recover the
regexp from the unique "serialized" number.

I also installed the 5th patch (the "unhighlight all") tho I'm not
yet sure this is the right interface.  OT1H I think it would be nicer to
provide this "all" as one of the choices in the minibuffer, but OTOH
I can't think of any way to do that which is not hideously hackish.

As for the 3rd patch, I haven't installed it yet because I'm worried
that (format "\\_<%s\\_>" (regexp-quote tag)) may sometimes fail to
match `tag', so I think it needs some additional sanity check.


        Stefan