From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Wed, 03 Jun 2020 21:36:42 +0100 Message-ID: <877dwnnaxx.fsf@gmail.com> 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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="14618"; 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: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 03 22:37:14 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 1jga8Q-0003iq-MI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Jun 2020 22:37:14 +0200 Original-Received: from localhost ([::1]:58954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jga8P-0002iG-Ot for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Jun 2020 16:37:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jga8I-0002i7-TW for bug-gnu-emacs@gnu.org; Wed, 03 Jun 2020 16:37:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33093) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jga8H-0002pu-IS for bug-gnu-emacs@gnu.org; Wed, 03 Jun 2020 16:37:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jga8E-0001hn-GK for bug-gnu-emacs@gnu.org; Wed, 03 Jun 2020 16:37: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, 03 Jun 2020 20:37: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.15912166136540 (code B ref 41531); Wed, 03 Jun 2020 20:37:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 20:36:53 +0000 Original-Received: from localhost ([127.0.0.1]:44639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jga84-0001hQ-UD for submit@debbugs.gnu.org; Wed, 03 Jun 2020 16:36:53 -0400 Original-Received: from mail-wr1-f43.google.com ([209.85.221.43]:36881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jga83-0001hD-Pg for 41531@debbugs.gnu.org; Wed, 03 Jun 2020 16:36:52 -0400 Original-Received: by mail-wr1-f43.google.com with SMTP id x13so3787006wrv.4 for <41531@debbugs.gnu.org>; Wed, 03 Jun 2020 13:36:51 -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=Cun6DictJEL/DEQnc2DdbCyzpTJNS9NvC80Guol8Les=; b=E58/7DbhHTK7x/UEygVLR1DWg6fivcs8L7JKtE/J6T/hM/SHeRT4ukrudKJ1/2h6UN VzLd/QNe3XJ4xwTID0ReaQmat6+07LfP/aJZrKf1F+KYOfn/jCMQJxGv1M0GvEQhKTzM NWNV3+4rN+E8e87/EUlMgGPRfX2m9XkDU2WW7NrFyfecC/n9+wAU53tixzz7QExOMru4 SyAjPnna/Ynut3tYMJCll+PtOGH8jkuIQi2ptDSTILvSgiDjiCJtoY5hjthfw4ow1dtO Su1zDzMK9Vfrjtul4xsTGUf6tic4so/NurunQCNDFVPxjLn9Kcb8Lspaa4qZR1uRnwIv zPag== 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=Cun6DictJEL/DEQnc2DdbCyzpTJNS9NvC80Guol8Les=; b=e8aXckmQDvqH2UxpNhbLs4WPOLt0s4z4FbVPKAk53d96HZBXJ/kq7p+9QSJnjMcCWQ Guavst05ZsFNbO1OvnMX3ATZTfbLVU8xI1KgmlvQuScZD7xlrb2NsFa6cBGiN4lP96Dn fsI3POqaRhj6cErSl/PJPuZAdhPxMkTL6PzPfoJ2LcvJX0BKQLuvz+aYO/b/YM68k85o fajeNGxez2W9wKql2vChVvtgQJGBG8mmUeQs/+qaPaYi4EDQG3Wgzz/QPWFk6U/z2NaA 57QVpZ7IwNup9Ey26stciR6Md67qG4yxzIfwDnaw9ZXUp4CEBCKRdUlonGUk71JbooW8 V9GQ== X-Gm-Message-State: AOAM531hJVALglekSL/BbSlTKgIWcolppGCZOoSd+GyxycxYeMOmKCY8 q9jfV15w3fu+LsemUW+IlWY= X-Google-Smtp-Source: ABdhPJw6MBbZ8Y5tLuf0LZBoHmcSnRrDvug6+R4xPLKomJgBa1OSXy+jTZc0dCvh1BRkKkCTshWuAg== X-Received: by 2002:adf:dc8e:: with SMTP id r14mr1013239wrj.333.1591216605574; Wed, 03 Jun 2020 13:36:45 -0700 (PDT) Original-Received: from krug (89-180-148-153.net.novis.pt. [89.180.148.153]) by smtp.gmail.com with ESMTPSA id 40sm5303387wrc.15.2020.06.03.13.36.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 13:36:44 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 03 Jun 2020 16:22:44 -0400") 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:181479 Archived-At: Stefan Monnier writes: >>>> + "" >> 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? No, that's not what I mean. Those should be two different members of eldoc-documentation-functions (plural). I meant producing metadata about the string just returned. Much like string properties, I suppose, but not specifically attached to regions of the string. > The infrastructure so far only accepts strings as far as I know, so > until that is changed the question seems moot. Very soon that might change, but yes. >> 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. Yes, I agree, but it's IMO easier to read (funcall cb :foo 42 :baz 23) than (set-value fut (list :foo 42 :baz 23)). >> 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. See my most recent patches, there are many ways to handle differently formated and differently timed reports. >>> 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. That depends. Depends on the strategy. I don't take eldoc-documentation-compose to mean that, for example. But we could easily have eldoc-documentation-compose-wait and eldoc-documentation-compose-eager. > 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 :-( I also don't take eldoc-documentation-default to mean that. I take it to mean: focus on the first guy that promised he would produce something. But we could indeed have a "focus on the first guy that actually produced something". >>> 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". Yes, of course it works differently. How "well" is another question, whose details I don't fuilly understand. In the last patches I showed it works decently well, i.e. I don't see anything wrong with it. I implemented eldoc-documentation-default, eldoc-documentation-compose, and something eldoc-documentation-eager which is like "default" but will show the first one, and potentially replace with a slower, but more important one. These were all done "in the hub", without lots of code. I'm fairly confident other strategies can be implemented "in the hub" easily. In fact, a much better name for eldoc-documentation-function (singular) is eldoc-documentation-strategy, not least because it relieves us from this silly singular/plural confusion. Jo=C3=A3o