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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 29 Aug 2020 16:36:51 +0100
> 
> I've recently moved `flymake-eldoc-function` from first to the last spot
> in the list.  If I hadn't done that, the default behaviour when writing
> a sexp such as, say:
> 
>    (my-dear-function [point here])
> 
> would be to foremost greet the user with the Flymake error message about
> insufficient args being supplied to the `my-dear-function` call about to
> be written, rather than what those args are supposed to be.  Obviously
> this defeats the purpose of having ElDoc serve as a code-writing aid.
> 
> But now take this other situation and suppose there is an error in the
> "foo" where point is on:
> 
>    (my-dear-function 'fo[point here]o 42 'bar)
> 
> Having the sexp written with a suitable number of arguments but with
> some Flymake mistake will now fail to notify us of those mistakes, since
> the signature information takes priority.  This is similar, if not the
> same, as the aforementioned bug#32243.
> 
> Earlier, there was no obvious solution to this, especially if one
> insisted on using only a one-line-tall echo area at the maximum.  Now,
> after Mark Oteiza's introduction of `eldoc-documentation-functions`,
> there are ways to configure suitable behaviours.  In particular there is
> `eldoc-documentation-strategy` (formerly `eldoc-documentation-function`,
> singular), which tells how to coordinate ElDoc information from multiple
> sources.
> 
> This variable's value defaults to `eldoc-documentation-default`
> globally. I suggest we default it to `eldoc-documentation-compose` in
> Elisp mode, so the three functions occupying
> `eldoc-documentation-functions` can be in play at the same time.  This
> is because the information conveyed by them can be generally be useful
> at the same time.

How will the proposed change modify the behavior in the use case with
which you started this message?