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: Tue, 26 May 2020 17:26:34 +0100 Message-ID: <877dwyr7b9.fsf@gmail.com> References: <875zckuet9.fsf@gmail.com> <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> <87blmbrlda.fsf@gmail.com> <87pnaqrae9.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="100815"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (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 Tue May 26 18:28:19 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 1jdcR8-000Q8L-Np for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 18:28:18 +0200 Original-Received: from localhost ([::1]:50364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdcR7-0001Rj-PO for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 12:28:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdcPu-0000Gy-8Z for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34725) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdcPt-0001Iv-VI for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:27:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdcPt-0006uE-SY for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:27:01 -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: Tue, 26 May 2020 16:27:01 +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.159051040526518 (code B ref 41531); Tue, 26 May 2020 16:27:01 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:26:45 +0000 Original-Received: from localhost ([127.0.0.1]:46271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcPc-0006td-Hq for submit@debbugs.gnu.org; Tue, 26 May 2020 12:26:44 -0400 Original-Received: from mail-wm1-f41.google.com ([209.85.128.41]:50455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcPa-0006tQ-7M for 41531@debbugs.gnu.org; Tue, 26 May 2020 12:26:42 -0400 Original-Received: by mail-wm1-f41.google.com with SMTP id v19so156919wmj.0 for <41531@debbugs.gnu.org>; Tue, 26 May 2020 09:26:42 -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=zvBDeXnk2okeXkDsnXkMMpzL27SA7cke2aPe6AJflFM=; b=Jc7dJUjIQfRXUOPi1PmKYE6iEYE9KXC1ysRHtVgGGkk0Hmx7VBo4W+kTX3NYyZKFMb yHTt9+t1U1q534uwowqNitgKVlQ+VVK6GxckF3ckqaA4MjQ3Z53QnqUxlqJwWDscgRaZ G12HBA/M0xnpZREwgwFARmXoAGcSN71oHFT26/INWQFbHlR5ypnbZWFJOLCUY5FX2LFz V32h+Xw3J7S8SVnGIkXyjHV6CCvpAsB8bM10ulq3a+/CXLKp+qVuVYffUEMVxh3fPTNG iSLtIx/9DVkcetFYpmMn1tCnpZvhPjdYd/x34WeRCT2DftQG+i4JeMnpTeSzz5NweZRO +bQw== 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=zvBDeXnk2okeXkDsnXkMMpzL27SA7cke2aPe6AJflFM=; b=bKCgYVv0NC7oQJI5TMWTgVxMYKl26W7REVwortpBBFGiSPYaat24zVYmNbia56POl9 kjtZwvzQ/8an5UuE5EmicGkzqfdQ00vq8NsXGTc9dS6Xhrm9nnPwvDOKzyWO49m1k0GC phA3+UDAfvEtX+yYwVMqwJMCRPb6qObFmq14duARRm6/Udl2/13+JiuXqjz79p4tsDZS 9dTwzHnDFKbq0F0Hov3jcm/wfne4GA1AUkYCe3gDfvwGtrkWJrc0YcVorv7pQOwQWNiT 7hgVOgYOFUySNyUd0z8WxXw8mMPXb1Zk4wSqcz9mTlM+FjnQLeNFlHTEzLTHWEb/c2X+ LqoQ== X-Gm-Message-State: AOAM531iEzAxfN2RxbiaoqfOxiEuZOSDJBMnJENZYH1yNIMVGOtlYMc+ f/2DO3gWlkJXUY4PpckWNiE= X-Google-Smtp-Source: ABdhPJyNEh2FX7z0woLM5mk1p2ezYIkheraSMXnb92EnCp9xY+DkInAKJf3SyTzDos35N0+EWqOySQ== X-Received: by 2002:a05:600c:2255:: with SMTP id a21mr33335wmm.67.1590510396329; Tue, 26 May 2020 09:26:36 -0700 (PDT) Original-Received: from krug ([89.180.149.243]) by smtp.gmail.com with ESMTPSA id g18sm32386wme.17.2020.05.26.09.26.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 09:26:35 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Tue, 26 May 2020 11:56:12 -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:181053 Archived-At: [ Christopher, I'm CC-ing you in this discussion becasue we've been discussing adding futures to Emacs, and I came across your aio.el library which seems very promising. (I am, however, proposing a pragmatic intermediate solution to the particular problem in the subject) ] Stefan Monnier writes: >> It's not complete, is it? > > Don't know. I have the impression that it's complete enough to give you > the same "power" as the callback argument. > I.e. instead of (funcall BACKEND CALLBACK) > you (eldoc-future-set-callback (funcall BACKEND) CALLBACK) and instead > of (funcall CALLBACK VALUE) you (eldoc-future-set-value FUT VALUE). It is, yes. The code is clear, not transcendental at all. But writing docstrings is hard. In fact, it's possibly the hardest part of the game. Tell you what: you write the docstring for eldoc-documentation-functions, I'll do the implementation. Deal? >> And how to I use it to solve the >> eldoc-documentation-compose problem? > > AFAIK this is orthogonal to the technique we use for the backend to run > eldoc's callback code. Not really. A "proper" futures library will have primitives that handle this very elegantly. I.e. a future that depends on multiple futures, a future that applies a function to the first available future. The kind of stuff I'm sure you'll love, academically. That would be the thing to use there, otherwise we're just playing legos with structs and functions. >> I suppose it's possible, anything >> is. But do we really want to hand-roll futures in eldoc.el when we got >> this nice https://github.com/skeeto/emacs-aio/commits/master that we >> could be looking into? > > I'm not familiar with that package, so I can't judge. It might be an > even better option, indeed. I believe it has such functionality that I mentioned before. And then some. I don't understand it filly but it seems nicely coded, has two authors that have (99% sure) assigned copyright. The library calls futures "promises", by the way. >> Also the latest patch I attach solves the eldoc-documentation-compose >> problem decently (should actually be less LOC than previous versions). >> I suggest we go with this tried-and-tested well-understood solution and >> then adjust as more sophisticated solutions come along and we evaluate >> their merits. > The use of futures has been discussed forever in the context of > several packages. That's why at this stage, I think either we decide > to drop the idea or to start using it. > I'm OK with either option. Black and white, do or die? Nah, I don't buy it :-) Let me be honest: the thing I'm not crazy about in futures is that if we go the handrolled eldoc.el route that creates another distraction to maintain separately. Eldoc's problem lie elsewhere. Let's use futures in the new completion API thingy, or in an elisp json library, where they might brutally speed up parsing, by doing parsing only parts of the document that users access. Jo=C3=A3o