bug#74673: 30.0.92; face warning on legal elisp syntax

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Christopher Howard <christopher@librehacker.com>
>> Cc: 74673@debbugs.gnu.org
>> Date: Tue, 03 Dec 2024 11:48:19 -0900
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Move the mouse pointer there and wait for a split-second: you will see
>> > the answer in a tooltip.
>> >
>> 
>> Is there a way to view tooltips without making any use of the mouse? I see 
>> that I can get tooltips displayed in the echo area, but apparently I still 
>> must utilize the mouse to see the tooltip in the first place.
>
> Some nice features of the UI need the mouse, yes, and there's no
> (easy) way around that.  That said, you can go to the "" part and type
> "M-x describe-text-properties", which will pop a buffer that tells you
> there's a help-echo property at that spot, and show a button which you
> could press to have the text shown in the echo-area.
>
> If you really need to be able to show tool tips without the mouse, you
> can write a simple function to show its text in the echo-area.
> However, most tooltips are shown on UI parts where you cannot go, so
> such a command will be of somewhat limited use.

Apologies if I missed something: this specific diagnostic is also
visible with 'C-h .', right?

Feeling like this is worth mentioning because IME a lot of "mouse-bound"
information is actually reachable with display-local-help; though of
course describe-text-properties is definitely a useful tool to have in
one's kit (I usually reach for 'C-u C-x =' FWIW).

>> >> (2) should we consider using a distinct face for style warnings?
>> >
>> > What's wrong with font-lock-warning-face?
>> >
>> 
>> In my mind, a style warning is significantly different from a warning about 
>> somethat that might cause my code to malfunction when run or compiled. If 
>> there was a face specific to style warnings, I would make it a distinct and 
>> less dramatic face appearance.
>
> It's the same case: we show this in the warning face because
> oftentimes this is a mistaken code, because it's easy to misinterpret.

(IMHO the flymake-warning face (wavy underline) would be less
surprising; in fact I find this style check being part of the "regular"
font-locking a bit surprising too, this is the kind of opt-in linting
I'd expect of flymake 🤷)