unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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





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