From: "João Távora" <joaotavora@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Glenn Morris <rgm@gnu.org>, Noam Postavsky <npostavs@gmail.com>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: master 9ade7ea: Fix Eldoc problem when loading on Emacs 26.3
Date: Fri, 10 Jul 2020 23:41:47 +0100 [thread overview]
Message-ID: <874kqfdmc4.fsf@gmail.com> (raw)
In-Reply-To: <jwv5zav9g43.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 10 Jul 2020 18:16:17 -0400")
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
next prev parent reply other threads:[~2020-07-10 22:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200710004934.18557.69586@vcs0.savannah.gnu.org>
[not found] ` <20200710004936.2935520A27@vcs0.savannah.gnu.org>
2020-07-10 16:09 ` master 9ade7ea: Fix Eldoc problem when loading on Emacs 26.3 Glenn Morris
2020-07-10 17:09 ` João Távora
2020-07-10 17:36 ` Noam Postavsky
2020-07-10 17:54 ` João Távora
2020-07-10 19:57 ` João Távora
2020-07-10 21:35 ` Stefan Monnier
2020-07-10 21:58 ` João Távora
2020-07-10 22:16 ` Stefan Monnier
2020-07-10 22:41 ` João Távora [this message]
2020-07-10 23:44 ` Stefan Monnier
2020-07-11 8:06 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874kqfdmc4.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=npostavs@gmail.com \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).