From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#43609: 28.0.50; eldoc-documentation-function Date: Wed, 30 Sep 2020 15:37:01 +0100 Message-ID: <87r1qjjppu.fsf@gmail.com> References: <2e610c3f-6e5f-c7dd-af2e-aeb5e20d8664@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7864"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 43609@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 30 16:40:16 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNdHE-0001xa-40 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Sep 2020 16:40:16 +0200 Original-Received: from localhost ([::1]:36282 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNdHD-0003Hy-39 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Sep 2020 10:40:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54472) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNdF4-00028s-S9 for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2020 10:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49153) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kNdF4-0002bL-H5 for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2020 10:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kNdF4-0006Gb-E1 for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2020 10:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Sep 2020 14:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43609 X-GNU-PR-Package: emacs Original-Received: via spool by 43609-submit@debbugs.gnu.org id=B43609.160147663424035 (code B ref 43609); Wed, 30 Sep 2020 14:38:02 +0000 Original-Received: (at 43609) by debbugs.gnu.org; 30 Sep 2020 14:37:14 +0000 Original-Received: from localhost ([127.0.0.1]:60699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNdEI-0006Fb-3D for submit@debbugs.gnu.org; Wed, 30 Sep 2020 10:37:14 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:40210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNdEE-0006FN-VV for 43609@debbugs.gnu.org; Wed, 30 Sep 2020 10:37:12 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id k18so2035865wmj.5 for <43609@debbugs.gnu.org>; Wed, 30 Sep 2020 07:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=irwcj029gyWX43veQsyDCXIyTNSBmPksjN16+440Nuc=; b=clsbKNmtH5bsOz5+DNKolqyuiSb4Dna1newhB1Q9rtcsHQhZ/4yGjfYoAgFdIREMOe +R7XjvY+VPKaGgPKmrk4CYrWWkzWSmLG4S5DAqnCaIxpS0Y0KCpsWupp6gLFmMDS/3Hj 8iANjQXCSMy7oRnF5FptkH29K3t5nseb8aP1zcp4USz1MLmQB5Qw6lhr8VI8DGYDQOOe aEpFu5FfnGrLY4Le9mjgarhgBfgJbdV42ZJElyWin/J/4gK4+PjOyBrf08SzLHp7WKPh Xwuarb/4swLZ8CBoIHOuja4WOg0ceo98ERqHDBIzmVj9FC+UKhjxCaWr02/NJi5wacrY KHeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=irwcj029gyWX43veQsyDCXIyTNSBmPksjN16+440Nuc=; b=eTtDs/i8UsXnIwyexGaL+kLocuekqTj7GvUGOY7t+YlNvPX2N1/5xtsRVGnDDHwi3f hFkq73N3mOUhSRTjH0fJ0+xxNTukNFgiurX0MvEocl20fa7D3IMNzgSuNdA3XuhT0rv/ 2gztRQi3IfrrbAouGq178oWLLbRuHsvrCjLvbWetfC6lZdHibxwozz0nek+zmPXLm3lh oeLKZcknYbRjpFrLlEk6mwMhmH3QxxvvZf4OMbxGW2lY5+7VgwCt6whY9yf07rlwmUvb yaB971to3heyxSI8kraMCxX6DfQwoMYNvqxkyBcsIoWIUfAp1c8ZmhAavLxc36Fy+WCQ +KMQ== X-Gm-Message-State: AOAM531Z3oW1ZrPJ+hB9Ys/Qv3q0Gwrd9vWcXEVMeCHM2FZWDDi+RALe 0DwHiEZkpHmgSLHMn3YhR2mvstf6vWo= X-Google-Smtp-Source: ABdhPJxnRL8LKOrXadeJsuj297uH6cbAXRVclL1SZAMtzB3hZr81PgBs7/iMtIKIX2qVY5AR0C4ZbA== X-Received: by 2002:a7b:c959:: with SMTP id i25mr3573469wml.39.1601476624444; Wed, 30 Sep 2020 07:37:04 -0700 (PDT) Original-Received: from krug ([89.180.153.120]) by smtp.gmail.com with ESMTPSA id p9sm3095255wmg.34.2020.09.30.07.37.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Sep 2020 07:37:03 -0700 (PDT) In-Reply-To: <2e610c3f-6e5f-c7dd-af2e-aeb5e20d8664@gmx.at> (martin rudalics's message of "Fri, 25 Sep 2020 10:46:36 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:189347 Archived-At: martin rudalics writes: > When with emacs -Q I put the following snippet into *scratch* > > (defun foo () > (ignore)) > > move point to somewhere on "foo" and do > Hi Martin, thanks for the bug report, which I only became aware of today. I apologize for the delay in answering. > M-: (funcall eldoc-documentation-function) You're not supposed to call the that function in your programs and neither were you in Emacs 27, much in the same way you normally don't call, say, adaptive-fill-function, add-log-file-name-function or many others. That you _could_ do it in your special circumstances was incidental, though apparently useful for your third-party extension, which I wasn't aware of. Furthermore, calling eldoc-documentation-function directly in Emacs 27 simply doesn't work with a lot of major-modes/extensions that use `eldoc-mode': ElPy, SLIME, SLY, Eldoc, and probably many others. If you call the function directly in those modes, it will quite likely return something other than the desired string, which will potentially appear in the echo area only some time after. That is becasue these modes (which all work in Emacs 26, 27 and master) set eldoc-documentation-function to fetch their docstrings from asynchronous sources. Therefore, calling the function won't return the immediate value you expect, since ElDoc in Emacs 27 doesn't have any concept of "async". It is true that in Elisp mode (and maybe some other modes) you get away with it becasue it doesn't have asynchronous sources (by default, at least, and mostly becasue it doesn't need to). This is why your technique worked, under very special conditions. This is to clarify that the "direct call" protocol of Emacs 27's eldoc.el was _never_ "a thing". At any rate it was never something you could rely on generally. Anyway, eldoc-documentation-function is consulted by the Eldoc framework to provide documentation of the thing at point. The default value of that variable has changed and it follows the "new" protocol. The documentation is telling you how to craft values that you assign to the varible, not how your application should interpret them. If you need a direct call, "give me the string" entry point to the eldoc.el library, one can be added. However, its semantics depends on your use case: - Do you want to have a return value handy for the docstrings that are immediately available from the sources that respond synchronously? - Do you want to wait actively until all sources have reported back and then get a return value? In this case, do you need a timeout? - Independent of your choice above, or do you want to get the return value as list of strings? Or as a single string, maybe concatenated and propertized, exactly the way it is display But maybe we are putting the cart ahead of ourselves? Would you mind explaining exactly what you are trying to do? I suppose it's: > I am using a package that displays the string produced by that > function in a tooltip near point. Is this supposed to work only for Elisp mode or in general for every mode that uses Eldoc, such as the ones I listed above? If the former, you can probably do this (or some variation): (defun martin () "CAUTION: Only works in default Emacs Lisp mode or modes with all-sync docstring generating functions. If some functions calls the callback afterwards, that result is discarded." (let (res) (run-hook-with-args 'eldoc-documentation-functions (cl-function (lambda (doc &key thing face &allow-other-keys) (push (format "%s: %s" (propertize (format "%s" thing) 'face face) doc) res)))) (mapconcat #'identity res "\n"))) If the latter, I suggest you look at the code I have in the scratch/eldoc-display-functions branch, which seems to match your intentions/use case very closely. The docstring of the new eldoc-display-functions variable could be of use (let me know if it's insuficcient). This means your advanced tooltip-displaying technology could now work with every Eldoc mode that uses the "new" protocol (including, of course, Elisp mode). As a side note, I would take the opinions of your other interlocutor here so far with a grain of salt or two. They're not always grounded in reality. Finally, I understand the documentation for the new ElDoc framework is not very good yet: I will update it soon. Again, I apologize for the delay in answering this bug report, but I am extremely busy as of late. Next time, if you can remember, please X-Debbugs-CC: me in your fresh bug report on this matter, so that the message reaches me immediately. Sincerely, Jo=C3=A3o