Perhaps as simple as adding help modes to hi-lock-exclude-modes?  It looks
like hi-lock mode exclusion logic might need a little improvement to honor
derived modes.

On Sun, Mar 2, 2025 at 12:33 PM Daniel Colascione <dancol@dancol.org> wrote:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> From: Daniel Colascione <dancol@dancol.org>
> >>> Date: Sun, 02 Mar 2025 10:49:15 -0500
> >>>
> >>> >From emacs -Q, M-x global-hi-lock-mode, then C-h m, then quit the help
> >>> buffer, and type C-h m again.  You'll get prompted about whether you
> >>> want to apply the hi-lock patterns in the help buffer.  And then,
> >>> because for some reason we don't actually clear the help buffer but
> just
> >>> narrow it to what we want, the next time you ask for help, even on
> >>> something unrelated to hi-lock (e.g. progn), hi-lock will ask you
> >>> whether you want to apply hi-lock patterns.
> >>
> >> That's the default of hi-lock-file-patterns-policy, no?  IIUC, hi-lock
> >> asks this question for every file you visit, if it finds the patterns
> >> there.
> >>
> >> Or what am I missing?
> >
> > The default is `ask`, which is documented to mean:
> >
> >     If `ask', prompt when patterns found in buffer; if bound to a
> >     function,
> >
> > but `(describe-function 'progn)` doesn't describe any patterns.
> >
> > (FWIW, I'm very much not a fan of this default.  If the user didn't want
> > them highlighted, she would not have turned on `global-hi-lock-mode`.)
>
> Isn't the idea that hi-lock patterns can contain arbitrary font lock
> keywords which can run arbitrary code?
>
>
>
>