From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Wed, 03 Jun 2020 16:22:44 -0400 Message-ID: References: <875zckuet9.fsf@gmail.com> <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> <87blmbrlda.fsf@gmail.com> <87pnaqrae9.fsf@gmail.com> <877dwyr7b9.fsf@gmail.com> <871rn6r0pr.fsf@gmail.com> <875zc8nhue.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="86074"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Christopher Wellons , Dmitry Gutov , andreyk.mad@gmail.com, 41531@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 03 22:23:13 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 1jgZuq-000MGs-QX for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Jun 2020 22:23:13 +0200 Original-Received: from localhost ([::1]:44184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgZup-0003Kt-SO for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Jun 2020 16:23:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39690) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgZuh-0003H9-4a for bug-gnu-emacs@gnu.org; Wed, 03 Jun 2020 16:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33076) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jgZug-0000Wk-Rq for bug-gnu-emacs@gnu.org; Wed, 03 Jun 2020 16:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jgZug-0001Mb-OD for bug-gnu-emacs@gnu.org; Wed, 03 Jun 2020 16:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Jun 2020 20:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41531 X-GNU-PR-Package: emacs Original-Received: via spool by 41531-submit@debbugs.gnu.org id=B41531.15912157825223 (code B ref 41531); Wed, 03 Jun 2020 20:23:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 20:23:02 +0000 Original-Received: from localhost ([127.0.0.1]:44618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgZuf-0001M8-Ib for submit@debbugs.gnu.org; Wed, 03 Jun 2020 16:23:01 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgZue-0001Ld-0k for 41531@debbugs.gnu.org; Wed, 03 Jun 2020 16:23:00 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3147681177; Wed, 3 Jun 2020 16:22:54 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6843E80382; Wed, 3 Jun 2020 16:22:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1591215772; bh=2gJBJbrIAWo+ivJ2BiNjOEZQ4L/1qsfrAyVGFfiXN04=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nlqJiTc6AsrnPRn0RtGIpQ5jFcVyCydV4D/+sryaqw02mz2lxiqBVsiggPeE5HPtg 7Xx3F70GWUr07rME03ljPZyLZwz6BNiV4349N2Fom+MCJdk5p3CaF5EyqYieklRF7R Bq7e1gIm/ZUcQpD5e3ccJ9tCjnK1I2bL+pAXM5SVTc+GtYyg9AnO4hohCwtz2Nzbiw 3c4vm3PS475sT598hTJr/d4+/6jl8Imt8O2QxaevCbIgvIoP5GSU3X7opqkEW7fpGL iL2yT99F/Xrl5Guj+NINqf3Er05g+FW9GG6NHb1KuPm4rpe6W8CTVmvibYQcZ8f8oS Td9+onSVTCE0w== Original-Received: from alfajor (76-10-137-254.dsl.teksavvy.com [76.10.137.254]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ECFA71203B9; Wed, 3 Jun 2020 16:22:51 -0400 (EDT) In-Reply-To: <875zc8nhue.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 03 Jun 2020 19:07:37 +0100") 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:181477 Archived-At: >>> + "" > Ahem. >>> + "" > Ahem hem :-) Not sure what you mean ;-) >> "Special hook run to get the documentation string at point. >> Each function is called with no argument and should return either nil >> or an `eldoc-future` object that should have its `value` set as soon >> as possible via `eldoc-future-set-value` (it can be set before >> returning the future or at a later time). >> This value should be a string, typically occupying only a single line. > Sometimes clients want to return more than one value, i.e. set more than > one value. You mean a single call could return first a function signature and a while later a docstring? Or at the same time. If at the same time, then it should return them combined into a single value (concatenation of strings, list, you name it). The infrastructure so far only accepts strings as far as I know, so until that is changed the question seems moot. > The callback strategy makes it easy because there are lambda lists of > all shapes and sizes. It's trivial to use a list to bring the number back down to 1, so it's not much of a difference. > How does the future approach handle this? > Do clients return structured lists of things? If we want to extend it that way, that would be the natural thing to do, I guess. Tho without knowing what the different elements represent (i.e. some kind of semantic information about that list), I'm not sure what the callback can do with it other than presume that all elements are strings and concatenate them. >> In case the function ends up finding no information it is allowed >> not to `eldoc-future-set-value` at all." > This is problematic. In the eldoc-documentation-compose situation we > need to wait for every backend to reply before composing. We definitely don't want to wait: if a backend responds quickly we should show that info immediately, and update the info if/when another backend gives additional info. OTOH indeed for the non-composing situation, we'd need to know that the 1st backend finished unsuccessfully before being able to use the second backend. So I guess you're right: we shouldn't allow backends to drop requests :-( >> each `eldoc-documentation-function` which chooses its own callback >> rather than being chosen by their caller. > For this to work, i.e. to be able to handle multiple responses, I think > it has to be set by their caller, i.e. eldoc-print-current-symbol-info: > that's the central "hub" that maintains information about how many > backends have responded and how many haven't. I don't think this structure can work well: the "hub" needs to work differently for compose than for "return first". Stefan