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#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Sun, 05 Jul 2020 00:07:01 +0100 Message-ID: <87h7umop62.fsf@gmail.com> References: <875zckuet9.fsf@gmail.com> <87sgecssch.fsf@gmail.com> <87tuynsdp6.fsf@gmail.com> <5d768a69-3574-10c5-e80a-8ab77ec60462@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="blaine.gmane.org:116.202.254.214"; logging-data="21149"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (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 Sun Jul 05 01:08:49 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 1jrrH6-0005Qj-TS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jul 2020 01:08:49 +0200 Original-Received: from localhost ([::1]:37390 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrrH5-0002NF-WD for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jul 2020 19:08:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jrrGM-0001WR-Ts for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 19:08:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48269) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jrrGM-0006hc-LI for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 19:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jrrGM-00034G-GR for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 19:08: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: Sat, 04 Jul 2020 23:08: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.159390403411723 (code B ref 41531); Sat, 04 Jul 2020 23:08:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 23:07:14 +0000 Original-Received: from localhost ([127.0.0.1]:59812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrrFa-000331-6X for submit@debbugs.gnu.org; Sat, 04 Jul 2020 19:07:14 -0400 Original-Received: from mail-wm1-f41.google.com ([209.85.128.41]:40673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrrFX-00032g-Hf for 41531@debbugs.gnu.org; Sat, 04 Jul 2020 19:07:13 -0400 Original-Received: by mail-wm1-f41.google.com with SMTP id f139so37881995wmf.5 for <41531@debbugs.gnu.org>; Sat, 04 Jul 2020 16:07:11 -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=wzmstFM2nirKqdgvgjrpnmm3EO1tqEETCdLgHUEy4x8=; b=Qox142n01LfINeRjWVo0GLABwGmbYhz96or2L96VIH6LpfogXbkeJOZXsJ1N3BO95/ FPhdCTy5BNG6MP5VsZeTaqUwPLp7Bo/OqOvLT9PqUkLb5KCzOfGB8+uObEJQutABKx20 vLle+O5oIX0PxkWaBsEi1byTN3nxFJAMZ3+0TJWAcaRg9xSbSYQO+eiI6E1FSwRFsjIM qt45AO3jI7ZtDozczRKBGhGzJpOoqVC9sG4tEpe5VJHkFzYi3XSOgkG5iyg1y4lGYQaF v6hPXg80JYMRjv7ZD/BqQddKrQ3vkKE1/o0fwuzHXL5T+oZcaMjDjbyYjRTjC0dlEotH YAQw== 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=wzmstFM2nirKqdgvgjrpnmm3EO1tqEETCdLgHUEy4x8=; b=QLnhNOthldiHjfPuqe8GNg+p3JOCNjOZ/umPHc+PQTHtG2PeB7o7TlsrX8iq3ZWU+h Lum1BIfv0qxG5uyygsHcyf3HhpbHHhQnEslRkpvo9B7sXfH7NaaiV++vaKOiyyNTEK7O QDmUI2OLdg0B1AKdafj/UZAAG7E2hFo3ioMFaXRVviPPqE6ZqSmEFKfaEp7ga75/w+Nw qVtxbY0H+iENz+/H906GmZHVHkRwofvrO36hnuIOUlSVmyH1b6OfABaaJmTie01INDSu 1oZ/nr81ghCfXUEgAhbqUICeM+k6xCEVcJ/832f5WG8HHWetkSQuCXc4Ez3GyCOlVfPq XXKg== X-Gm-Message-State: AOAM530Spcr6+jG02Dru6Am4eV2MlE68enygtpe/mdtEI0obnmT8+oBY QLWvSWKpERYeqJJDGBwT9e4= X-Google-Smtp-Source: ABdhPJzEHxOhLhZIYAVXwO8/3aUwvo/xGN9U5//B1RtjSTBUVAYxN1ysF/uLKEzuAgEJR0aYv9PsFw== X-Received: by 2002:a1c:345:: with SMTP id 66mr26954065wmd.31.1593904025409; Sat, 04 Jul 2020 16:07:05 -0700 (PDT) Original-Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id s8sm18157627wru.38.2020.07.04.16.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jul 2020 16:07:04 -0700 (PDT) In-Reply-To: <5d768a69-3574-10c5-e80a-8ab77ec60462@yandex.ru> (Dmitry Gutov's message of "Sun, 5 Jul 2020 00:27:20 +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:182723 Archived-At: Dmitry Gutov writes: > [that is the] "transition" I meant here. > > If you have other questions, please ask. If it wasn't clear, my suggestion is that you send your earlier dimtry-futures.el (as I am temporarily dubbing it, for clarity) to emacs-devel, along with a rationale for why it is needed and where it can be useful, not only in eldoc.el but in other places in Emacs that use callbacks like like url.el, flymake.el, jsonrpc.rl, timers, completion, processes, etc. You may want to include a short comparison to Christopher Wellon's aio.el, if you have studied it. > I think I have described at length the very simple idea of what it is > supposed to improve: provide a standard primitive and a library of=20 > composition/manipulation functions that would make these operations > simpler. Which can be used in Emacs core, and in clients of the > various facilities and expose future-based interfaces. Maybe I missed something, but I don't consider our discussion an at-length discussion. It might have been verbose, but it wasn't in-depth at all. And certainly it didn't involve anywhere enough people for such an ambitious feature. I have some comments to your last proposed dmitry-futures.el, but this bug report is not the place to make them. >> And I've seen no feedback from the author of what seems to >> be the most promising futures library, aio.el which uses the >> generator.el library, to provide, presumably, more elegant >> "language-level" futures (i.e. futures that aren't only hiding the >> callback in some other object). > > I'm very curious to know Christopher's opinion myself. Based on my > experience, this will result in a much longer, protracted discussion, > if it will result in one at all. > > You seem to be in a hurry to get this in for some reason, but I'm fine > with waiting a little more, if we get a better result. I want to fix longstanding problems in Eglot. I have limited resources, mainly time. It is you who seem intent on not letting this go in, as if you won't be able to prove that "better result" after it does. This is absurd: if you do show it to be better, then we should migrate eldoc.el etc to futures. ...as I've said a trillion times already at this point. > Please recall how you rejected my proposal along the same lines. I don't remember your proposal fixing anything in eldoc.el, you merely suggested I experimented with a technique. Which I actually did, and I didn't see any advantage in it. > And it's fine. We can do better. I'm sorry you don't like my work. I had good feedback about it. If _you_ can do better, I'm not stopping you. >> And, again, for the nth time, there is nothing in my code that prevents >> your -- or someone else's -- "futures" library to be the nec plus ultra >> of async in Emacs. But, in the meantime, I won't let you make these >> Eldoc changes hostage to your predilection for futures. > > "won't let you" is not exactly how things work here. We usually try > hard to reach a consensus. In my book, there's nothing legitimate in vetoing a bugfix because of some yearning for some particular abstraction or programming paradigm. That's as absurd as demanding Emacs be rewritten in my paradigm/language of choice before anyone else commits anything. Especially when, for the quadrillionth time, there is nothing stopping you from making your case for futures after the bug is fixed. > In any case, I have considered this for some time, and my arguments > for "let's work on this some more" won't be limited to > futures-vs-callbacks. In that case, if indeed they are not futures-vs-callbacks, are they _serious_ objections? Can they not be fixed afterwards? I would have expected some manifestation of them already, but you seem to waste all your energy on your proclivity for futures. But very well then, let's have those non-futures objections in this bug report, the sooner the better. >> legitimate inclination, of course, it musn't be needlessly put it in the >> way of other's work. > > I agree that there are improvements to be made in > documentation-related code (whether it's in Eldoc, or not), and I also > think that you might not be going far enough in some respects. > > But the problem you seem to be urgent to fix (having eldoc-message > called from client code) is not so terrible that we can't wait until > the future-related discussion at least has had a chance to happen. I've explained repeatedly: this is holding up multiple things in Eglot. I want Eglot to serve diagnostic messages, and various kinds of automatically gathered information about the "things at point" all through eldoc.el. Then move on to better stuff, of which there is a lot in LSP, as you well know. Also, this fixes SLY and SLIME too, both hacking their way through eldoc.el. Possibly the same for CIDER and other such extensions. This also opens up eldoc.el in non-async situations as well, such as elisp-mode.el. Just read the patch. Look, Dmitry, think clearly: I'm going to fix eldoc.el and you can have your futures.el discussion when you want, a discussion where don't know if I'll be able to participate, but that shouldn't prevent it from happening. After that discussion, whatever conclusion you, possibly me, and other interested parties arrive at, as long as you/we keep Eglot and SLY functional, or suggest improvements to them, I'll abide. Jo=C3=A3o