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 02:21:14 +0100 Message-ID: <87k10zsd85.fsf@gmail.com> References: <875zckuet9.fsf@gmail.com> <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> 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="105232"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: 41531@debbugs.gnu.org, Stefan Monnier , andreyk.mad@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 26 03:22:09 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 1jdOID-000RFg-K7 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 03:22:09 +0200 Original-Received: from localhost ([::1]:44618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdOIC-0000eL-IS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 May 2020 21:22:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57412) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdOI6-0000eC-La for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 21:22:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59526) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdOI6-00017H-CM for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 21:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdOI6-0000qZ-8s for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 21:22: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: Tue, 26 May 2020 01:22: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.15904560863213 (code B ref 41531); Tue, 26 May 2020 01:22:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 26 May 2020 01:21:26 +0000 Original-Received: from localhost ([127.0.0.1]:42839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdOHV-0000pk-LJ for submit@debbugs.gnu.org; Mon, 25 May 2020 21:21:26 -0400 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:35411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdOHU-0000pX-1I for 41531@debbugs.gnu.org; Mon, 25 May 2020 21:21:24 -0400 Original-Received: by mail-wr1-f48.google.com with SMTP id x14so13399513wrp.2 for <41531@debbugs.gnu.org>; Mon, 25 May 2020 18:21:23 -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=yNUl/t5+AcX0Y/KnJSnYdzvbGuQYC47GBfR3bD3EKSI=; b=OMKhDektqF8zYuPrfXk0aLqATzdAxOE5ZiJc0/Cpo/YrooPYl1MclLXfCqc77TOvNq 3TTZg8rJx3fwTT/bLHpvaI5Czo3KDRadGdQSF8Dco4m/O5a/ZOlZghlqIPjWtHVYNniX iPNp7gr9zLrMEfkXAPZHllH4z8q2gFKZKjGGCCsSnxe7z14rU4NvcQAm2KC9VogB6g0g WsbKPXZAgiq34iq/ZLYlqOX09hif7HzkD/EPB20zmefGu+4X0CtQR+0FCwy1FVtv0Ab0 zNI1HO7a4C3WQ48XmttiGKHBi5l5YiC+Agtv91E54jqNq6R3S9ooH/ISn2VG+noMEBim pV6Q== 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=yNUl/t5+AcX0Y/KnJSnYdzvbGuQYC47GBfR3bD3EKSI=; b=JsZYkI4TpSYzH22269IGnG4SSeeD3XYcQHwmWLmZR7RPd3Yx9ynNBALjZqUP0Ul1xI eThs0/DCUcnvnTP/yH01oawpvKYbpwE7XCOWvT/X8U+hfWf3tI0DFAOasirDb46hlWxU zOMdOJ7VBYaLHGAwycaYkmeyqRWA4X/eymohXNL9SuC/ztagxI6/dZ5XdBiRwLFmAx8b SK8Tsu28ON5ZI6JbDy6wkrUSym9kPtZnpdRAvYE4SnRcPSPxDjW66Qlnjz2MNU8KZTCQ uHsxf8iJi5B8thfELBQJm4q3DKKtdyp0C3geVHsrXada453UMvBPVtQ9KSzVpVqDkHIh j9Pw== X-Gm-Message-State: AOAM533SYQReOoJG5w/nMnMnxjXzwb37vCKzBFLsAInJhdUb2uCVFbYE 3xAO0EwVDqb+UV+d+BbvnNs= X-Google-Smtp-Source: ABdhPJxB4GnKYLZOfd7JtcAb9UKLdAjIDM7plbqxKi9uFqi82q9KE3Z+IKpHMbs+S/85UgwacAfsTA== X-Received: by 2002:adf:ed51:: with SMTP id u17mr8068094wro.285.1590456077970; Mon, 25 May 2020 18:21:17 -0700 (PDT) Original-Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id s5sm4343698wme.37.2020.05.25.18.21.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2020 18:21:16 -0700 (PDT) In-Reply-To: <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> (Dmitry Gutov's message of "Tue, 26 May 2020 02:52:58 +0300") 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:181011 Archived-At: Dmitry Gutov writes: > On 25.05.2020 20:04, Jo=C3=A3o T=C3=A1vora wrote: > (add-hook 'eldoc-documentation-functions > #'test-eldoc-async 0 t) > > (defun test-eldoc-async () > (cons :async > (lambda (cb) > (funcall cb "doc here!")))) Thanks. As I told you, it's not bad. These aren't exactly "futures" though, they're a way to simulate argument passing. I prefer my version, which matches what flymake.el, url.el, jsonrpc.el, sly.el and others do. > If you like, we could simplify the returned objects to be just FETCHER > (as documented in the patch) rather than (:async . FETCHER). But the=20 > latter seems more explicit. Yes, if we do go with your version, I'd like that. The latter is hard to read and understand from the docstring. Before I go any further I'd like Stefan and Andrey (or others) to weigh in. I don't have a lot of time to invest here, so if there is another vote for your proposal, I'm not going to wrestle here. To simplify, hopefully you agree that your proposal can be summarized as: "return a function that receives a function that you should call with the docstring" whereas my proposal can be summarized as: "receive a function that you should call with the docstring" > There also exist a possible modification of this patch with a bit of > functional programming where both calls to eldoc--handle-multiline=20 > happen from inside of eldoc-documentation-default's definition. Yes, that's independent of the shape of the callback we want to use. I'll leave that for later. Specifically, eldoc--handle-multiline has to do quite a bit more handling (to satisfy Andrey's expectations). Replying to parts from the other discussion in the Github tracker now. > OK, another question: if the result still /valid/? ^^ Assuming you mean "is". Well, if the client discovers the result to be invalid, it can not call the callback, or signal an error. If it is valid, call the callback. > No idea, a hypothetical one. It's an open API, not everybody is or > will be using LSP until the end of time. And it doesn't really have to > be huge. A saving is a saving. There's no free lunch. A very small saving in time for more complexity is bad. That's what overengineered means. > You can certainly kill the external process outside of it. Saving on > CPU expenses in general. The future's creditor is the only one who could do that to any useful effect. Does it have access to the process? Probably not. You would have to return a complex future with a kill switch. That's possible, but tricky, because you'd then have to be ready in the sentinel for another source of unexpected kills. > > For a poor man's async primitive, I prefer my version > So even the code savings didn't convince you? Both in eldoc.el, I do see minimal code savings in eldoc. You do remove a special variable (which is _not_ the same as a global variable, btw). I do see a much more complicated docstring, where the reader has to wrap his head around a 2-deep functional conundrum, whereas my version was 1-deep. Nothing special, but a VERY common source of headaches. Let's take your trivial example: (defun test-eldoc-async () (cons :async (lambda (cb) (funcall cb "doc here!")))) It isn't really representative of what a function that needs async would have to do, is it? Because, if you really wanted this very example, then it's much better to do the one-liner: (defun test-eldoc-async () "doc here!") Rather, presumably you would use this to fetch something from an HTTP server or so: (defun test-eldoc-async () (cons :async (lambda (cb) (url-retrieve-thingy "http://test-signature" cb)))) Where url-retrieve-thingy is very similar to our url-retrieve. Right? But why have that awkward :async there when a function is a first class object that we can identify with the functionp predicate? Let's just: (defun test-eldoc-async () (lambda (cb) (url-retrieve-thingy "http://test-signature" cb))) And at this point one wonders why the heck not (defun test-eldoc-async (cb) (url-retrieve-thingy "http://test-signature" cb)) ? > and likely in doc functions as well No. Unless I am completely mistaken (I might be), in the "doc function" not only are there no savings, but complication. This makes sense because you just inverted the responsibility: the doc function now has to "beg" for the argument that used to be given to it naturally. So, it's just a functional gimmick. As good as the next one, but a gimmick all the same. Until the "futures" are here, people will potentially bang heads in an anguished "WHY??". Why indeed? Your other argument, that this makes the transition to proper futures (such as the ones in https://github.com/skeeto/emacs-aio) easier, is questionable, too. There are two scenarios here: - You want to keep backward compatibility to this API published in eldoc 1.1.0 until the time of the Emacs 28 release: This is something that I -- and Stefan, if I'm not mistaken, -- don't think we should worry about. Just because a package is :core GNU ELPA doesn't necessarily mean we guarantee stability of its API. But if we do, then we'll have to explain in the docstring that there is a fourth return value for the hook functions. In my version we'll have to do exactly the same. - You don't want to keep backward compatibility until Emacs 28: Then, when the super-futures are here, you can just kill the CALLBACK arg if we find it doesn't fit and rewrite the docstring without concerns. Jo=C3=A3o