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

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> 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.

I was describing my own earlier solution, by the way, where I'm pretty
sure that would happen.

> 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?

Maybe I am, surely.  This is complicated, and I'm probably not seeing
through the complexity as well as you are.  If you want to do these
changes I won't object, but I'd probably mess them up.

At least for now, I really do think the best way is to alias the two
variables.  Whichever way we alias them, it's just as if I never renamed
the singular "e-d-function" to "e-d-strategy" at all, which is, after
all, a much safer bet.  I've even thought about dropping the whole
"rename function to strategy" idea completely, which was just a cosmetic
way to escape the awful mind-bending confusion between "e-d-function"
singular and "e-d-functions" plural.

So I think I'm going to go with the simple alias patch, unless you (or
someone) strongly opposes.

João