bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: 43103@debbugs.gnu.org,  larsi@gnus.org,  monnier@iro.umontreal.ca
>> Date: Sat, 29 Aug 2020 17:07:48 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > How will the proposed change modify the behavior in the use case with
>> > which you started this message?
>> 
>> In the use case I started this message with, the user has enabled
>> Flymake.  Instead of seeing only the function signature in the echo area
>> -- and being denied the presumed Flymake diagnostic "beneath it" -- this
>> user would now see both items of information in two lines of said echo
>> area.
>
> So the user will see both the function's signature and the Flymake's
> error message because the call's syntax is not yet complete?  That
> sounds sub-optimal, doesn't it? why show an error message when the
> user is clearly still typing the code?

For me it's really not clear.  What if the user changed the function
signature elsewhere or the compilation the error check is based on might
is looking at a different version of the library that has another
protocol.  When point is on those invalid calls, it's quite useful to be
alerted to both the error and the signature.  Also note this happens in
any mode that uses Flymake and provide signatures, not just Elisp.

So, situations where the user is typing function calls from scratch do
happen, but they're not necessarily the majority -- it depends on the
editing work.  I will agree with you that displaying the transient error
on those situations is alarmist and not very useful, but it's better
fixed by adjusting 'flymake-no-changes-timeout' (or some other heuristic
that makes Flymake less eager) than asserting that the simultaneous
display of both pieces of information isn't useful _in general_.  It is.
In fact, I recall bug reports in Eglot that repeateadly state so.

>> A similar reasoning applies to other situations with two competing
>> different sources of context or "at point" documentation.  Currently,
>> even without Flymake there are function signatures and variable
>> docstrings, for example.
>
> I'm talking specifically about Flymake, because it reports errors,
> not just any information.

More precisely, it reports "diagnostics", which may be errors, warnings,
notes, or really any annotation about a region in your source.

Anyway, from your statement, it seems you'd be OK (or at least find less
problematic) that the two Flymake-unrelated lines:

    eldoc-idle-delay: Number of seconds of idle time to wait before printing.
    run-with-idle-timer: (SECS REPEAT FUNCTION &rest ARGS)  [SECS is boldface]

Being shown when point hovers on the second atom of the form

    (run-with-idle-timer eldoc-idle-delay nil ...)

?