Subject: Re: bug#76687: global-hi-lock-mode prompts on its own help

From: Stefan Kangas <[email-masked]>
Date: Mon, 3 Mar 2025 06:54:56 -0800

Eli Zaretskii <[email-masked]> writes:

>> From: Stefan Kangas <[email-masked]>
>> Date: Mon, 3 Mar 2025 13:39:38 +0000
>> Cc: [email-masked], [email-masked]
>>
>> Eli Zaretskii <[email-masked]> writes:
>>
>> >> From: Ship Mints <[email-masked]>
>> >> Date: Sun, 2 Mar 2025 13:56:37 -0500
>> >> Cc: Stefan Kangas <[email-masked]>, Eli Zaretskii <[email-masked]>, [email-masked]
>> >>
>> >> 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.
>> >
>> > Any reason why Help mode should be exempt from global-hi-lock-mode?
>> > This bug report shows a single instance of that mode which perhaps
>> > needs to be fixed, so why disable the mode for all of the Help
>> > buffers?
>>
>> First, isn't the bug here that you get a prompt despite there being no
>> Hi-lock lines?  Why would you prompt in that case?
>
> I understood that there _are_ Hi-lock lines in that buffer.

Right, so more precisely there are two bugs:

1. We incorrectly treat the examples from the hi-lock-mode docstring as
   highlighting patterns in the *Help* buffer.

2. We incorrectly consider the examples from the hi-lock-mode docstring,
   when looking at _other_ docstrings, after having looked at that one.

I think adding help-mode to `hi-lock-exclude` would solve both bugs,
however see below.

>> Second, and orthogonally, perhaps special-mode should be in
>> hi-lock-exclude modes by default.
>
> Again, I find no reasons to exclude special-mode.  People may wish to
> highlight a regexp everywhere.

That's true.  The issue is that `hi-lock-exclude-modes' disables all
highlighting, even when manually added.  That is undesirable, I agree.

This suggests that we need a more fine-grained control that disables
only the "Hi-lock:" pattern handling (i.e. only the unsafe part).