Re: master 9ade7ea: Fix Eldoc problem when loading on Emacs 26.3

[Stefan Monnier]

>>>> Maybe come up with a better idea, or maybe, like Stefan suggests, don't
>>>> make it an alias at all, just deprecate it and keep using it instead of
>>>> eldoc-documentation-strategy when we find it to be bound.
>>> That sort of works, but it forces extensions that do want to
>>> "Package-Require" eldoc to remember to unbind
>>> eldoc-documentation-function if they are loaded on older Emacs versions,
>>> which is undesirable.

No.  If they're only written for the old API they set
`eldoc-documentation-function` and live in blissful ignorance of what
they miss.  If they're only written for the new API, they add-hook to
`eldoc-documentation-functions` and live in bliss.

And if they want to support both they do

    (if (boundp 'eldoc-documentation-functions)
        (add-hook 'eldoc-documentation-functions ...)
      (setq eldoc-documentation-function ...))

>> Maybe use a rule like:
>>
>>     (if (and (buffer-local-p 'eldoc-documentation-function)
>>              (not (buffer-local-p 'eldoc-documentation-functions)))
>>         <Use `eldoc-documentation-function`>
>>       <Use `eldoc-documentation-functions`>
>
> Sounds a bit complicated for me, especially since there's already a
> eldoc--supported-p which does similar heuristics.

But that's one of the other benefits.  It lets us distinguish in
`eldoc--supported-p` the case where `eldoc-documentation-strategy` was
set from the case where  `eldoc-documentation-function` was set.

> Wouldn't it break in some older Emacs version that loads the new Eldoc
> and has some global value in eldoc-documentation-functions (say,
> a spell-checking eldoc backend)?

The above `buffer-local-p` tests would be in eldoc.el, not in the client
packages, so I don't see what scenario you're worried about.
And of course the presence of a global value doesn't affect
`buffer-local-p` anyway, so ... I guess I must be missing something?


        Stefan