Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 18:32:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 14:32:43 2020 Received: from localhost ([127.0.0.1]:39062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jtEs6-0004yU-RQ for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 14:32:43 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:40918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jtEs5-0004yC-G1 for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 14:32:41 -0400 Received: by mail-wm1-f41.google.com with SMTP id f139so4220285wmf.5 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 11:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=k9uBWhAimbshRgi1fv6bV7CWP09g1xda4vsB9LaCEgc=; b=SpRVbLgCp4ETBEuN6cNLxQBJiRG5Mn7jr7YishikJPj2fvmYrjAnOfu8rU3Hkj+D6i 0IHBKw0mdmTdS4FCU0fnsC5AXbyRartWHHFIMLjLXrMtRhyOGmsKidimX1nByt3r4+S5 MKWeNAVUc4sl5YCSXKHnqkWOPYl6bzWuwTKwmkHHbnzRP/f9r6H+N4tTmI5LC1m3gXe1 cqo9dKM2Z5s0UfWD4VFiSD6wqZdhg0RVA1XRiaoBgi8YQdk9aZO0nbhH6OUuh2stFUjp ESKZAlfXDI3EK+/0pUs1F4ZLoSvGzHUe32P+iD3EQl6LkpRlpwJRSzHNs+bZeE1buAmT CQQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k9uBWhAimbshRgi1fv6bV7CWP09g1xda4vsB9LaCEgc=; b=QxwAS/ZMVeGho92MWTglA2xWUYo7/fgkiLDGLWyrJA3yjDA4SFecJsF62A5k6Av+Mr YcDxB5tfJOAmd/l1eZbBl1P5Wd6qoQh2vkjYQQPvE+MtcMRNVH8oubqHEppYev2E4GF9 3Md27346ShT9HBdS96vxIBfLeA19hD6FG7ID0zERHBXRO4ROTCD2cA9zUTP40A4aCujF Ezf/Es2Fu85pM/oKZ7491NUwAGOyiWmk+X+tmkj5aF5IycbCF0ktvNAJIBCqKIOdkXda y2MP6HHL3SehzSnJfv2fX6sq+20Qtgh8cwaeMFe9a1SNgmXhdpZkA34JYH9j6MF4PXS8 wf9w== X-Gm-Message-State: AOAM531fO4LQGt32zfdE11zVEYzEjCLGFXXHcA3VCwzrz2S595Q4w/pZ hFI6+IBVKynfz5jwySKWJlg= X-Google-Smtp-Source: ABdhPJxW6F375OUfvUioNHAF7JCsM+DLknkWGdK5hDeavjE8DBE+ROoZB+KFCyRtDTGrNBRoMhJNhg== X-Received: by 2002:a1c:8117:: with SMTP id c23mr10129681wmd.157.1594233155428; Wed, 08 Jul 2020 11:32:35 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id h84sm1015731wme.22.2020.07.08.11.32.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jul 2020 11:32:34 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN> <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN> <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN> <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN> <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN> <87k0zef3br.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <64585842-bd25-8610-153a-2143750e3ee8@HIDDEN> Date: Wed, 8 Jul 2020 21:32:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87k0zef3br.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 08.07.2020 18:12, João Távora wrote: > Please stop falsely claiming I "ignored" you review. This is distateful > and offensive. Not as offensive as having one's writing ignored. > I replied to both emails: neither were a code review like Eli's and Stefan's were, which were much easier to follow. Both Stefan and Eli were too busy to do an in-depth review. And I now know better than to do one for you either. > While the first email was already quite full of tension and off-hand remarks about my code being offensive and undemonstrated claims about code being bad in general, the second one was worse in that respect, There was a lot of different issues discussed in those emails. You ignoring most of them and retelling the contents now in this simplistic way is offensive (but about on par with your other messages in this discussion). I'm not going to describe the same things again and again, in many different ways. I have wasted enough time on this already. And if you didn't want reviews this long, you shouldn't have submitted a branch with multiple orthogonal features intermixed. You should have picked a proper solution to the issue #1, then filed a bug for the next one. Then we could have had much easier, targeted reviews.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 15:12:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 11:12:51 2020 Received: from localhost ([127.0.0.1]:38932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jtBkg-0006SZ-9J for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 11:12:51 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:55417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jtBke-0006SM-BM for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 11:12:48 -0400 Received: by mail-wm1-f48.google.com with SMTP id g75so3614377wme.5 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 08:12:48 -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=JSpg5unCxqWnXUsUvu2+Z0vifH96jB45jawovCQ5r1Y=; b=jorUetZr7pX2v3mmOOP2ds07WKBwHzRXYhnMdl3WABV24P0eRTeA2bWquQOoIInJj4 yef5FYTyNk8HUIHL6S8movXlf8EOoj+Kq3WfyullnqQeipAWE8igqBQ3JZh1JWhWswrX tADMzcBE1fH7xiuaX5QsJBoAOOg3MLzK8eJTRiVuEXOi6QzGoA0IkKam0piOZpx3rqv4 XTK3ElXvF6Mjn2SzjEqK2DpdsBEMGymt39rRKjpXmfjjCy4QEbqpC9V3ReBbEs/VHlFE IdMjrW8pMNda5o7Og7Q9eYtJrPX/GreLOO3vtDWZQvM/oJlUVtvfZgB+dU1R5ABUoXdO W4Mg== 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=JSpg5unCxqWnXUsUvu2+Z0vifH96jB45jawovCQ5r1Y=; b=R7S/bQ1vVrY4l7D8zprb3DEMsPbrZhengTUuzsfSxtRsPdkTIBTBOEiyyqhCZTw5HX sgFLVlr+aGN7Hltx1STaCdJRokZy9a00ZJqrIYDJiYITAlgGjMnVRAe4XWMeq5CRMDww Fk354Cvt0jVv03J0uUEUEkyuX+SRnFVSSpn4KkWj8SFDMhh+ZOiaNSjJRJVSVVigaNEP a/kj20agD13ywT4DL7Yf0ReqHa5wQRhyCzWLssU32MCrt5X5Fsii2zznpPXOeSKppNEs xBFg4SODWmsDt6L5LUeT5090T6yixLuH8WST96WBp7DpcpAIyuiIKcjGWWr7A5RymIQ/ aMxQ== X-Gm-Message-State: AOAM532UAq8m0d/7U9dAkGFWChuNCqjUXpfL3Lw3PqHEIAmvKeoxmSmL bYgGftckBUPUD9kQKOa0mDI= X-Google-Smtp-Source: ABdhPJzIOYsqPMNzud4qtqyPiROBxNUWRgD7nmQv3SlcLfh9m9rflABVY38jo/43M580ojqJuN6PWQ== X-Received: by 2002:a1c:7717:: with SMTP id t23mr9641530wmi.75.1594221162535; Wed, 08 Jul 2020 08:12:42 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id r28sm397388wrr.20.2020.07.08.08.12.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2020 08:12:41 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN> <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN> <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN> <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN> <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN> Date: Wed, 08 Jul 2020 16:12:40 +0100 In-Reply-To: <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN> (Dmitry Gutov's message of "Wed, 8 Jul 2020 17:21:57 +0300") Message-ID: <87k0zef3br.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 08.07.2020 16:25, Stefan Monnier wrote: >> - do a quick version of the code for yourself. >> - then compare that with Joao's version. >> - then do a mix of: >> - argue to change or remove some parts of his code (those that would >> make it difficult for you to install your code on top of his) >> - keep the other changes to apply them after he installs his > > Since he went ahead, ignored the review and pushed the changes, > apparently I can just do the same now. > > That just leaves the buggy new features which went in without proper > justification. Can I go ahead and remove them, then? I think you should M-x report-emacs-bug and explain the bug.=20 Please stop falsely claiming I "ignored" you review. This is distateful and offensive. I replied to both emails: neither were a code review like Eli's and Stefan's were, which were much easier to follow. For the first one I replied diligently to each point as I could, especially when direct mentions to code that weren't related to futures and when I could understand your question. While the first email was already quite full of tension and off-hand remarks about my code being offensive and undemonstrated claims about code being bad in general, the second one was worse in that respect, it was purely opinative and again conflated most issues with your penchant for an implementation based on futures, making it extremely hard to follow your point, as I already told you. Therefore, I suggest you describe the issues with M-x report-emacs-bug for bugs and for features that you don't understand the value of. Make a separate bug report for each problem. Again, I promise to reply to those. Here are suggestions for subject lines of those bug reports, as I gathered them from my reading of your emails: - No purpose in `eldoc-documentation-enthusiast` - `eldoc-documentation-compose` causes blinking - `eldoc-documentation-functions` should use futures library - `eldoc-print-current-symbol-info` is extremely complicated - This much simpler patch would solve all of Eldoc's asynchronous problems - Eldoc now eats my homework Etc, etc. Hopefully some progress can be made in those discussions. Thank you very much, Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 14:22:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 10:22:10 2020 Received: from localhost ([127.0.0.1]:38835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jtAxe-0005Ev-3O for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 10:22:10 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:36848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jtAxb-0005EW-He for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 10:22:08 -0400 Received: by mail-wr1-f50.google.com with SMTP id k6so49231299wrn.3 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 07:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Bp7JpwMNs5wuTE+MJSxTx6brSAGYlwp91Ryf2N+wyqY=; b=dHlVtWAYyZsAqB1BdMgIYtvD4fJTK4LJuMCFgXUpD2xyRphnmY3FrKc/UaSBOxoYYs bQkrQYVpdmsZl0KYyrpafLdDzHbSBz+UdJKAq3nDwy9ttMl4U17XRws1tbZIxzw3w/zO zAhdMF+qkvkBD5OfRuhWZx0/H5c7NSOTDwZ2wRXosn1P6utbbff7H5549SP68xd2zH9c SAK9PLVG6sGBeJqWb7pEbPOUK0m2rBRHOUttWzgs8fFv23q1J54hSpVewgt5hmCthU+y fEBUi084eShSgRqaGP4ZTicJ8SvVqOaSudGevTllnfTTvrQ9gX73MSerq8+DXmpgbo4m P3+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Bp7JpwMNs5wuTE+MJSxTx6brSAGYlwp91Ryf2N+wyqY=; b=H7fUhup8AOmEM00KdM7Y4xJiNoaEk5dxwc7fF0nfYcOR2JxIhpHk7+qfvqUjoAAsUK GCvtxYC055LxHskF71uvde/NGdZClupGmhEI/UZ3cwbefTt9QnIttyUZjVGCQHAtIiyp UKekFCWrFeYldDC3dNWUBW/6dE8xSO9mV2pLY1mxqAJ02K9/5MIEna6nixsw+gI9ja9W 6CzKp7wRFSNBMBspVLEdU50sX8fEV+cM7/Wx8KNCjfDpCqxm+HDKNKP0FnWj8NGi5f1L Xxn2rg432VrEoRH2a60eDvxGmX9skAsllHnoYqo6j+1RSVBFJ26xBnD9baxsPfODXybd EIGQ== X-Gm-Message-State: AOAM531pB2HMeuVAugBYeCljaHRlT7FcaJy+gIBEUDOWmTMH/UflwMMC +cR2cbfNy2MHz/lwvbUAoKc= X-Google-Smtp-Source: ABdhPJzORD9yoNrpSJbRKCEq5yqI7amhR01ohBlHpENK4Q2tvPD5x4/UKvULs5WxoawgTvYwDLTRdg== X-Received: by 2002:a05:6000:11cc:: with SMTP id i12mr57968344wrx.224.1594218120348; Wed, 08 Jul 2020 07:22:00 -0700 (PDT) Received: from [192.168.0.142] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id d132sm6454229wmd.35.2020.07.08.07.21.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jul 2020 07:21:59 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Stefan Monnier <monnier@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN> <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN> <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN> <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN> Date: Wed, 8 Jul 2020 17:21:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 08.07.2020 16:25, Stefan Monnier wrote: > - do a quick version of the code for yourself. > - then compare that with Joao's version. > - then do a mix of: > - argue to change or remove some parts of his code (those that would > make it difficult for you to install your code on top of his) > - keep the other changes to apply them after he installs his Since he went ahead, ignored the review and pushed the changes, apparently I can just do the same now. That just leaves the buggy new features which went in without proper justification. Can I go ahead and remove them, then?
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 13:41:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 09:41:56 2020 Received: from localhost ([127.0.0.1]:37685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jtAKh-0001pY-Us for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:41:56 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:39211) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jtAKe-0001pJ-0u for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:41:54 -0400 Received: by mail-wm1-f50.google.com with SMTP id w3so3190389wmi.4 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 06:41: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; bh=fHg9khiPVJolhLfM//rUXhKCwZGk6zFXXQS7wg4UUMI=; b=rHY8MNPBHkj0/1kv5PISl/xFkexDhZ7kmMxzjYAQSsNh5qzg9nj8f7r6OIAR/iEZ+3 0NfTnog9dKSDGnPs2EbobioQgaIg+JqmOAPvyN68rnUKDkbZHDiS9S3RJ7KNy+xWA+8g 5cWljYh8xuKzWBRD26hpeZhXnbebQCiFOCeomsmt4zvkfUCgAEmHUk3/KVsOXKoyCsKh E1Rw9j71lsB8Qu/zYKD3MHpT0NEUibqUZX85DgCDoc6FZw978USAOFNA+kO80YLzFPej CfjwfbO7fO0gmKEMNEYuq+NxxNnGI5ZaFfv0SUaqWR8QIoEXaWEzwsOVqKDqC74vTEvm 6hyA== 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; bh=fHg9khiPVJolhLfM//rUXhKCwZGk6zFXXQS7wg4UUMI=; b=I6vsSARqK+fpYfEKB8KJn7ZGg4O/Kd4TrSsyYe/kFqg+l2wEXZUa1uwDxcmAH+ZltS d+cb6eWCPF/S5i/p/+F/8C7cTUbdHuUJRpQrSS90DccglKvULy2P71Dt0kYd/MQYeFVz MZ2mqRSKkYIchA3FL3rpPE07cFoQM2WBjbkj6kUnO0gYaf7r5CcKTf1ToM1jkL3ZpeC/ hRfVwTW4PMps/aEHzL2uQQmjQ7ITlpOu/mKRb5LWJP2sqh7Is6OLHT4q6iSnxvtqPfmQ YuVd5gZKSkgVYdB5q0h0Lo6jXDe2CCnkNomDWKboR+grEUv+1CmrflbKZlwdLnUusGvj svTQ== X-Gm-Message-State: AOAM532mK7KXqMtcrKrLinfR4f71GFgJwo04OW6KN01V0SezR+UtyFQp tAH4qan4Ob32+MmZvuytfwQ= X-Google-Smtp-Source: ABdhPJzYtJ9IQK/7PaAMoOG2nnXSY3mAaAgVVgyji0pX1DXZuOA5ryIwisqF7AeqeOPC7AIKeW4ieg== X-Received: by 2002:a7b:c0c9:: with SMTP id s9mr8888933wmh.166.1594215706071; Wed, 08 Jul 2020 06:41:46 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id g3sm7090075wrb.59.2020.07.08.06.41.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2020 06:41:44 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN> <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN> <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN> <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN> Date: Wed, 08 Jul 2020 14:41:43 +0100 In-Reply-To: <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Wed, 08 Jul 2020 09:25:23 -0400") Message-ID: <87tuyif7jc.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: >>> I don't have the time or energy to work on eldoc myself, and apparently >>> neither do you, so the one who writes the code gets to take most of >>> the decisions. >> I have offered to do a rewrite multiple times now. > > Feel free to do so. But it does mean that one of you two will > be frustrated because your/his code won't be accepted. > > Maybe a better option, then is to: > > - do a quick version of the code for yourself. > - then compare that with Joao's version. > - then do a mix of: > - argue to change or remove some parts of his code (those that would > make it difficult for you to install your code on top of his) > - keep the other changes to apply them after he installs his > > WDYT? Fine with this plan. Would even dare to call it "development" ;-)
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 13:25:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 09:25:37 2020
Received: from localhost ([127.0.0.1]:37664 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jtA4v-0001PR-41
for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:25:37 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58025)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jtA4r-0001PC-NN
for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:25:36 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0701D4410DF;
Wed, 8 Jul 2020 09:25:28 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6F4784410D2;
Wed, 8 Jul 2020 09:25:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1594214726;
bh=e3p+BSWjcLbk2D1fwz9A3DnLAnl/r7G/oloClcHR5y8=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=BY+PzqtMbWdZLEznp08ImHgiBaqt0EcfPt7O1behb0HhYaT1tPA0UHbyHONOgpolt
UkhR9KQFgbMB8AvMDq1iCyDRXovi59PfgPY1/5GqmMj4NGqzNaVhpl82cKdUuPbxb+
hkq7l2CFlrQlnMZUsCqwchcGtKpE5E7//vwKeuIddI3LjmA6+JHwIETlX/UM4ZgiMo
e44Zvc4fZpvpmZVSNkXlUch8RrtoDc59CQUUnGvt8gGLWsfydPfpVusXfyEX/5NX9T
rqLeF06D5wzcWT6GYPZSXb/6ur3Z03Dx8TX1nEy68KCXeNxsxQbTu9NyPpbWdjW2F9
G6kMVePEUAVJA==
Received: from alfajor (unknown [157.52.0.200])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D312F120820;
Wed, 8 Jul 2020 09:25:25 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
<87tuynsdp6.fsf@HIDDEN>
<5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
<87h7umop62.fsf@HIDDEN>
<671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
<877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
<3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
<jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
<5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
<jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
<7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN>
Date: Wed, 08 Jul 2020 09:25:23 -0400
In-Reply-To: <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN> (Dmitry Gutov's
message of "Wed, 8 Jul 2020 14:20:47 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.037 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> I don't have the time or energy to work on eldoc myself, and apparently
>> neither do you, so the one who writes the code gets to take most of
>> the decisions.
> I have offered to do a rewrite multiple times now.
Feel free to do so. But it does mean that one of you two will
be frustrated because your/his code won't be accepted.
Maybe a better option, then is to:
- do a quick version of the code for yourself.
- then compare that with Joao's version.
- then do a mix of:
- argue to change or remove some parts of his code (those that would
make it difficult for you to install your code on top of his)
- keep the other changes to apply them after he installs his
WDYT?
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 11:20:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 07:20:57 2020 Received: from localhost ([127.0.0.1]:37564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jt88H-0004lq-ND for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 07:20:57 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:39366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jt88F-0004lb-Qw for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 07:20:57 -0400 Received: by mail-wm1-f52.google.com with SMTP id w3so2544807wmi.4 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 04:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MdiIqwiFU+5+Y+Gx5O1l9usofkeMTwuX2UfN0Ry8IYU=; b=kt8XnajXRWQVngeNwLHgo1bLsKRL+PHHEB0ESuKZsTSVaxp3QPvTGbGyqVF5y6FVVT 7L3eTP2I5PSTYg3BrCvj4JUjYrWPF9z56DS9gaMe4wOHFP8EqcJiJPy7ODdVVs6AUmvP IrfLklodRPsvWIimmUj6mfwkeeu6MVEYbweDx73rKQ9u7rLUP0k2yGOcesdbH8o5cvSQ oSkrXUH2mqBD7gOWH+OM1Yn3vL0Vpwsm103QHSg38eoEwedSFFF7aDtbLfaE0di1t8C1 tl1fWHdPTT0j8tiH7f31f4IRO+IL70Fy4tW4wxw9WHTzPexkwVsd3y7JTZm2sYZ3qlkb C4fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MdiIqwiFU+5+Y+Gx5O1l9usofkeMTwuX2UfN0Ry8IYU=; b=d5UCfQmbIZ75Z4eCuAH6m2jWy7XX2pdZvm7silB8CaiKjENZpEDICFeskPfcNAU6P2 aR/BVyXDkOISH6XFuAgfVopkYd0gr4DnOZEQ2Ed7/NFu3c+TOyjoWgOXfDeAHDDyHJrA w/ozZ25t4KUHlm1Fk8UWzHBuuzrNkox26pqrsBVmu4nZdkTI2GjZOT532C2Kq6AXL7lx 6KYr/R3+MUwyBofofe7VR1VJyUxem0SFYAaRUtPsLSDMaGKOWg1iQnERtlbO13GVgG0N 2tGQ5G62iH52/lwEV1Ty+RSL1oHzMf0WOPxuS3jyUweABWYIltf0595ztY4kwfg6vPFS 92Zg== X-Gm-Message-State: AOAM5312qBivy7MTeotxef26GyoN9u+8mSD3QY+EbRdy3NnjmL01Va1y hP9AIMWUOyR48Ofa3tpNff0= X-Google-Smtp-Source: ABdhPJydYu0RkB2KDPCuRvwBbhAzxZW5oo9E9ktrl91tXJ5zhLqrKqhTlFQZKEd6h0XC6/ZhoQcyRQ== X-Received: by 2002:a1c:2402:: with SMTP id k2mr8838040wmk.138.1594207249859; Wed, 08 Jul 2020 04:20:49 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id u2sm5246753wml.16.2020.07.08.04.20.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jul 2020 04:20:48 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Stefan Monnier <monnier@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN> <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN> Date: Wed, 8 Jul 2020 14:20:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 08.07.2020 06:58, Stefan Monnier wrote: > I don't have the time or energy to work on eldoc myself, and apparently > neither do you, so the one who writes the code gets to take most of > the decisions. I have offered to do a rewrite multiple times now. The only encouragement in that direction I have received was "can't stop you". > From what I remember the last time I looked at the branch, there were > things I didn't much like, but not more so than in the rest of Emacs;-) I thought we were more into detailed reviews and good code.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 03:58:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 23:58:21 2020
Received: from localhost ([127.0.0.1]:37197 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jt1Dx-0001wI-MY
for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 23:58:21 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58279)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jt1Dv-0001w2-66
for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 23:58:20 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 88C4780A1F;
Tue, 7 Jul 2020 23:58:13 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C25E780B63;
Tue, 7 Jul 2020 23:58:11 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1594180691;
bh=Yx48gz2JAMFILb/JwiWMSIz+X7NTx+l+AMGxsgJwwKA=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=RcE5xMAlQgribr9eP1vz4DrbIinCHci7f8zpZLngTsgnvISzvr50Lead/1f5lqHPK
02d9pWic+LqJ/DnJ1bPQiEDeB17ctxFo7PLjqdpVX3sQZb5S4YvaWlpuUs5VS1fhzn
GLELU0Np8euZTbL7QcFzFmWuCpDYVzAAceeyZnEsly+ZKxBS19te8DNmeqPHsgZjBb
/u0WIH0E6kfZK+wxBmuZJyYdwxBrCxeMPEDkgz+di2tR3ASIDa1jrk1JjhNliez9yW
o004KuwD3r7+M1EvpEH49ngieB92FldEegENcjH2kdOLUJjHw9bo7zvvjKO+BlTj+L
AuURnFWsbALUQ==
Received: from ceviche (unknown [157.52.0.200])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7674C1207A5;
Tue, 7 Jul 2020 23:58:11 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
<87tuynsdp6.fsf@HIDDEN>
<5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
<87h7umop62.fsf@HIDDEN>
<671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
<877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
<3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
<jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
<5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
Date: Tue, 07 Jul 2020 23:58:03 -0400
In-Reply-To: <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> (Dmitry Gutov's
message of "Wed, 8 Jul 2020 02:11:11 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.022 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Why you don't consider the alternative with less invasive changes, is beyond
> my understanding.
[ It's the same old maintainer's conundrum, trying to balance the need
to stay in control of the code and make sure it's coherent etc.. while
at the same time delegating and encouraging participation. ]
To a large extent, I tend to give a lot of weight to existing code.
I don't have the time or energy to work on eldoc myself, and apparently
neither do you, so the one who writes the code gets to take most of
the decisions.
From what I remember the last time I looked at the branch, there were
things I didn't much like, but not more so than in the rest of Emacs ;-)
I can't ask everyone to code what I would write (and it's often for the
better since what I'd write would likely not work because I'm not aware
of the underlying difficulties that would make it fail).
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 00:10:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 20:10:17 2020 Received: from localhost ([127.0.0.1]:37040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsxfF-0004tS-8j for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 20:10:17 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:56004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsxfD-0004tE-Qa for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 20:10:16 -0400 Received: by mail-wm1-f45.google.com with SMTP id g75so1101690wme.5 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 17:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+pr4S5vrAizyiKvX9CMB1ttGnrOWeW6Fx4dEPqxTz98=; b=Pe2D01jkI7z52EzUV36zA2OmimUijzp+0xwSYSFBpwi+jHCXcB2A/7k+1ctOSdJ4ep jrgYTXvX+84GXAjSryRYG8Y4dIm1terqfyiOd4r6u4RlkrulTCWCItekw24i/luv2Htr snMVzYW1zETQnPKnPdD3dL9xfkDTyZfNx6v8f8ZazxwupDgLI9Q3FCo3daA7vGdWxQbz oh218LbuD7Vw7gPqK0wtwUcD5Y4oMD4pB+5rs56MJ7jPUj2pwxcHgqmx4kSA3+hWwqh5 /bdI4952ZXMWj/rKAAPD62LJK88XnxL2o+JryTPC2p6l2Kv1KsSoygyai3Q0S5LiYG04 4kvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+pr4S5vrAizyiKvX9CMB1ttGnrOWeW6Fx4dEPqxTz98=; b=X7OtByIKG8rN2K3Emtc6Amu1t/d4v+tz6TYs4RkjMYmk/Rh03Imq75LrIReqvK+1TX HZsT1eZfBey30II/i7Xdgq9EMNNZhKngt00n3nOG1qGU6cJ4xdc7WkC/grdbFQ4NBEnT T8WD6llSEkrQ2veW/6vlMEVYinpZq/b10AnftjR8LTfd0nAH3/Kfj9DNY+f+azEqGO58 M3upSJ2n91xefqB2C/9vJFVtGfluGkvSpRWOCwrEX9GyuOv8GW48SnBqnsk+7KVV5nlZ shZk9B5wKXAwm11XMtzGb0JO8NcCwycMJ62sXbJ6TSPUV61sXGLDltW4x2LBk/5ZThCi FmPg== X-Gm-Message-State: AOAM530+bRds1oQM3/FgLnLNKLrYXYXmNJ/U2sdTwQSIP4lAowszsl0x pwDu/X3zJU8BczC8AhxENNQ= X-Google-Smtp-Source: ABdhPJxF1Vnvsacdvg1cdn4KPjCVUttYqr0fU+ZbWSuUthmc+p68yeqrr680kLlUkNdppXC5oPRPJQ== X-Received: by 2002:a1c:bb43:: with SMTP id l64mr6716385wmf.151.1594167010054; Tue, 07 Jul 2020 17:10:10 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id x7sm3035950wrr.72.2020.07.07.17.10.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 17:10:09 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN> <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> <87y2nugb78.fsf@HIDDEN> <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN> <CALDnm508OCN7S9iLaw9k-91gtsW9nN4yo+vJWYzEf4ACoAJSiQ@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <550c7a18-e60b-e490-f39d-97d5a2b386a6@HIDDEN> Date: Wed, 8 Jul 2020 03:10:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <CALDnm508OCN7S9iLaw9k-91gtsW9nN4yo+vJWYzEf4ACoAJSiQ@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 08.07.2020 02:46, João Távora wrote: > You're confused, but by all means code away, you don't need my > permission for that. Good luck! So I spend a few hours coding, and you wave the result away just as promptly as you did with the code review? Or with my previous patch? I asked what you actually need here in terms of functionality to go on with your work on Eglot. No response came to that either.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:47:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 19:47:13 2020 Received: from localhost ([127.0.0.1]:37014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsxIv-0004Kd-Dh for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:47:13 -0400 Received: from mail-il1-f194.google.com ([209.85.166.194]:44667) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jsxIp-0004KK-Gm for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:47:12 -0400 Received: by mail-il1-f194.google.com with SMTP id h16so14224114ilj.11 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OWttQUTY9e7uQ0Xwk4FaUmcwDGUdkSZZxM0rfr09uYA=; b=olaKvag9QZxp9mU4plC9pvUV2+Yya4E42KxdEUJal+X1PqZfDy6JN3n8ESyqMEoRXP VEPYh+IRsT6r51xr08TFtnECGjzxJTm6mXkaYSnpAM5zMtGIKqSM12SsCMEoFC5gN1TX G27KRVfzdg5lkVIjmT/iNzRMmvuY4n2wE9rKgib7sybzqsYPYuTndMCFTawnwc4Cs++p I3lSFwE2EJmxy3TKcidgizYkZ8fdTe20a46PXjeRKzOzrmb7ER+2LUbKvmsmeXFLqsEU I86yqEvshPFdOJki1FkwMIsTena5i30xoYYcntKp3vO5hqbK9RiuuK4JxFlAPVaTp6t2 cLIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OWttQUTY9e7uQ0Xwk4FaUmcwDGUdkSZZxM0rfr09uYA=; b=dpCdSIaB1k+NbQX+WVwxfqq4exrLX5oYJVJNGZ/pakuootLBWy5KmL1XAU82ONoOmH 9S/uQQmpYSEg59r4g8TiPEAfq2B4RgmeD1bbPw9lOGPgeTDAyaqOWtLio/vLcdjSx5Hq MmjoA2qPznDGyWHztcOi3cM6wF+asjwzbu/6dtBNAoUnGycxk7FZpbr0dkuZei+p1doE 1HVh6TnzgXj16/8VdNJkNHAEzqzOG0nFbkgY5BMDk1b3swTI9HUo1rQOQH7eGCguhUMG Mdj0GWLhJMj++zd0zBzjMXXMgxEBRKLPmEMkrMsOviZwwQ+GwOyU0L6MzYekX58JJILA x13A== X-Gm-Message-State: AOAM53002jk1Io8TVoOJnTOJKF3y//p8vTAnKAoGPKRE9wK5SzYn2DMB 7a0bat4EMbCjwv2o0ZtTKv5edWeC7yio4uNK6jc= X-Google-Smtp-Source: ABdhPJzpnAEIH7mqvzmPMsNGl3/Mp6SGND8VQQFV1N8nAX744GcyTzk46qqUI/Gik+uh5rf8lRvN2sekPlcD2rcXQ6M= X-Received: by 2002:a05:6e02:13e2:: with SMTP id w2mr39678235ilj.9.1594165621868; Tue, 07 Jul 2020 16:47:01 -0700 (PDT) MIME-Version: 1.0 References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN> <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> <87y2nugb78.fsf@HIDDEN> <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN> In-Reply-To: <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Wed, 8 Jul 2020 00:46:49 +0100 Message-ID: <CALDnm508OCN7S9iLaw9k-91gtsW9nN4yo+vJWYzEf4ACoAJSiQ@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Wed, Jul 8, 2020 at 12:42 AM Dmitry Gutov <dgutov@HIDDEN> wrote: > One message, you > accuse me of not implementing everything myself. In the next one, after > I offer to do just that, you cut the discussion short You're confused, but by all means code away, you don't need my permission for that. Good luck! Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:42:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 19:42:35 2020 Received: from localhost ([127.0.0.1]:37010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsxEQ-0004DG-Rs for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:42:35 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:33173) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsxEN-0004Cw-H8 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:42:33 -0400 Received: by mail-wm1-f51.google.com with SMTP id a6so2731517wmm.0 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4D+jEGzN95BDJjc2YjQZP9qQmzC/H2EE9zxgquyjqok=; b=T6MRB4nLIYFQyTJKmmF7/QwR/lWn1wykRi7T9rn/q7ZWSPbvikOxlZhrkpt4SEHmHz BJbKFCsX4XJ2EgBGg6A0arnuap4k7+J6+LBqff4WJ0gHwJphoKoWEMakF3cQpy7h8ukG jMFkG6N0HA/+v9nn59mtCf8zP/QQ3z/wW13y/zlWr+/cZJ7wfq9AyQ55+ACLIDuha9Wg faZuL0FwJJo8DoAuwWW/h6YszRJlxl4EmcT3wzZnNhU0WWG3kjIxAXzPUrASOVgpY0HR zlmo33mkvQ/zqZdpxhSmPbRzIfTulnoaiPDcYoQyj930Za7Lfuy2SIroX6cmpzn5eDsS E7nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4D+jEGzN95BDJjc2YjQZP9qQmzC/H2EE9zxgquyjqok=; b=J5UE2zNgIv+cgIsGRHXOIf5FAgymrt0muijUl4LKQvE0s7I9/diUj6uEVbkkQVdfc+ ecx7DfeS7DLsQvVXQ+zt/pDr3/zP7xJlbFeIiThs0q+To6Jn3cShdNR4CWNe3sXvzFRz 39HbMIrNNT/QLRnfV6K1Qnns1fcrQMHDRxWNZheCsHl7Sc1of+r1J5ZMJ1t72u7cPm8T szjO4TvCdovyRTZh1kT/PjlG3MKTEd4Xp1FY7LN3oJdBWUOb4myADjRlJDy0up8ebn2P hxJH8SAHsy0/1gV1ZivLTCTjojf2neaHG0fmnFWIoQu+Z+8xmU1TcWO1bAu/l8gtl+jS oTFA== X-Gm-Message-State: AOAM531UAtMsPoUQByHoi2xaJsLkFltw7ivQCpS6LDRN1VBmoPSxBUBA kqA+cNNsSopckqlR4JtFxFg= X-Google-Smtp-Source: ABdhPJxUxl1E83CpAhQN90UE0g1tu4RT5EzT3IEGU4HEhcVcUCTcoPwNAXWt3YkGASooC3VXDkNxjA== X-Received: by 2002:a1c:bc8a:: with SMTP id m132mr6139843wmf.1.1594165345348; Tue, 07 Jul 2020 16:42:25 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id w14sm2951234wrt.55.2020.07.07.16.42.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 16:42:24 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN> <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> <87y2nugb78.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN> Date: Wed, 8 Jul 2020 02:42:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87y2nugb78.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 08.07.2020 02:24, João Távora wrote: > I read your email, but it's very hard to follow your verbal conjectures > that this here or that there will fail catastrophically. No such conjectures there. > I suggest you make a bug report for each bug, describe a recipe for > reproducing the bug. Likewise, if there are shortcomings in the design, > state clearly what you wanted do, but can't. I promise to attend to > them, time permitting. How about you reply to the email I already wrote and ask questions where something is hard to understand? > It's important to disconnect these reports from your fondness for > futures, which is a technique for which we don't have a library or > consensus for. You're ducking away from your previous statements. One message, you accuse me of not implementing everything myself. In the next one, after I offer to do just that, you cut the discussion short and accuse me of fearmongering or something. > Also, I agree with Stefan that things have become tense and agressive, > and no good progress can be made in these conditions. Let's tone it down, then.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:25:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 19:25:12 2020 Received: from localhost ([127.0.0.1]:37000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jswxc-0003mR-1L for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:25:12 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:38179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jswxX-0003m0-71 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:25:11 -0400 Received: by mail-wm1-f43.google.com with SMTP id f18so1043062wml.3 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:25:07 -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=hHLxnx8nyngEprDMbgUhDpwfukaPRT64QSt2P1M2iK8=; b=ttKPcjfqbU2GIdSSTXMLN86UsT6o4yhynfYN4XgJNTlKCKKATPMmE/mxSnAjET1knR eXqHzGDYIRCbY9b/3b6D8c/unx99widyRjiTyOqGrk4lsw59T+2i27L9hax8Q+rmOzpQ tmMbSKb/LkVBH6Ne5QHo73QzVFIaBWGW5rs+AjvApTqMXcV17J+Qbtm47wd/zPtvqsE3 FBdIT3H7b9jbcaYvMCSDgk8dCrF3+OoyXa68JGbXi9OU7Kd5WsqOxmqyNfB6ut+e17rs D3uUBMaFxqoP5ratg8SmJ6GRhJlCmXs4wPRZ4ROGbOR8Ko2UKSCyCTj2IvJ9BA7qAjmM +6PQ== 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=hHLxnx8nyngEprDMbgUhDpwfukaPRT64QSt2P1M2iK8=; b=I8wkVI+SlX+a66vnGKTlNhrCWb5amErhuolZR9Spnlb/t6GiAGuKGaTEOxU4ggDJ7V p/+iJnyuWvvxUYdT/BieDJdhVJYw4ywRorguqSBjFAN6L6DcOIUv73W7hxwlV7GYhxnd 6azVP3AvOqIwYnuLjrY1NhslPZYAgKT1Wc5E1g+nnGFfY7DdHWPiZ33j5lekc74jXVO0 EzpGt0Y6qBQ1y9EZoUZGhwfr7TKZZOAnzd84+oleRqci7W5RAw3d2tx9D99ugItw3Qir iTWR6KMHr7JSJLwbsfizNnrAAf8gxE1tlfbdc10bTFe9dw11eUAcMRjpksnNpg4ueveD L9Pg== X-Gm-Message-State: AOAM531bOTUpDv5Iv+QnjrLPWePHUhxJSiyckGKP/SgvWc6mGq55VA3A 8FVxRix6YhBpcb5vEH0FcJQ= X-Google-Smtp-Source: ABdhPJw3hlG+0sGLSq0N8dNiLmartdme4M4xwSQo7zG9tbgZAV9f5jhKh/0qWBrDYyeeLYPpPYUNQQ== X-Received: by 2002:a7b:cd09:: with SMTP id f9mr6674049wmj.160.1594164301309; Tue, 07 Jul 2020 16:25:01 -0700 (PDT) Received: from krug ([89.180.149.197]) by smtp.gmail.com with ESMTPSA id z63sm3168830wmb.2.2020.07.07.16.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 16:25:00 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN> <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> Date: Wed, 08 Jul 2020 00:24:59 +0100 In-Reply-To: <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> (Dmitry Gutov's message of "Wed, 8 Jul 2020 02:00:08 +0300") Message-ID: <87y2nugb78.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 08.07.2020 01:49, Jo=C3=A3o T=C3=A1vora wrote: >> The rest of your long email hints that you've misunderstood what this >> change to Eldoc is accomplishing. > > So basically you even refuse to discuss the design choices in the > branch, or the shortcomings of the implementation, its current bugs, > etc? I read your email, but it's very hard to follow your verbal conjectures that this here or that there will fail catastrophically. I suggest you make a bug report for each bug, describe a recipe for reproducing the bug. Likewise, if there are shortcomings in the design, state clearly what you wanted do, but can't. I promise to attend to them, time permitting. It's important to disconnect these reports from your fondness for futures, which is a technique for which we don't have a library or consensus for. That in particular makes your otherwise extremely valuable feedback very hard to follow. Let's take Stefan's advice on the futures front, is my recommendation. Also, I agree with Stefan that things have become tense and agressive, and no good progress can be made in these conditions. Best, Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:11:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 19:11:20 2020 Received: from localhost ([127.0.0.1]:36988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jswkC-0003PV-Kb for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:11:20 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:53856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jswkA-0003PG-VR for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:11:19 -0400 Received: by mail-wm1-f52.google.com with SMTP id j18so986923wmi.3 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nVZ2kI+DAIGADUfmh08z8jHQMsnedOR1vrSwW7Ki33E=; b=uObmKMh6d7oPC1xfFBLhT0ZR9Kvl62LwLEcFZWq0V9N9isJc85ZiGV5Ya0stQX6BX7 51JUA/IWcGolmGAI8JCHjcgVHPc1r/snW7jQZjakS9Msb3CR1PhJmc7R53qLeyTLtvmA mm/lK1x1+ET/q5jpcB54C1QHYCIbAVabnUqARwi6xKzDmRM/jzvDbbQKk3E8oRzHeBU9 lXLdtUc6IizJCf6UFD1NeC8OefTli7n4r9K8JFj1yP/EcQYY+oX17ZDLhkJSyEi0gTwx O5m8cWGg6qm8/G0Jp88BElitL33UcI30naw5BBvc71g7V/prIhrhA8P7wkVRrwSC/aEv 1H2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nVZ2kI+DAIGADUfmh08z8jHQMsnedOR1vrSwW7Ki33E=; b=q/RCB7khME6muuB+qwKzTS5D1fKad2wh5phUpNAXYs5ZKpEuNHNZwHAhYmXlUDxiwy LgvgtJHS5josJZjWLv7g0XJTEw9etPervXMBm8T0ntWmHftymF/VpYIcTb2hRaYNK2Lg Khu+pcyj0ieXGbIf89P4ARocXrFI+4VmynqD5izfCOSmhqx28HD6mdwZk/XtqmkV5VDS ic73ju/gp56utHew3AbhtWFb8LYOMmSXDi2Hgqu8BRGSnrgGzHx1x9Rddl7kVpNu3/NY K8/4VSWmQFaJRHuBWixAt3dwb3O0+FFPWYa9tgCz/2Zh1oB+qlijDHx8FZonnVNDWoOE DpPg== X-Gm-Message-State: AOAM533a4NGXKRj8SqwGhOTbyCoqZgxL+LxhwPCTW7TiuBVntt++o90M BM28rCWHSFBeIXhXJuQw9Fs= X-Google-Smtp-Source: ABdhPJz5517bNzpPLWyMX86nNJT9ACUV+nXxlEAZXJN/zRGn+YKrYTjZdsOGjxqomYmu4ugUvxgAQw== X-Received: by 2002:a7b:c013:: with SMTP id c19mr6223505wmb.158.1594163473089; Tue, 07 Jul 2020 16:11:13 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id c136sm3185519wmd.10.2020.07.07.16.11.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 16:11:12 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Stefan Monnier <monnier@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> Date: Wed, 8 Jul 2020 02:11:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 07.07.2020 19:07, Stefan Monnier wrote: >> But I fear we wouldn't be able to roll back the related decisions >> so easily, however. > I don't see any reason to fear that. The more time we spend discussing > what the ideal should look like, the less time we have to actually > get there. Given we can't even agree on the acceptance criteria, how would the rollback process look? Another "let's get it merged, folks"? With nobody particular in charge of Eldoc except maybe for Joao now? Who will of course be ecstatic to change the API to one he explicitly disliked in the beginning. > The current eldoc-async branch doesn't get us further from the ideal, > I believe, unless `emacs-28` gets cut before we get our act together. > > But if we don't get our act together before `emacs-28` then the > alternative is to have Emacs-28 without support for async eldoc, which > I think is even worse. Why you don't consider the alternative with less invasive changes, is beyond my understanding. > I recommend we try and be pragmatic. Especially since it will make us > all happier (instead of arguing against each other, we get to work on > improving the code). I wouldn't call the definition of eldoc-print-current-symbol-info in this branch an improvement over anything.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:00:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 19:00:20 2020 Received: from localhost ([127.0.0.1]:36966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jswZX-00038v-V0 for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:00:20 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:35840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jswZU-00038e-QC for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:00:19 -0400 Received: by mail-wm1-f54.google.com with SMTP id 17so994516wmo.1 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vuHTpTZv9hS0z3MygeBbh9a8L6dbkoGa1B6Q4z1u1Ps=; b=TnmXCi1IjT8e23d7O/q683AAahnwpfgOTn2ntlkHTEhsMK3uvCMcavtUT2uqamL7Bh 3SsNRfBnQzTjti5ZBtBphxIaFEE/i5WCoDSbr/iDTqsI5/DBWQwCUTcBeIKqRuPwLvxd M2O5bG7wmGWlSUYOFUbK06qmdglUljqMGGkHCZlpXLngJ4y1J+AOQB8cW6Q6c3vp4evR c2VDeRZ9mmlDH+w2ydmcha6iD4sWEqhbDS9k0y4ulusEW4q8VfDDqI5v2YzvYaVcaXBU iB9HBOhf5+11Au4aY+zvdq2YQPPg2Co8vKOB+RhemHjOy8igPT1qg4KCCRA62owdEOYL suhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vuHTpTZv9hS0z3MygeBbh9a8L6dbkoGa1B6Q4z1u1Ps=; b=Xiu+79LT9Fuly71CpWzHnLrY5V7ngAE/BvHPetvBld2iEOootDr4SeyBJL3mx8HW6Q ZRgPDPlkZ93N1gT99VFettcVPKbRp7RxZS5TAWHYODI2bzT+ZCjiEnKr9E7V6XFMkbqR gfB71FXahN9+/jhxZi3VadiaoRO/YatrbsoFkIbLAuKZzi9v3vv4THDZZdQaMcI9AZvZ XJJEhRNMGBBPJ1m+E6MY6nk2JPL7Knk8xlQWGtl4eXcFJtWDCd087qTChq6Bq5GNwk0i iQMYFAU9pH7rFbMiplSFgYUtPsJE90v6kTYnzb5ul1MeYCnt5D/O8Q/mer3f+v/G54m3 Xe2g== X-Gm-Message-State: AOAM531dIAkclArpIsIEx+TBDJM68Mr8P42LDQejySTKeCcvWU8RmL2D sQJBG2T1PpylKLgAWA9x46I= X-Google-Smtp-Source: ABdhPJy8KUm6VBsS/vPaNpQPJIa55dvW2Yi2/VjgLL33Wij4gxLzNNmzhbroIgWfpEgHuJID6m78ZA== X-Received: by 2002:a05:600c:410f:: with SMTP id j15mr6153275wmi.128.1594162810683; Tue, 07 Jul 2020 16:00:10 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id v5sm2930639wmh.12.2020.07.07.16.00.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 16:00:09 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> Date: Wed, 8 Jul 2020 02:00:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <875zazgcug.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 08.07.2020 01:49, João Távora wrote: > The rest of your long email hints that you've misunderstood what this > change to Eldoc is accomplishing. So basically you even refuse to discuss the design choices in the branch, or the shortcomings of the implementation, its current bugs, etc? And just merge the branch wholesale? Thanks, Stefan! > I might even work a bit on futures myself. Knock yourself out.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 22:49:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 18:49:39 2020 Received: from localhost ([127.0.0.1]:36953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jswPC-0002sE-St for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:49:39 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:37236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jswPB-0002s1-1m for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:49:37 -0400 Received: by mail-wr1-f47.google.com with SMTP id a6so46988540wrm.4 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 15:49:36 -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=MHGJG17utx7ENa/DrQszChvQOsKf0cvqnQcl8WxZYEo=; b=EVRMO2oqgQdpJXRM725KPOOlar5np01tzv5+2651ZcWaDO20UUX6w4XXWwBGCGvsUW 8w7p5ExrNCfL0jKvRu8dDuNvrf8rKwSrjmt3cTCsdBrZDcU++IUxhXqb7CYJgNxHe00Y Tk/sZ7S2++8IMDYp3wF5rM2/GF9hxIVvT+7ApNReodgDFdY2PJ//5qJGmMggKUAurJWz +gyo6thoz/RHiR1Y1B9JwZtglpDChiSnvjFD76jzSKt0YbrrBwpzDWIBBmjTUPXOkJLE t7L55IM/hqBsVWb0qAo9KKUrbkq5QXd8Zn2xM84/oaFj0k3Ka3v0Z/Z3Pf37JP8fNvOx C5pg== 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=MHGJG17utx7ENa/DrQszChvQOsKf0cvqnQcl8WxZYEo=; b=ZbO/gCWb7FfLli5p0O/ehwnzuqhxKvD4xyFKY1jaQNXjDSJ6YsIj7SZ0u5BK0qIAPk H7jbzF12IyDemWDGAEQ7TuKnWe2E772J+qG+prrBWHIUbe+6JNechLZcntR9GRppNRfF V4YzCgMVzywliqdZ4iC2m+PZxo3WqwE0sPBkzC8KfOCH0ozYmfhQO8lcaCaOscjlhczn Dl4AbYcEvFI9TIvJsJ+uCjoTBKwqcuyz3yMi/dEPpiV9NDmgKtGo+PS5OoVo/ZpwHh88 jZQrdbWr5Ba5RrqcJtMU/9scHQ+4hQbAayr0u3bkC68vNVVtsdlAsa78ykjRqGeNT8Wn HPEw== X-Gm-Message-State: AOAM5324AUtOqJET1O/+BGaA0jnqodk1wDHDn8zRzce2JWCP1OUfYZ+z pHZVnYwty9zuJJON5fnffA0= X-Google-Smtp-Source: ABdhPJw/jAUSTrdP2aizTbi+Qt2jWXi2TIqKb8MS9oItlq341tlD0K/GsGr26CFWuw+hsIMVaRaVFA== X-Received: by 2002:adf:b198:: with SMTP id q24mr25442221wra.335.1594162171003; Tue, 07 Jul 2020 15:49:31 -0700 (PDT) Received: from krug ([89.180.149.197]) by smtp.gmail.com with ESMTPSA id u186sm2937340wmu.10.2020.07.07.15.49.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 15:49:29 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> Date: Tue, 07 Jul 2020 23:49:27 +0100 In-Reply-To: <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> (Dmitry Gutov's message of "Wed, 8 Jul 2020 01:24:27 +0300") Message-ID: <875zazgcug.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: >> But if we really, really wanted to, it's easy to get rid of the >> arguments, too, with a variation to the callback technique. I just >> don't think it's worth it: a technique is a technique. > > The variation that I showed in my little patch a month ago? No, to be clear that was not a variation to the callback technique. One way is simply to passing the callback as a special variable (and there are more ways.) The rest of your long email hints that you've misunderstood what this change to Eldoc is accomplishing. I'm afraid I've done all I can to explain it, including docstrings, NEWS entries, commit messages and going through your previous very long code review. I understand you expected a futures library would come with this change, but it does not, not for now. I've explained that is only a technique, but in this last email you conflate every issue with it again. My position is: if there really is value in them, futures will soon be in Emacs. Let's follow Stefan advice, it's good advice. I might even work a bit on futures myself. Best, Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 22:25:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 18:25:09 2020 Received: from localhost ([127.0.0.1]:36904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsw1U-0002FB-Vh for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:25:09 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:34881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsw1T-0002Ea-58 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:25:08 -0400 Received: by mail-wm1-f45.google.com with SMTP id l2so908542wmf.0 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 15:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xvuyXoxcxuYAP+xmqs8M8iOHyb7g27NxZrpR1MIm6Fo=; b=oeT3OhCaaEgPBYt/KqpKLXKYjB6+0buHCHPxM53MRZUZ9CnBsGJKo2HR9PAQKg6n8P CyHDptVcHrwxVPtPkjf4Wj13Nu+8T8ilbuTwc2gvkr5BgtcrjoAuWmJuq1tw030DkUHZ 2wOgRGlTSt/ckRWEmXzlwH5gvSHZdM/PO+tr6ZyW35TMa3pcTMn+bnc/un0FvW7ortOX H/pGsPHONjCOlfC7iGbjwHGuDqy2tt1Lm5vXCMFPqgm5mhKTUOGiUC1svCovLns6D++P wyKu2PtCU8mFeJZt2xD64aEfCkQSVotunbwjySsF/gU2A4uHBm/E5PV+Jrte9x+iOclq xDrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xvuyXoxcxuYAP+xmqs8M8iOHyb7g27NxZrpR1MIm6Fo=; b=ngvmu9OXSr352RPiUzCDg4lwxpfMmveCr4DwBE8dR/o7bMisscmbzTzzQyYt8j5OT1 /AO9E5AiC2FFF5G5OALikyg2HhJTwY9syxiLIebz/qoSBuu3Rt+uzxGj6NRui6mtBfEA ocbX2M7kUmi6vkAx9ggy7pdXie4rD0VOFsR1Z3vox3esndZjxWCFObJ8/09h8TwaSmmC OwtqtZ7nyx9HcacK3c6MyyVPrd8PyB/jesbQ5ZyF0ZYycghH0L7kY1LUvUNn7a0JPVo1 Qcg80yzi1uBmOMC2B92JS57apKl1wX3Q7X3BOIC28Wctx5R6fbs/romBuYKzc355NRGl vQUQ== X-Gm-Message-State: AOAM530dB9n7Hv83orlrpQ9O7RGTHDRrtN430gBKwHS0OoCIbXEWA0ur oJe5OQGbtc56WAD7ucKuyZg= X-Google-Smtp-Source: ABdhPJyHOiT5OZCxp0FjzLTdoAO7MpG77NY7KaN8zr7lzQskyRRRhqOhpJl/UWeKPHAOYuY0md/ueQ== X-Received: by 2002:a7b:c4d6:: with SMTP id g22mr6478941wmk.170.1594160700808; Tue, 07 Jul 2020 15:25:00 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id j24sm3015489wrd.43.2020.07.07.15.24.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 15:24:40 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> Date: Wed, 8 Jul 2020 01:24:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <877dvfiofy.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 07.07.2020 13:56, João Távora wrote: > You talked and talked and presented your favourite async handling > techniques, like having functions return functions that return > functions. You contented that I -- not you -- should work with it to > solve the problem. I showed a solution to the part of the problem that we managed to define at that time. You added some more features now. If you like, I can rewrite your branch in terms of that proposal. Or in terms of eldoc-future (as suggested by Stefan). Your pick. (But we still need to discuss the extra changes in this branch). > For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: I > just don't use these Eldoc fixes to shoehorn something rushedly into > Emacs. Make a new thread, or join the existing one: > > https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00935.html Thanks for the link. I seem to have missed it. Not exactly the discussion to join, but the projects mentioned there could be helpful. > Afterwards, propose a change to the technique, not only in Eldoc but > elsewhere, too. This idea is so simple that it boggles the mind that > you don't grasp it. Sure. As long as this discussion waits. >> urgent endeavor. E.g., Flymake is stable, and I don't have any >> particular bugs in mind that need solving. > > Great. I'll just note here that it uses exactly the same technique I'm > proposing in Eldoc to communicate with multiple backends: it's curious > how that doesn't bother you. I would reasonably expect "futures" or > something else its implementation much simpler too. It doesn't have existing clients that return results synchronously. It almost always works with external processes. It doesn't care if a checker never calls back. It doesn't compose results from multiple checkers. Basically: it's simple, and whatever legacy it did have, you cordoned that behind flymake-proc (which everybody promptly migrated off). And as you can note, the interface you proposed here is not exactly the same: due to some of the requirements above, it's slightly different. A flymake backend is considered running whenever it didn't signal an error. The convention you proposed here involves returning a non-string, non-nil value. I imagine having different interfaces between facilities is better than having similar-by-subtly-different ones. >> Aside: given that this discussion has user interface in mind, it needs >> more consideration of actual user experiences we'd want to allow. Ones >> not provided by eldoc itself as well. For instance, I think we sooner >> or later should have a callsig floating popup (in the vein of MS's >> editors) as an alternative to showing the signature in the echo area >> only. > > That is addressed in a comment in eldoc-docs > > ;; Finally, output to the echo area. We handle the > ;; `truncate-sym-name-if-fit' special case first, by selecting a > ;; top-section of the `*eldoc' buffer. I'm pretty sure nicer > ;; strategies can be used here, probably by splitting this > ;; function into some `eldoc-display-functions' special hook. I think the first question to ask here, is whether the eldoc clients are not ultimately the best place to decide how the doc should be formatted and displayed. So the alternative to your current proposal (with composing strategies) would be for us to provide a set of utility functions to clients: ones to manipulate async computations, ones to truncate the doc to desired dimensions, ones to combine several docs in one, etc, while honoring the value of eldoc-echo-area-use-multiline-p. The advantage to that approach is that we don't limit the display to particular format (e.g. the truncate-sym-name-if-fit requires the symbol to be at the beginning of the line, and for it to be specified as the :thing property as well). The downside: mainly being unable to compose eldoc results from multiple clients. But I wonder how well we can manage to handle that anyway. > I agree there is ample space for improvement, including a > "floating popup" (which I wouldn't limit to callsigs though). Make > another bug report to study this. Callsigs are a whole other matter, actually. The best experience seems impossible to implement through eldoc. The LSP protocol shows an example of a good data structure required for it (a list of overloads, the number of the current guessed one, and a documentation string for the function). Eldoc can be used in the absence of other options, but a different hook which requires richer values seems more appropriate. >> The new API is incompatible with the previous one, it requires >> changing a lot of functions (though admittedly in a minor way). > > This is demonstrably false. As I've explained to Eli there is no > incompatibility in practice. 0 (zero) third-party extensions make use > of the protocol being changed from Eldoc 1.0.0 to Eldoc 1.1.0, unless > you're stalling here to secretly work on one. So what happens if we merge this to master now? Either you expect no clients, and there is no need to hurry, or we expect some new eldoc clients to use this interface. But then the same clients will experience breakage as soon as we switch over to "proper" futures. > But if we really, really wanted to, it's easy to get rid of the > arguments, too, with a variation to the callback technique. I just > don't think it's worth it: a technique is a technique. The variation that I showed in my little patch a month ago? >> is easy to miss, as evidenced by describe-char-eldoc which still >> doesn't accept any arguments. > > Oh, an actual useful comment! Easily solved, thanks. And it was only > "missed" because it wasn't used anywhere. Well, you corrected its docstring in this branch. >> The choice to require a return of a non-nil value if the callback is >> going to be used is also kinda odd (+1 control flow to test). What's >> the problem with using the callback synchronously if the doc is >> available right away? > > Nothing, you can do it. As long as you return non-nil, non-string. But > if you are are going to synchronously call the callback on a string, you > might as well return that string, just seems simpler. Seems like a missed opportunity to simplify (or not). >> First of all, if I understand the main motivation behind it, it's to >> delegate the implementation of asynchronous primitives to Eldoc. > > It's rather to make clients don't worry about the synchronization. Because it's fairly difficult, right? Especially in the absence of helpful standard libraries. >> We don't want to bother with that in Eglot, etc. But you mentioned "a >> type of docstring" to be returned in the discussion (and the callbacks >> have the plist argument as a future proofing). If the type is a >> buffer, its contents might as well be created from several async calls > > If you want to support "buffers" as a "type of docstring", just do that: > make buffers a type of docstring. The obvious way is to have multiple > sources produce multiple buffers. That doesn't really jive with what I imagined. If I want to produce a "pretty" buffer in a client, I will print to it. Possibly making several HTTP calls in the process, if that's not hard to do. I would also probably prefer not to worry about some other eldoc client leaving its documentation function in the list before mine. Or having them later in the list, leaving some unrelated stuff in the resulting buffer. As a client, I would probably know which calls are made, which data is returned, and how I want it to be rendered. > Thing: why would you ever want to put buffer-joining complexity in the > client? Because it knows in which order to put them? Or how to render the seams best? Or it could mix the HTTP responses in other ways than simply joining them with "\n\n". Having generic code do that seems limiting. Having individual clients do that should encourage more attention to detail. >> The strategies themselves: >> >> - eldoc-documentation-enthusiast: What's the difference compared to >> the 'default' one? Sacrificing CPU load for lower latency? It's an odd >> choice to force the user to make. The only people who can make an >> ideal decision regarding this are probably the authors of >> eldoc-documentation-functions, but it wouldn't help if >> eldoc-documentation-functions has functions coming from different >> authors, facilities, etc. > > Has nothing to do with CPU. This is the way Eglot works now, or at > least tries to: there are two delayed doc-producing backends, and > neither is guaranteed to complete. Why not? HTTP responses normally arrive reliably. > One has priority over the other (and > special hooks are a decent, standard Emacs way to manage priority) > > Eglot shows the lower-priority one if it shows it can survive for more > than x seconds (currently x = 0.3, uncustomizable). No more doc > blinking. Why not just wait for the first one, if its documentation function returned non-nil? I considered commenting on the 0.3 magic number, but dropped it in the first review. >> - eldoc-documentation-compose: Okay, this is kinda interesting (though >> not essential), > >> I think the only reasonably predictable behavior would be to truncate >> each of them to one line, always. > > That's a display problem, not a composition problem For now it works OK > for one liners and also multiple multi-liners. Displaying doc is not > the main goal of these patches, there is certainly room for improvement, > as I said above. Whether we can reliably display these docs in a "composed" way, from any sources, or not, should probably factor into the design. Because if not, do we really need different strategies? >> - eldoc-documentation-compose-eagerly: Ooh, now I think I see why >> Returning futures instead (when async is needed) would provide this >> kind of guarantee without the seeming duplication of signals. > > Can't let go of that futures drum, can you? It'd be a pleasure to see > you walk the walk. There's not much inherent difficulty in extracting the future-merge code from here or elsewhere. The actual problems I mentioned in the email with the (tiny) future.el come from elsewhere (e.g. from requirements for using them for completion), but they need to be decided on, in order to minimize breakage later. >> On a related note, I believe some facilities might want to use only >> certain "kinds" of documentation functions (as indicated by the plist >> arguments). If the plist is only provided together with the response, >> there is no way to avoid unnecessary computations (e.g. making HTTP >> requests that return some other kinds of values). If the plist was >> returned together with a future value, however, it would be easy to >> do, as long as we document that the futures should start the >> computation until a callback is provided (if possible, at least). > > Save it for your future futures implementation. My point was, again, adopting futures here would create a structural change. A more incompatible one than if we adopted a more compatible API. Or straight away used eldoc-local futures. >> And in a different high-level argument: you stated that you intend to >> have Eglot use a non-default value of eldoc-documentation-strategy. > > OK, but this has nothing to do with Eldoc, does it? Make a bug report > for Eglot, I'll explain why it does this, and maybe I'll change it.. It does, if the actual requirements here mean that Eglot could just as fine perform combining its documentation results itself, in its documentation function. Then Eldoc could eventually do away with the eldoc-documentation-function/strategy variable altogether. And the current change to the API would be minimal. >> idea). This should very well be possible to untangle in the future, >> but I'd rather not have code like this in Emacs if we can help it. > > You're such an ace programmer that you code alternatives that are so > brief that they occupy no code at all! Nice punch. I hope you haven't missed the implication that it's _hard_ for me to make heads or tails of your code there. But I could take a shot. >> Further, having all strategies basically delegate to hardcoded options >> inside eldoc-print-current-symbol-info seems to confirm that the set >> of available strategies is a closed one. Which is not what I would >> expect from a variable called eldoc-documentation-strategy. > > There are four strategies to choose from but you can make more. What > did you have in mind? Well... if I were thinking further in the direction of strategies, perhaps some would first request/wait the documentation from sources that return buffers, and then if none of those return any, then query the rest of functions. Or order the sources based on their kind before doing the calls, using user-supplied algo. Or perhaps skip buffers which are already displayed in some window. My point here was, though, that a strategy sounds like something customizable and extensible. So their semantics, docstrings and implementations will need to be more accessible to an average Lisp developer. >> These are my objections, for now. I'll have to study >> eldoc--handle-docs a bit later, but any problems it has are probably >> orthogonal to the rest of the list. > > Thanks. Having looked at it, the only problems there I can report on are practical, the same as I described when talking about eldoc-documentation-compose in the previous email: blinking after every user command, missing truncation when composing several docstrings, and undefined behavior with multiple multiline docstrings. Is it at all possible to get rid of blinking? One-line eldoc doesn't blink. Also, umm... it seems to truncate the contents of a long doc buffer to its bottom part. At least that's what I get when trying the related branch of Eglot.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 16:08:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 12:08:03 2020
Received: from localhost ([127.0.0.1]:36597 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jsq8Z-000190-5B
for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 12:08:03 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44108)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jsq8X-00018F-5G
for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 12:08:01 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9A81580A1F;
Tue, 7 Jul 2020 12:07:55 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B59B880B74;
Tue, 7 Jul 2020 12:07:53 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1594138073;
bh=G6Eo9Gg54jCUcvRFCG+PrRWzkdGztaR5cBdbfTB+5/o=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=imI3SPXmLv5XnVH6bxw5GMDBccfSm6Y3SVIl4z/hqiaS/83Gu1tlIcGEpcVjLhelI
7PW6SFrI7ieIwFHnW+ciyqi53vqCOXerIUhS0WBz7kdUItfvqjToW1HBscgwi3aQrX
RhMp82I090Xg+WUiYJqUkXfPVW5jCQZwYL7x8MoqDjWzn5kN3GkU7A/YMyqCsZLPop
9Q8ydIxcwF4rURwhzwGkL2R9rPXh75hMsWxRyuY0/EB3pxRQWU5sZut783/7PECFpk
LmkyD0zPlsTx4SCHQUtdfkt/DTU06+kp+76m9a1MmUEvjmvJiXWGrfJNiWTrWEBage
7Pq56RRZaJp4A==
Received: from alfajor (unknown [157.52.0.200])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7C8CD12030B;
Tue, 7 Jul 2020 12:07:53 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
<87tuynsdp6.fsf@HIDDEN>
<5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
<87h7umop62.fsf@HIDDEN>
<671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
<877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
<3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
Date: Tue, 07 Jul 2020 12:07:52 -0400
In-Reply-To: <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> (Dmitry Gutov's
message of "Tue, 7 Jul 2020 17:24:18 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.022 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> The current discussion, and the current eldoc-async branch adds some more
> design decisions, as well as breaking changes.
I don't see any breaking changes (other than to things which haven't
yet been released IMO).
> As soon as we get futures/promises/aio into the core, that will cease to be
> the case.
Then let's get moving on that. No need to wait.
> But I fear we wouldn't be able to roll back the related decisions
> so easily, however.
I don't see any reason to fear that. The more time we spend discussing
what the ideal should look like, the less time we have to actually
get there.
The current eldoc-async branch doesn't get us further from the ideal,
I believe, unless `emacs-28` gets cut before we get our act together.
But if we don't get our act together before `emacs-28` then the
alternative is to have Emacs-28 without support for async eldoc, which
I think is even worse.
I recommend we try and be pragmatic. Especially since it will make us
all happier (instead of arguing against each other, we get to work on
improving the code).
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:45:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 10:45:30 2020 Received: from localhost ([127.0.0.1]:36469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsoqg-0007Nt-0J for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:45:30 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:35078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jsoqe-0007Nh-Jm for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:45:29 -0400 Received: by mail-wm1-f67.google.com with SMTP id l2so45318019wmf.0 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:45:28 -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=Qz4ueyref7OpFfZzbWzhcJeY4LYvkcSUdyVzNWRvLMY=; b=AXzALvK71pu/aq69sq+imK2FUo7bAeRX/GYihMmFBJH9X/RCEKrm+XucwqWa93GpLW XopfuOkMWWyhSdND+aEg+0bDogM6CS4yJ/NNaFm3nGmlV7yJg51iwwDw/nNgyy/pamc6 NZ7gVL/vQgfEGDOncQ+SaLuNl7gUI7TpxXD4K/wuco+CKksuk7N7ixwAT4HKZlyyLsOx A7Bgc+IZcduNcmVdLSEIkUli/jf+3EaUjwORAKU58auTeX8+MZHz67+YJBO+5nrL5ABM xzypzvgNonvfqAM3EyqgBZuWrcWhta/q/fhbmN7VSfozk1wDEz2GQNEZB8EDr/WDpkrC pwRw== 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=Qz4ueyref7OpFfZzbWzhcJeY4LYvkcSUdyVzNWRvLMY=; b=LEO29FxYs1ZxjCtFp7arFa3wj6xv3E8z13YF6qx48kctDO7Kl8mHq78ybn700jyuhn Mjz9BdxwnTPxZJWJuR72lXNZUXwMAi0VYEcCxzIemXt13KbVewZXxg7cXt90idWTJPQK RK1wEC6NWaQ15zejOskNGLC57k0qOjtv0PwUcuBshJ1L5P1TuxPygIMEjt/MY7CQOQk5 7Oa4Vdrv5F0lT5qFnG0iTgsaRo49OUcocv2IaRbS0iakIEVmffsJujUEbSC15T2N2R7v 3BEJ9Tbyw8LG1jiNIZ/ns+UBTaaWMW0NTvaDyTxZrp5VcU5M1QsM/pWz1QKtwucUuEt/ jUpg== X-Gm-Message-State: AOAM532wv5Ctd7kKPCPobZl5WIAi3WRIZ3G9bguit3VB5BV/ndbTJK4r yshTPz1rbSqWCtD2YKREO8Y= X-Google-Smtp-Source: ABdhPJzp3f9q7cNdtvgEkudMRhRSUYXFOGQmaQKtIMs/I0u0MdDEJRJtRtHDSOSXt4CLO95pQGpaSQ== X-Received: by 2002:a1c:9e06:: with SMTP id h6mr4335114wme.45.1594133122758; Tue, 07 Jul 2020 07:45:22 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id 92sm1404294wrr.96.2020.07.07.07.45.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 07:45:21 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> Date: Tue, 07 Jul 2020 15:45:20 +0100 In-Reply-To: <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Tue, 07 Jul 2020 09:38:45 -0400") Message-ID: <87k0zfgz9b.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: > I suggest we install the current eldoc-async code into `master` and in > parallel work quickly on a futures/promises/aio/... package for > `master`. That's the point I've been making all along, indeed! Finally progress! Thanks, Jo=C3=A3o PS: I for one will try to invest some effort in some more modular/powerful eldoc-display-functions... let's hope that's less contentious.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:40:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 10:40:10 2020 Received: from localhost ([127.0.0.1]:36435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsolW-0007Dl-5l for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:40:10 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:42741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsolV-0007DU-3x for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:40:09 -0400 Received: by mail-wr1-f43.google.com with SMTP id o11so45449348wrv.9 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tmdLsAhQ1lGSzm8Y9I+NKexP/sI22/aW+rBNrrDBgAI=; b=IEDv1QHOrKvIxXwaugIs/YrmZeKFbI2rrFVkHWKJuHm7BRl1JYuWYKNlGrK0oVHBMa hHQD8m03Q7JUfDm9BToxYJH6YViTq0pUqbmlA4B8Mvqte6ArysxFSGxckaBfIopo54Hx qulL7uuED3ILaq0mG4ScYHk+3PqxETUV37P7CrPAibYxSYqLd/Igh5okuU1ZZUuIMckQ HnvXM7SHTtIwoOElvhcSdHYpXk/C3tbPJ03ldN1A1AM4cBqnEv0kNx25rxQowVlilUeb c40elBg2krhGALAu81jNB8Uk1h9YL+wA0arrTC0wrz7PHpIZt5Zv3pPA2CvhCqlrmk/B W0Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tmdLsAhQ1lGSzm8Y9I+NKexP/sI22/aW+rBNrrDBgAI=; b=kYqdZjsnsiGfRGFaNCmJaFMVfdciUkjoUeP74iBi4583NiTCNLCWnZRLK96BxL8tFu UjThJVzgDIauTRYIq18LHzYBhg6EOvIqLv1dBQN7Lmrq09k+iDRpoZtcs0pf0mlnhO7C TlvoS5+p9//M1vL8e3sN0H95en/Hh2UFcpklZ/LIIxEdGB0Mrx5SDjLf4jAlT/t4ay0O fVRXdJgLldJ2I/chultBLfVIZHnmf1vq/8dpOd8Q5BGL6P0XRgUdnK7KrfgnCs0IV9oR nWeP+rN+v3xrKOnU106/6M96oBLjy/HK6xaCD8i/jFvaA+yXdA7Wd+ZVw1GxSO2asvYW ccOA== X-Gm-Message-State: AOAM533FyapIO3tsj/VSMqJ/4x1FQIlCxcttiJFgsK20kHZB2BP+SHlc 1TRq9UVzo7MqhQld/4TGNBA= X-Google-Smtp-Source: ABdhPJwyUgnILBhalOJyE4hv7dKYcwRym7Ntabw+yD/Azl04QnYd4pUyADl1/NPJyUHoPMmXsPp7bQ== X-Received: by 2002:adf:ed47:: with SMTP id u7mr58421602wro.201.1594132803193; Tue, 07 Jul 2020 07:40:03 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 63sm1320613wra.86.2020.07.07.07.40.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 07:40:02 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <84a17480-cf10-8176-3080-61e5947ac6ed@HIDDEN> Date: Tue, 7 Jul 2020 17:40:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <877dvfiofy.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 07.07.2020 13:56, João Távora wrote: > Are you in any way trying to say that you presented a "simple solution" > that somehow magically solves the problems of Eldoc? If you do, you're > living in conflict with reality. > > There is the problem to be solved. And then there are techniques for > solving the problem. These are two entirely separate things. To be > absolutely clear: you have not, ever, proposed an alternate solution to > the Eldoc async_problem_. Perhaps there is a misunderstanding here. What would it take for you to say that "the problem" is indeed "solved" to a sufficient degree that your work on Eglot can continue? If you could mention both the strictly minimum conditions, as well as the "bonus round", that would be great.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:34:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 10:34:54 2020 Received: from localhost ([127.0.0.1]:36415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsogQ-00074l-LP for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:34:54 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:38501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jsogP-00074W-2T for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:34:54 -0400 Received: by mail-wr1-f51.google.com with SMTP id z13so45395944wrw.5 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:34:53 -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=WZsl3efc9qUf18ZTdQjylNux0op5veEUMsuIODH7bLg=; b=BV7NGpnjg/jFaVwhWpevIaPj9ZpoNLf1BXz18KcXe9+S9FZZKC+rDlHA970FvWMDW6 FJ3dh9qi9tgyOb8+f2sop7B/rruWQJ5JQCZ2ht6odr2DRDLXwYe8492t3jczJkfZ+I0+ X6Nte+O7ScEjsOm5oOn8sbGCFQWw2cMYFNk5+5rAGaelalvAouXcRnra4pwTJyqdjjBO JOIpNQarJHoNwhjpydAQ8v8GsGbPjfdRfW+rImJRRvZVQWNG+R9kAgML4HL63uL6nQoF Hk5jMYQcjuTB9X9eCgEcdKHrJ0s9jQ9zuhx2hk0IYiX35kpWa/z3LnAkA4Dplos49Y3/ hsLw== 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=WZsl3efc9qUf18ZTdQjylNux0op5veEUMsuIODH7bLg=; b=ArT5VRpps9qYef/Fd608SmBtZ3u9lZkbWwZBIGizobA7YPbGa4wXEmOqJAXVLr4Cd8 hAhV1TgOj7eyxbyYdnqyihBB4sTG2OxAPTd2fjlMqDfri8iJLHHUprXL5L9ubULmPu09 7qMGAhtNOAHqa5qqocymOh1amvjhbBZjSmNmR3kAG17StAU8LHOkRzI7LOSylnjfHfsM FpgBC21YRskpn+I/PSNjxVwkCyxdsGQioZ/G/0WICqXQBJ01n+TcvCbFtS6fC3xY6Ksm mPhvwNkFYr3H8m7J6pRE+VlrSpgulFRBmw5LHJr0gtnBwmkJmKa7x55RKcaEPUgUZwNU ki0Q== X-Gm-Message-State: AOAM533kiWpu5YjH/5XhkNuSRB1PRpjvMynDhAp1ws2/SpG72kHUKa30 Qxp2ePKvGJXWuipKdQP1Mvg= X-Google-Smtp-Source: ABdhPJzrk4tH3w8kdjSff9awiLE4nqxm8b59h9rTvUAK/RamI9zU2FJM1jfpJ0yCcx2rxCywqMedgA== X-Received: by 2002:a05:6000:1182:: with SMTP id g2mr50646748wrx.44.1594132487250; Tue, 07 Jul 2020 07:34:47 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id c206sm1381273wmf.36.2020.07.07.07.34.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 07:34:46 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN> <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> <87d05aoowh.fsf@HIDDEN> <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN> <873663iob0.fsf@HIDDEN> <a952c5d5-6569-b1b9-1981-618d9efd1bbb@HIDDEN> Date: Tue, 07 Jul 2020 15:34:44 +0100 In-Reply-To: <a952c5d5-6569-b1b9-1981-618d9efd1bbb@HIDDEN> (Dmitry Gutov's message of "Tue, 7 Jul 2020 17:18:09 +0300") Message-ID: <87r1tngzqz.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 07.07.2020 13:58, Jo=C3=A3o T=C3=A1vora wrote: >> I've told you this before: you mistake attention for obedience. > > Most of the time I feel you're not even addressing my points. I try my best, but I don't have any control over your feelings :-)
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:24:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 10:24:28 2020 Received: from localhost ([127.0.0.1]:36405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsoWK-0006mU-F4 for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:24:28 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:33507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsoWI-0006mH-5V for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:24:26 -0400 Received: by mail-wm1-f46.google.com with SMTP id a6so1871744wmm.0 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W+F9C82WWkJmCj99W9SOwacXHCQJ1i1XU4B23/L9LqU=; b=mWAxLS8MdRrPShNxw47oE9rzSvOtr/Luz1GmTBfcifIBoIn5bP55Td6nnzeeg5wph3 4nlOrUtBbuBUWTct3OW1yV04n45toHO55C5xslHpQX7bQ62jDTK/p2LTCm9gZ2BDEPTm fChdbmDkjzrjdRSvCzNoTzsRaMXa2pziMimlot8X87jjfKCzDdf8HVthIJWCQI5K6DH5 s52WCybTYiWBQqyltt5VlSRBAYJX8+dSXOq9HpJ9bpoVwwNr051zNr0oGvz+tVshpbxc pMogJk7/5h61wCzcByIX+TQiGcE44FCHTsdKKzv2oC67jHOM5nPh+kzdwjFZF1GnGe3c XP8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=W+F9C82WWkJmCj99W9SOwacXHCQJ1i1XU4B23/L9LqU=; b=sG53S0+iEyy6YUkTcb/jE3iJJnJ9NHxDkFIGPgm1IL3N0wBNWKCZMMLSGmEFxdWrqn r9FdjUxETYSvyjS1eM8hOvU2yqphkXK1rF4Jse5a6foSzwyEjoOwdeN+tpf3xc1hx14e S3E/wxCzXKfJvSxY4tbu3cfa3LrWlUfuC6L3Zp67bu1D/M/HdkR1s34DOy+KADLkOQ+c XDJ4mFOEJRDmMQUDbzPiwgQNii6ButhsAmaTnHotCy5wcVjkOmLGxavJJmDVAW+Ucuqd 6tlYBBM5sPscMMutyqSlxoly+ceZmz3eLxq+sntXAorOhaVatqnEC0aWnIU8HXJsGLda Caog== X-Gm-Message-State: AOAM532fjGsGLw5bKCTK5K6QQlKVAJWCoBgw382r+o1l2t3alKN5I4wS UPfhYEtBrZQhFTgJb3t/bdA= X-Google-Smtp-Source: ABdhPJwrUd0+5TfHRmM6cHQShwWoGdg3Y2oU1yLosEmXMJTIOuEqW7HnPvXYrQ12fvUoWFoFxdYX8w== X-Received: by 2002:a1c:de07:: with SMTP id v7mr4518106wmg.56.1594131860441; Tue, 07 Jul 2020 07:24:20 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 2sm1162683wmo.44.2020.07.07.07.24.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 07:24:19 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Stefan Monnier <monnier@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> Date: Tue, 7 Jul 2020 17:24:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 07.07.2020 16:38, Stefan Monnier wrote: > As long as it's done before we cut the `emacs-28` branch, I can't see > any reason why we couldn't change the new (and hence not yet released, > except for the GNU ELPA package) API in a backward-incompatible way > (just like the eldoc-async already does). It's a good point, and if that was all that we'd need to agree on, I'd be fine to proceed. But if we just wanted to get async into Eglot, that's what my simple patch did: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41531#8, proposed months ago. With minimal backward compatibility issues. The current discussion, and the current eldoc-async branch adds some more design decisions, as well as breaking changes. And those decisions seem to be informed and made necessary by the lack of standard functions for combining async computations that eldoc clients could use. As soon as we get futures/promises/aio into the core, that will cease to be the case. But I fear we wouldn't be able to roll back the related decisions so easily, however.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:18:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 10:18:21 2020 Received: from localhost ([127.0.0.1]:36397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsoQP-0006cR-H3 for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:18:21 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:36170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsoQL-0006cA-Hd for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:18:20 -0400 Received: by mail-wr1-f54.google.com with SMTP id k6so45344764wrn.3 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5sJyn4G7owkFSRMDf77IxnlseK33nLbnh8K7xaok+8k=; b=GQGy0ZGOud8pRdAgqzqtJHmJdoF14io6MUKllYAE2E4kx1YfVh734iaR7V4dPVPXn7 b8RAHToAzmSq+EtdG5pY1dT3QF1f/NHQ7SohiWqSPQf7/tMFfUjJnTQb6dLhWMx169dT zckQV2li8GpHjGyQEtV1OCdIl2cd69Ljtu+v6Ildj3iGFL8r3s6WCU7gK5iZe46urIoT kJ/zyi+GvavxOHQieOaCAZ189aIpt4O/VdICfxy/NnjuztKoEzipq4+3MTOF9zJ45xl4 J/cO8uL35bDyD0zeZuzauwBtreGAyy+yje+/Y/TeieEBcg1f81zAzh3EFECVu5t7AWJS A0kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5sJyn4G7owkFSRMDf77IxnlseK33nLbnh8K7xaok+8k=; b=QkWH+B588YsYxELgg7Vyt4/ybrOBsJzDRggfz8SeBjeJAcbDy1s7FzPM6pHqbXiZsB iqz/sf9nbsAnvRjLQxmXLVMP3eSGFntqx//DB3PJyc/zxzBgcJfL9hkjG6asrik6jkS3 Gi/dGJ7Ryhb/UyoCyoJbbafIKxezOMNX8x4/LdE3u8rccevKqsjBaxqClerJ5JCsa6XG oI2cw2VXDKTTDb+JcoCejxWEfD9F0n8CxTfnGaj85Lk7E7B9wYaZS0vZ5DE8BCoL7usw YvJW6nKqc2bWYJTU4cr2VppVriogfwSe9fgjKs3OZGRjj3L+5/mHHCsdEZJmFM8EnNiV kDGQ== X-Gm-Message-State: AOAM530XAAFxFZyp6ffbvpVC8Zw+aJY/g1R6JrsPfjAwL+B6fQ1PHdxL n46qLzRtLFQ+7W5tu5M4zq4= X-Google-Smtp-Source: ABdhPJzUwSW19vIWtylLJlMcEX6XNzU2dQZYm2vLQlNgBVrkGsWu/HxLwrXJLZHd08FoXjJyyc2Zig== X-Received: by 2002:a5d:60c5:: with SMTP id x5mr19751827wrt.67.1594131491737; Tue, 07 Jul 2020 07:18:11 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id m10sm1295652wru.4.2020.07.07.07.18.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 07:18:10 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN> <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> <87d05aoowh.fsf@HIDDEN> <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN> <873663iob0.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <a952c5d5-6569-b1b9-1981-618d9efd1bbb@HIDDEN> Date: Tue, 7 Jul 2020 17:18:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <873663iob0.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 07.07.2020 13:58, João Távora wrote: > I've told you this before: you mistake attention for obedience. Most of the time I feel you're not even addressing my points.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 13:39:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 09:39:02 2020
Received: from localhost ([127.0.0.1]:35771 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jsnoL-0005TQ-O1
for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 09:39:02 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48936)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jsnoG-0005T9-4k
for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 09:39:00 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E4C1100E87;
Tue, 7 Jul 2020 09:38:50 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 628BC1005A8;
Tue, 7 Jul 2020 09:38:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1594129127;
bh=KIevi42Yxm8vrvACP2tc7Ba9zbra3LiOkiKGtvpxqPI=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=hbA/pIZH1U2TfF8IsN8TNdYsAoSZC2jjzpD6QmgcTk1kupoXq7B6Oc4luBCkjTSgi
By9PsBXRPTHMAz6xkbogYZXgjqAUhZ+VBOfblb+DNkIpNSeGpty0zaLR1zSH1ecQDW
i0RO8/HCO7jB+j6Ck5px5pw1Z0F+4bpnQr9ESsPSMIonlAkAdoK6ijoirt/qY+1EbT
KUmJ1DKDzZRKfDeZ6kBryImM4vGoYmjxA0oTtLxsE+zFIEo4N1mwJnBfKkWZ2p/CLT
EX0X/CMWC6PrrSbeuKuKduRDW0MOXIZ8RXkCr69g04S5keNHtTNBYMU5x6oyru7ccv
5sjk0jB0+Xqyw==
Received: from alfajor (unknown [157.52.0.200])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D29B1120329;
Tue, 7 Jul 2020 09:38:46 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
<87tuynsdp6.fsf@HIDDEN>
<5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
<87h7umop62.fsf@HIDDEN>
<671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
<877dvfiofy.fsf@HIDDEN>
Date: Tue, 07 Jul 2020 09:38:45 -0400
In-Reply-To: <877dvfiofy.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Tue, 07
Jul 2020 11:56:01 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.034 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
[ Sorry I can't really take part in the discussion, 'cause it's
a rather busy time here. ]
[ The discussion is becoming too tense for my taste. Please take
a break and think whether all this is important enough to warrant
criticizing each other this way. I think you're both great hackers
whose opinion and expertise I value very much. ]
I think getting async support for eldoc is more important than *how* we
get it.
I suggest we install the current eldoc-async code into `master` and in
parallel work quickly on a futures/promises/aio/... package for
`master`.
As long as it's done before we cut the `emacs-28` branch, I can't see
any reason why we couldn't change the new (and hence not yet released,
except for the GNU ELPA package) API in a backward-incompatible way
(just like the eldoc-async already does).
Stefan
Jo=E3o T=E1vora [2020-07-07 11:56:01] wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>> Please don't make it sound as if I'm the only one here having a strong
>> opinion about proposed code. You disregarded the simple solution in=20
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531#8, and then went
>
> Are you in any way trying to say that you presented a "simple solution"
> that somehow magically solves the problems of Eldoc? If you do, you're
> living in conflict with reality.
>
> There is the problem to be solved. And then there are techniques for
> solving the problem. These are two entirely separate things. To be
> absolutely clear: you have not, ever, proposed an alternate solution to
> the Eldoc async _problem_.
>
> You talked and talked and presented your favourite async handling
> techniques, like having functions return functions that return
> functions. You contented that I -- not you -- should work with it to
> solve the problem.
>
> Callbacks, futures, promises, ad-hoc or proper, are just techniques. I
> tried a couple techniques, including a basic futures-based one proposed
> by Stefan. I didn't find any as compelling as the simplest and most
> widely used in Emacs: callbacks.
>
> For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: I
> just don't use these Eldoc fixes to shoehorn something rushedly into
> Emacs. Make a new thread, or join the existing one:
>
> https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00935.html
>
> Afterwards, propose a change to the technique, not only in Eldoc but
> elsewhere, too. This idea is so simple that it boggles the mind that
> you don't grasp it.
>
>> urgent endeavor. E.g., Flymake is stable, and I don't have any
>> particular bugs in mind that need solving.
>
> Great. I'll just note here that it uses exactly the same technique I'm
> proposing in Eldoc to communicate with multiple backends: it's curious
> how that doesn't bother you. I would reasonably expect "futures" or
> something else its implementation much simpler too.
>
>> Aside: given that this discussion has user interface in mind, it needs
>> more consideration of actual user experiences we'd want to allow. Ones=20
>> not provided by eldoc itself as well. For instance, I think we sooner
>> or later should have a callsig floating popup (in the vein of MS's
>> editors) as an alternative to showing the signature in the echo area
>> only.
>
> That is addressed in a comment in eldoc-docs
>
> ;; Finally, output to the echo area. We handle the
> ;; `truncate-sym-name-if-fit' special case first, by selecting a
> ;; top-section of the `*eldoc' buffer. I'm pretty sure nicer
> ;; strategies can be used here, probably by splitting this
> ;; function into some `eldoc-display-functions' special hook.
>
> I agree there is ample space for improvement, including a=20
> "floating popup" (which I wouldn't limit to callsigs though). Make
> another bug report to study this.
>
>> The new API is incompatible with the previous one, it requires
>> changing a lot of functions (though admittedly in a minor way).
>
> This is demonstrably false. As I've explained to Eli there is no
> incompatibility in practice. 0 (zero) third-party extensions make use
> of the protocol being changed from Eldoc 1.0.0 to Eldoc 1.1.0, unless
> you're stalling here to secretly work on one.
>
> But if we really, really wanted to, it's easy to get rid of the
> arguments, too, with a variation to the callback technique. I just
> don't think it's worth it: a technique is a technique.
>
>> is easy to miss, as evidenced by describe-char-eldoc which still
>> doesn't accept any arguments.
>
> Oh, an actual useful comment! Easily solved, thanks. And it was only
> "missed" because it wasn't used anywhere.
>
>> Whereas we could limit ourselves to the change which would only make
>> the clients use the different hook (or keep using the old one, for
>> compatibility with older Flymake/Emacs versions).
>
> Compatibility to the old `eldoc-documentation-function' protocol is
> fully guaranteed.
>
>> The choice to require a return of a non-nil value if the callback is
>> going to be used is also kinda odd (+1 control flow to test). What's
>> the problem with using the callback synchronously if the doc is
>> available right away?
>
> Nothing, you can do it. As long as you return non-nil, non-string. But
> if you are are going to synchronously call the callback on a string, you
> might as well return that string, just seems simpler.
>
>> The decision to double down on having different
>> eldoc-documentation-strategy values seems odd to me in several
>> respects.
>>
>> First of all, if I understand the main motivation behind it, it's to
>> delegate the implementation of asynchronous primitives to Eldoc.
>
> It's rather to make clients don't worry about the synchronization. Not
> specifically to make Eldoc worry about it. As soon as you and others
> come up with the uber-async library, I think Eldoc and Flymake and many
> others will be very pleased to delegate work to it.
>
>> We don't want to bother with that in Eglot, etc. But you mentioned "a
>> type of docstring" to be returned in the discussion (and the callbacks
>> have the plist argument as a future proofing). If the type is a
>> buffer, its contents might as well be created from several async calls
>
> If you want to support "buffers" as a "type of docstring", just do that:
> make buffers a type of docstring. The obvious way is to have multiple
> sources produce multiple buffers.
>
> Thing: why would you ever want to put buffer-joining complexity in the
> client? They're not in the business of doing async gymnastics, they're
> in the business of serving things coming from servers as efficiently and
> effectively as possible.
>
>> , which would require the same async primitives (though rather in
>> general purpose form) available on the client anyway. Though it
>> doesn't seem to be necessary for LSP in common operations, it's
>> unlikely to be the only such protocol we'd ever want to support.
>
> I don't know about that, but if we did, the current mechanism work
> nicely for the example you presented.
>
>> The strategies themselves:
>>
>> - eldoc-documentation-enthusiast: What's the difference compared to
>> the 'default' one? Sacrificing CPU load for lower latency? It's an odd
>> choice to force the user to make. The only people who can make an
>> ideal decision regarding this are probably the authors of
>> eldoc-documentation-functions, but it wouldn't help if
>> eldoc-documentation-functions has functions coming from different
>> authors, facilities, etc.
>
> Has nothing to do with CPU. This is the way Eglot works now, or at
> least tries to: there are two delayed doc-producing backends, and
> neither is guaranteed to complete. One has priority over the other (and
> special hooks are a decent, standard Emacs way to manage priority)
>
> Eglot shows the lower-priority one if it shows it can survive for more
> than x seconds (currently x =3D 0.3, uncustomizable). No more doc
> blinking.
>
>> - eldoc-documentation-compose: Okay, this is kinda interesting (though
>> not essential),
>
>> I think the only reasonably predictable behavior would be to truncate
>> each of them to one line, always.
>
> That's a display problem, not a composition problem For now it works OK
> for one liners and also multiple multi-liners. Displaying doc is not
> the main goal of these patches, there is certainly room for improvement,
> as I said above.
>
>> - eldoc-documentation-compose-eagerly: Ooh, now I think I see why
>> Returning futures instead (when async is needed) would provide this
>> kind of guarantee without the seeming duplication of signals.
>
> Can't let go of that futures drum, can you? It'd be a pleasure to see
> you walk the walk.
>
>> On a related note, I believe some facilities might want to use only
>> certain "kinds" of documentation functions (as indicated by the plist=20
>> arguments). If the plist is only provided together with the response,
>> there is no way to avoid unnecessary computations (e.g. making HTTP=20
>> requests that return some other kinds of values). If the plist was
>> returned together with a future value, however, it would be easy to
>> do, as long as we document that the futures should start the
>> computation until a callback is provided (if possible, at least).
>
> Save it for your future futures implementation.
>
>> And in a different high-level argument: you stated that you intend to
>> have Eglot use a non-default value of eldoc-documentation-strategy.=20
>
> OK, but this has nothing to do with Eldoc, does it? Make a bug report
> for Eglot, I'll explain why it does this, and maybe I'll change it..
>
>> Next, eldoc-print-current-symbol-info is a mess, very hard to
>> follow. I am frankly offended that you argued that both ad-hoc futures
>
> I meant no effense.
>
>> idea). This should very well be possible to untangle in the future,
>> but I'd rather not have code like this in Emacs if we can help it.
>
> You're such an ace programmer that you code alternatives that are so
> brief that they occupy no code at all!
>
>> Further, having all strategies basically delegate to hardcoded options
>> inside eldoc-print-current-symbol-info seems to confirm that the set
>> of available strategies is a closed one. Which is not what I would
>> expect from a variable called eldoc-documentation-strategy.
>
> There are four strategies to choose from but you can make more. What
> did you have in mind?=20=20
>
>> These are my objections, for now. I'll have to study
>> eldoc--handle-docs a bit later, but any problems it has are probably
>> orthogonal to the rest of the list.
>
> Thanks.
>
> Jo=E3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 12:23:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 08:23:16 2020 Received: from localhost ([127.0.0.1]:35675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsmd2-0003Zo-B6 for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 08:23:16 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:40183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jsmcx-0003ZY-G4 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 08:23:15 -0400 Received: by mail-wr1-f53.google.com with SMTP id f2so16934431wrp.7 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 05:23: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=eRPkloRyzfybOoXLTomCGi/gUBsnCI1bWgmB/tn33S4=; b=osXGyX7pwDOHfVeDBeRgQelLdPROItTWGzDByDfVyFtDDQjbwDJ0AwIS0VxhOwKbO8 Q0+jjNFHn4divnZZ3FGldROMjemigVGR2xQedcoGayZWZOXuThH4dNjACj8OCGCHrsO/ jJ/nXCAXX02TBpWCLzVb1mW+mapVyl3QWnH+tyiYJWcdovNe7HHs1CDj48AxzxoK704+ GBkdnRiSuLRysNtvXnAm4cUMcC94sTSRxrq7yf0zT021iTjCF8hInK84L/VEIEr74ByY DaU7vIy1a6yd+f24TFLbgEkM0em47teJWFU5zAXBnZcy4VidyP/42dXLVojO0REN4sUL JW4A== 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=eRPkloRyzfybOoXLTomCGi/gUBsnCI1bWgmB/tn33S4=; b=dyTDgpZcLXJBLH7Ifau2WoyXw1K6QnqnC8exXaytbSNQ4YiCfsIeD2LWyHyMMq1yIg d069RT4PUKLeEJeLIITyVxjBYnfvq05ytw9mAl6IgFCUloXfI15dvRDF++zdaQwjeoIE I9ADsNcc6puczxcWVtz68TRV4+4q0d78CXWdAlbVB2q3fqm+Nn0uFsikKFgW6US647KF sFtOHuO9QW+5+24ZgG4yD3Rbry/cohaz8A0lB1fUW02IED52VXYzNN5VURUcx3tCu0+4 b+zIDMwIdGJ8h7CPeYdem1xFdOHrFuVyRS8vE6aofL+68Kjn+9qASpexgzKB27TadSnu oxFA== X-Gm-Message-State: AOAM531LduAHc/aUb0IOeVj9O2MplYhfoBCTdyAiIDRzEq1W3hFHR8NQ 4WvSb/IKzNEequhqBmjG46Q= X-Google-Smtp-Source: ABdhPJzKrZBk14peza7FVkJXffLe1A2uKrJTIOEZiKXHTTKgoSgKi98a/QQMONMgnTQeGqfb/VvC3Q== X-Received: by 2002:adf:fe85:: with SMTP id l5mr50848850wrr.333.1594124585649; Tue, 07 Jul 2020 05:23:05 -0700 (PDT) Received: from krug (6.213.115.89.rev.vodafone.pt. [89.115.213.6]) by smtp.gmail.com with ESMTPSA id j16sm867122wrt.7.2020.07.07.05.23.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 05:23:04 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN> Date: Tue, 07 Jul 2020 13:23:03 +0100 In-Reply-To: <877dvfiofy.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Tue, 07 Jul 2020 11:56:01 +0100") Message-ID: <87y2nvh5ug.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, eliz@HIDDEN, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: > just don't use these Eldoc fixes to shoehorn something rushedly into > Emacs. Just a further note: not only am I NOT "against" futures, I don't even disagree with you that a good async library CAN improve Eldoc and other async code. The question is, like it always is: how much of an effect and at what cost. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 10:59:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 06:59:08 2020 Received: from localhost ([127.0.0.1]:35573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jslJc-0007k4-LP for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:59:08 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:45947) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jslJa-0007ja-VB for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:59:08 -0400 Received: by mail-wr1-f49.google.com with SMTP id s10so44624340wrw.12 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 03:59:06 -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=A9hUfR3hgsQN81wDuwZMJACUBAOm1S03sRPR4TXX1jc=; b=TaJ6nYdvu4ccTiVBkfHLH0RFQQpLLUh3CCvk54aIAZN8TYqQriEGPI1LAiOHZgJuNE pe14yRCiteAi+2e1ujNQDDw1CtlFil9eH7DcDYsfjcDb2n7y8GmpLiFf0V5mLUqA6Tu7 3YPJCEI4XoEhPk8iXvEkjn8VlA2QXf/7Kmvaas+N/WxwrIf8ijwo0c7kvy6tdPgTC+XP a2zPM6H78yWoS1Eh7CjpvnlC2YPu+YrwUY0GFR8f/CsqKTNN4irxNjT5+i3qyQTEoHxc kQs5a3O0Dofl45k4Wu6huAc1epI4cGMpyVv5GEW6LNKnRm0msrN19mQUjEldH0H39nuQ mVMA== 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=A9hUfR3hgsQN81wDuwZMJACUBAOm1S03sRPR4TXX1jc=; b=QTLStpJLs3f9MP7XvnaCvzr8PgRiqXWxT4Hqu6zS3KRWmJxEX5hSTJ9nQiq7Lx7tfR xxFmk8iM4M372bdsICAkcMZMifPcLySoNWlsw8vSx+pi3DFfEQzxMEn6/e70dIkoN26S 8AxX4NK56diD1qqU0Q+gO/knaEeIhnA1/bGxDxztvIw918qq3EymUwoVbURevO7AmZIB aAiFiv7iQV7oXR3YDEjzb0AM4mVHZFsGUcZpCIKfGT9sYEyJSzIL3bcEbv6vkZzNYkMK JE/eob66sswabfn9aszm8VXrxAWrUph/kFXAMxSa8wlrIRd/wOLxoPGy3smk3Uc8bj3U 7Osw== X-Gm-Message-State: AOAM533UKCO3vCLJzk5VbivPbjfBhbL+V2g0gttQKSHs0pmQUC1d18IU EV+f6hUE00Jr0H/l2auSRjw= X-Google-Smtp-Source: ABdhPJyA9XZCRUawrvP21+eNegUECd86jBrpAU86ECmV9vd1+o5MjqV6l8LwMUAbyGmMaupqTqAtWQ== X-Received: by 2002:adf:dcd0:: with SMTP id x16mr51251651wrm.387.1594119541307; Tue, 07 Jul 2020 03:59:01 -0700 (PDT) Received: from krug (6.213.115.89.rev.vodafone.pt. [89.115.213.6]) by smtp.gmail.com with ESMTPSA id z25sm524217wmk.28.2020.07.07.03.58.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 03:59:00 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN> <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> <87d05aoowh.fsf@HIDDEN> <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN> Date: Tue, 07 Jul 2020 11:58:59 +0100 In-Reply-To: <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN> (Dmitry Gutov's message of "Tue, 7 Jul 2020 03:43:16 +0300") Message-ID: <873663iob0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 05.07.2020 02:12, Jo=C3=A3o T=C3=A1vora wrote: >> I actually have multiple people working with me in Eglot, potentially >> eager to see how things in Emacs core can be solved properly and >> effectively, and being utterly disappointed by your opposition in this >> eldoc.el case. That's the sad state of affairs IMO. > > A part of "solving things properly" is listening to feedback. I've told you this before: you mistake attention for obedience.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 10:56:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 07 06:56:16 2020
Received: from localhost ([127.0.0.1]:35569 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jslGp-0007fp-SE
for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:56:16 -0400
Received: from mail-wr1-f51.google.com ([209.85.221.51]:46304)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jslGl-0007fX-DW
for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:56:15 -0400
Received: by mail-wr1-f51.google.com with SMTP id r12so44593432wrj.13
for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 03:56: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=wFo82F9BYxp9h6i7nk/imamXlrR7Jt6bw9l2u15Wbww=;
b=sEkMZ2OLIP4WLZJ67mb2oFsazmXs04MkTxdUN+INt7E8+fzpVl6/xFRMqdRbjkfsTU
kVYBQVoy0jduDUjqRwC4UNB9Zu1pJG7UFpoZIgXnJa0O1Fz6FWNnj5oGSY29FVhqXuY1
F7QNjmCJcsWbbDg1YgCNd/5ehW8TQyY5xYg9FbZQhQgywj2Bk5u6kLfQr0eKPNAMeVeO
n1H0LexF2B5udv70L8hHNmlBsO2OImfUW3ocavONhEAL9RBBifzXUaqXW7w2Bn9XTpHx
6oSc/bc+zQO/iAIRlJ6lL4i6MjlKlv1uouzk91g3lgwcY4D36+FNGFzf52KcnvX1PcVZ
gDpA==
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=wFo82F9BYxp9h6i7nk/imamXlrR7Jt6bw9l2u15Wbww=;
b=se+hAYrn4+Waec6HUfgxqZ3czAtQOIXlEGM1axmGROtMgcxNw1m3C4rRpjmgnU9mr2
FgJDn32Mr+1OhjwbWQf2k1ncgR4aGjC1KX3K5ShrY0ymC7eYLBzKUJaXRH5ouXK6rwEM
Y7AGHunNjBYdje6jA6o3IqVq9ySEqyW5A8Lxg9VDE4fr6J06GYoAHKi5aatVqVN+2S4J
lFDoxyFeP5i5YUS07pb+gt0a9z+SJQLeUqHHynKPJOo7SxZw0NTg5U/jJtSJOIUV6Flt
SOHlL+jnY/mdsLcyqBVX3XLs+8Xn07XOAuBD0y7i4VuLxobKMZW87byUaMn7zbwqdrAq
QVFw==
X-Gm-Message-State: AOAM533N9gyHBBETQfvDMvPIldlu2x+kJ6S1u2TnvCVaam+TbvtMplL5
HcJqA9lewaK7z56k68axC6c=
X-Google-Smtp-Source: ABdhPJx8/O0plSKGWR3GUtLHztOZzY+VOjO4TzInD3vL5pIHjPaFi4Ad2mkMox86/V/YG6OvSLqg7w==
X-Received: by 2002:adf:f34c:: with SMTP id e12mr50934837wrp.46.1594119365300;
Tue, 07 Jul 2020 03:56:05 -0700 (PDT)
Received: from krug (6.213.115.89.rev.vodafone.pt. [89.115.213.6])
by smtp.gmail.com with ESMTPSA id d18sm599393wrj.8.2020.07.07.03.56.03
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 07 Jul 2020 03:56:04 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
<87tuynsdp6.fsf@HIDDEN>
<5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
<87h7umop62.fsf@HIDDEN>
<671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
Date: Tue, 07 Jul 2020 11:56:01 +0100
In-Reply-To: <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> (Dmitry Gutov's
message of "Tue, 7 Jul 2020 06:01:20 +0300")
Message-ID: <877dvfiofy.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> writes:
> Please don't make it sound as if I'm the only one here having a strong
> opinion about proposed code. You disregarded the simple solution in=20
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531#8, and then went
Are you in any way trying to say that you presented a "simple solution"
that somehow magically solves the problems of Eldoc? If you do, you're
living in conflict with reality.
There is the problem to be solved. And then there are techniques for
solving the problem. These are two entirely separate things. To be
absolutely clear: you have not, ever, proposed an alternate solution to
the Eldoc async _problem_.
You talked and talked and presented your favourite async handling
techniques, like having functions return functions that return
functions. You contented that I -- not you -- should work with it to
solve the problem.
Callbacks, futures, promises, ad-hoc or proper, are just techniques. I
tried a couple techniques, including a basic futures-based one proposed
by Stefan. I didn't find any as compelling as the simplest and most
widely used in Emacs: callbacks.
For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: I
just don't use these Eldoc fixes to shoehorn something rushedly into
Emacs. Make a new thread, or join the existing one:
https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00935.html
Afterwards, propose a change to the technique, not only in Eldoc but
elsewhere, too. This idea is so simple that it boggles the mind that
you don't grasp it.
> urgent endeavor. E.g., Flymake is stable, and I don't have any
> particular bugs in mind that need solving.
Great. I'll just note here that it uses exactly the same technique I'm
proposing in Eldoc to communicate with multiple backends: it's curious
how that doesn't bother you. I would reasonably expect "futures" or
something else its implementation much simpler too.
> Aside: given that this discussion has user interface in mind, it needs
> more consideration of actual user experiences we'd want to allow. Ones=20
> not provided by eldoc itself as well. For instance, I think we sooner
> or later should have a callsig floating popup (in the vein of MS's
> editors) as an alternative to showing the signature in the echo area
> only.
That is addressed in a comment in eldoc-docs
;; Finally, output to the echo area. We handle the
;; `truncate-sym-name-if-fit' special case first, by selecting a
;; top-section of the `*eldoc' buffer. I'm pretty sure nicer
;; strategies can be used here, probably by splitting this
;; function into some `eldoc-display-functions' special hook.
I agree there is ample space for improvement, including a=20
"floating popup" (which I wouldn't limit to callsigs though). Make
another bug report to study this.
> The new API is incompatible with the previous one, it requires
> changing a lot of functions (though admittedly in a minor way).
This is demonstrably false. As I've explained to Eli there is no
incompatibility in practice. 0 (zero) third-party extensions make use
of the protocol being changed from Eldoc 1.0.0 to Eldoc 1.1.0, unless
you're stalling here to secretly work on one.
But if we really, really wanted to, it's easy to get rid of the
arguments, too, with a variation to the callback technique. I just
don't think it's worth it: a technique is a technique.
> is easy to miss, as evidenced by describe-char-eldoc which still
> doesn't accept any arguments.
Oh, an actual useful comment! Easily solved, thanks. And it was only
"missed" because it wasn't used anywhere.
> Whereas we could limit ourselves to the change which would only make
> the clients use the different hook (or keep using the old one, for
> compatibility with older Flymake/Emacs versions).
Compatibility to the old `eldoc-documentation-function' protocol is
fully guaranteed.
> The choice to require a return of a non-nil value if the callback is
> going to be used is also kinda odd (+1 control flow to test). What's
> the problem with using the callback synchronously if the doc is
> available right away?
Nothing, you can do it. As long as you return non-nil, non-string. But
if you are are going to synchronously call the callback on a string, you
might as well return that string, just seems simpler.
> The decision to double down on having different
> eldoc-documentation-strategy values seems odd to me in several
> respects.
>
> First of all, if I understand the main motivation behind it, it's to
> delegate the implementation of asynchronous primitives to Eldoc.
It's rather to make clients don't worry about the synchronization. Not
specifically to make Eldoc worry about it. As soon as you and others
come up with the uber-async library, I think Eldoc and Flymake and many
others will be very pleased to delegate work to it.
> We don't want to bother with that in Eglot, etc. But you mentioned "a
> type of docstring" to be returned in the discussion (and the callbacks
> have the plist argument as a future proofing). If the type is a
> buffer, its contents might as well be created from several async calls
If you want to support "buffers" as a "type of docstring", just do that:
make buffers a type of docstring. The obvious way is to have multiple
sources produce multiple buffers.
Thing: why would you ever want to put buffer-joining complexity in the
client? They're not in the business of doing async gymnastics, they're
in the business of serving things coming from servers as efficiently and
effectively as possible.
> , which would require the same async primitives (though rather in
> general purpose form) available on the client anyway. Though it
> doesn't seem to be necessary for LSP in common operations, it's
> unlikely to be the only such protocol we'd ever want to support.
I don't know about that, but if we did, the current mechanism work
nicely for the example you presented.
> The strategies themselves:
>
> - eldoc-documentation-enthusiast: What's the difference compared to
> the 'default' one? Sacrificing CPU load for lower latency? It's an odd
> choice to force the user to make. The only people who can make an
> ideal decision regarding this are probably the authors of
> eldoc-documentation-functions, but it wouldn't help if
> eldoc-documentation-functions has functions coming from different
> authors, facilities, etc.
Has nothing to do with CPU. This is the way Eglot works now, or at
least tries to: there are two delayed doc-producing backends, and
neither is guaranteed to complete. One has priority over the other (and
special hooks are a decent, standard Emacs way to manage priority)
Eglot shows the lower-priority one if it shows it can survive for more
than x seconds (currently x =3D 0.3, uncustomizable). No more doc
blinking.
> - eldoc-documentation-compose: Okay, this is kinda interesting (though
> not essential),
> I think the only reasonably predictable behavior would be to truncate
> each of them to one line, always.
That's a display problem, not a composition problem For now it works OK
for one liners and also multiple multi-liners. Displaying doc is not
the main goal of these patches, there is certainly room for improvement,
as I said above.
> - eldoc-documentation-compose-eagerly: Ooh, now I think I see why
> Returning futures instead (when async is needed) would provide this
> kind of guarantee without the seeming duplication of signals.
Can't let go of that futures drum, can you? It'd be a pleasure to see
you walk the walk.
> On a related note, I believe some facilities might want to use only
> certain "kinds" of documentation functions (as indicated by the plist=20
> arguments). If the plist is only provided together with the response,
> there is no way to avoid unnecessary computations (e.g. making HTTP=20
> requests that return some other kinds of values). If the plist was
> returned together with a future value, however, it would be easy to
> do, as long as we document that the futures should start the
> computation until a callback is provided (if possible, at least).
Save it for your future futures implementation.
> And in a different high-level argument: you stated that you intend to
> have Eglot use a non-default value of eldoc-documentation-strategy.=20
OK, but this has nothing to do with Eldoc, does it? Make a bug report
for Eglot, I'll explain why it does this, and maybe I'll change it..
> Next, eldoc-print-current-symbol-info is a mess, very hard to
> follow. I am frankly offended that you argued that both ad-hoc futures
I meant no effense.
> idea). This should very well be possible to untangle in the future,
> but I'd rather not have code like this in Emacs if we can help it.
You're such an ace programmer that you code alternatives that are so
brief that they occupy no code at all!
> Further, having all strategies basically delegate to hardcoded options
> inside eldoc-print-current-symbol-info seems to confirm that the set
> of available strategies is a closed one. Which is not what I would
> expect from a variable called eldoc-documentation-strategy.
There are four strategies to choose from but you can make more. What
did you have in mind?=20=20
> These are my objections, for now. I'll have to study
> eldoc--handle-docs a bit later, but any problems it has are probably
> orthogonal to the rest of the list.
Thanks.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 03:01:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 06 23:01:32 2020 Received: from localhost ([127.0.0.1]:35232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsdrP-0001p7-Kn for submit <at> debbugs.gnu.org; Mon, 06 Jul 2020 23:01:32 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:46303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsdrM-0001ot-UD for 41531 <at> debbugs.gnu.org; Mon, 06 Jul 2020 23:01:30 -0400 Received: by mail-wr1-f52.google.com with SMTP id r12so43470406wrj.13 for <41531 <at> debbugs.gnu.org>; Mon, 06 Jul 2020 20:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/4/eMZe+wU9ly30PODQJyvOmz89mN/3C5BM16El2qzY=; b=aW7I+d+obJvoQURp+OYT6eDOIl8nJnWIO7ph9apJQudj9kSqB67NfSgWP3RHZ8Sc9s XQQKVKE6jNS7k5RM/jSEr5qxC5Hb2l7ZzPqG/kIo0htITIOp01r68l3VF8E7rL+dnU8t PMwwQgFGyX67kG/TRBBmGt03UCoWXjz+Xl7dV4Jmzuq9Xev6PVESX+AZrr79eLRe+Z5c RQPUxX6YlDiBnRwzqWIOchwIU5nKOZx0S5zaIG9wec0h6qyEIv4UxxLrEIohimdxuBfV uXE0dp8juTe6Ej5o2ODHAlwzuWRsqOmzTRpyo7Y281kMBVcSJWeU4pcdHeQyGS58hHiE GwxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/4/eMZe+wU9ly30PODQJyvOmz89mN/3C5BM16El2qzY=; b=pHmCwnRIWykar5fSKs2DH6q57HXq57WmbMx4wBOi2J8BNBPJOkcWdB1xFR6v+ibu4F /DhZDuoJGcDk7LJFq4Csj47+4A/WGU3boN2RA2dbJ35zP/kpf9jznYDEUlg0qAlCD0n+ 5qxcbP3cJkmMUNNmLrWUViD3yVRq4mJB0gVFGLmc64DUHqjxWyLFno8aO5t7gTDfcmVz Xrxrj9G4mqrH1v68SQXy1ahYEEnAr6WVSdFTk1DF+Q+7vP1KACknN2Zc4fJHbeIMvP3I LBjci+WHtNRDP3Di2vnKBZ6FWpfkSHqs5KViueBA+7H9DYFWmEzOkeJzQ8iQ5MAb2DMw elgg== X-Gm-Message-State: AOAM5309OD+0cllJ4lby/tCr94Dr7wHeN1lyjb6Vzt5Hxur2WHPvNnCj ow+z3Pm9ZadTU1RNnY+rj84= X-Google-Smtp-Source: ABdhPJwDVflGGmUrSOE9SFV8BSWZiN0M6/Az5u6KdNF5YPkZlEEer8rXIPGN751wy3MvR4xlkjeEqg== X-Received: by 2002:a5d:484b:: with SMTP id n11mr49491876wrs.320.1594090882869; Mon, 06 Jul 2020 20:01:22 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id e17sm25716592wrr.88.2020.07.06.20.01.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 20:01:21 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> Date: Tue, 7 Jul 2020 06:01:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87h7umop62.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 05.07.2020 02:07, João Távora wrote: > Dmitry Gutov <dgutov@HIDDEN> writes: > >> [that is the] "transition" I meant here. >> >> If you have other questions, please ask. I meant questions about futures as pertaining to eldoc, of course. I have other uses in mind, but redoing existing features is a less urgent endeavor. E.g., Flymake is stable, and I don't have any particular bugs in mind that need solving. So I'd be fine with keeping it as is. Unless someone wanted to take advantage of extra features that futures provide. > 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. Yes, will do. But note that when I argue for futures, it's for basically any implementation that has a container for such values, and a set of common functions for manipulating them. Christopher's version would serve that just fine (with copyright assignment signed). Which exact version to choose, however, can indeed be discussed separately. >> 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 >> 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 also wasn't a discussion really. Too one-sided. >> 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 don't make it sound as if I'm the only one here having a strong opinion about proposed code. You disregarded the simple solution in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41531#8, and then went on with your own vision of of "simple" function based async, full on with extra features and additional incompatible API changes. >> 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. It certainly did away with clients having to call eldoc-message. And if shorter code and better backward compatibility are not advantages, we might disagree hard on the meaning of the word. >> 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. Aside: given that this discussion has user interface in mind, it needs more consideration of actual user experiences we'd want to allow. Ones not provided by eldoc itself as well. For instance, I think we sooner or later should have a callsig floating popup (in the vein of MS's editors) as an alternative to showing the signature in the echo area only. > But very well then, let's > have those non-futures objections in this bug report, the sooner the > better. To be sure, they will also contain the "how we could do this better" kind of arguments. Let's start with the basics: The new API is incompatible with the previous one, it requires changing a lot of functions (though admittedly in a minor way). Which is easy to miss, as evidenced by describe-char-eldoc which still doesn't accept any arguments. Whereas we could limit ourselves to the change which would only make the clients use the different hook (or keep using the old one, for compatibility with older Flymake/Emacs versions). The choice to require a return of a non-nil value if the callback is going to be used is also kinda odd (+1 control flow to test). What's the problem with using the callback synchronously if the doc is available right away? The decision to double down on having different eldoc-documentation-strategy values seems odd to me in several respects. First of all, if I understand the main motivation behind it, it's to delegate the implementation of asynchronous primitives to Eldoc. We don't want to bother with that in Eglot, etc. But you mentioned "a type of docstring" to be returned in the discussion (and the callbacks have the plist argument as a future proofing). If the type is a buffer, its contents might as well be created from several async calls, which would require the same async primitives (though rather in general purpose form) available on the client anyway. Though it doesn't seem to be necessary for LSP in common operations, it's unlikely to be the only such protocol we'd ever want to support. The strategies themselves: - eldoc-documentation-enthusiast: What's the difference compared to the 'default' one? Sacrificing CPU load for lower latency? It's an odd choice to force the user to make. The only people who can make an ideal decision regarding this are probably the authors of eldoc-documentation-functions, but it wouldn't help if eldoc-documentation-functions has functions coming from different authors, facilities, etc. - eldoc-documentation-compose: Okay, this is kinda interesting (though not essential), and the implementation is not working as well as I'd hoped it would. It makes the echo area blink up and down as I move the cursor around. There's no expected truncation of individual docstrings when they don't fit in the window's width. And I don't understand what you expect it to do if several docstrings are multiline, and as an aggregate they don't fit the target height. I think the only reasonably predictable behavior would be to truncate each of them to one line, always. - eldoc-documentation-compose-eagerly: Ooh, now I think I see why documentation functions have to return these non-nil, non-string values. Is it that this particular strategy wouldn't have to wait too long for documentation functions that never intended to call back? Returning futures instead (when async is needed) would provide this kind of guarantee without the seeming duplication of signals. On a related note, I believe some facilities might want to use only certain "kinds" of documentation functions (as indicated by the plist arguments). If the plist is only provided together with the response, there is no way to avoid unnecessary computations (e.g. making HTTP requests that return some other kinds of values). If the plist was returned together with a future value, however, it would be easy to do, as long as we document that the futures should start the computation until a callback is provided (if possible, at least). And in a different high-level argument: you stated that you intend to have Eglot use a non-default value of eldoc-documentation-strategy. Which would basically have you use Eldoc as a library, controlling both the list of documentation functions and how they are composed. Whereas having the eldoc-documentation-strategy defcustom at all makes it seem like the user's choice, and that all Eldoc clients must be able to perform well under any strategy chosen by the user. We might want to think twice before introducing such responsibility. Next, eldoc-print-current-symbol-info is a mess, very hard to follow. I am frankly offended that you argued that both ad-hoc futures I showed, or any potential "proper" ones would make backtraces hard to read and debug, and then introduced this kind of control flow with callbacks calling dynamically generated callbacks, retrieved from a variable dynamically set in a caller function up the stack (to be clear: I think having eldoc--make-callback variable at all is a bad idea). This should very well be possible to untangle in the future, but I'd rather not have code like this in Emacs if we can help it. Further, having all strategies basically delegate to hardcoded options inside eldoc-print-current-symbol-info seems to confirm that the set of available strategies is a closed one. Which is not what I would expect from a variable called eldoc-documentation-strategy. These are my objections, for now. I'll have to study eldoc--handle-docs a bit later, but any problems it has are probably orthogonal to the rest of the list.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 00:43:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 06 20:43:28 2020 Received: from localhost ([127.0.0.1]:35152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jsbho-0006to-NU for submit <at> debbugs.gnu.org; Mon, 06 Jul 2020 20:43:28 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:33664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jsbhk-0006tY-Sj for 41531 <at> debbugs.gnu.org; Mon, 06 Jul 2020 20:43:27 -0400 Received: by mail-wm1-f51.google.com with SMTP id a6so648873wmm.0 for <41531 <at> debbugs.gnu.org>; Mon, 06 Jul 2020 17:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QqVm2ydI+m9c3MzcchMxUR6Lqgs9G6TQPGnXe0eu0mQ=; b=XvYUlrVv7clNsq1wnZp8wxJbADjr9iQvxzUAAfEt7MVL/1LtmGM4NORONW7LC7gbH0 nrIMCqqJ6gC+HrfR+P+aj/kWFgtoEK9mM62gWJiT7L7DVQe9jB6cqWYEKURrIF46KsTU aJk97XPQAziE7IgbZQ7tSK+VOfdrETcYSKuSE2bEItSzaY4oOmmY0wmsblVKRryUo8g8 I7ItEHDPvC0Mxs6m9jJBHIqCaqdteTNIesLbm+1h8ozR03Y0qPrA99P04nRb/gIxFUGi jG1yFU1MmzXnilV7qDbDr5ASmyhbsyqZGJo2/cfmYLMxYR8y4YXEx1v0d9pmAerfZH9z jttQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QqVm2ydI+m9c3MzcchMxUR6Lqgs9G6TQPGnXe0eu0mQ=; b=YrRMKqKuq5MiSsOPvxzJAumeLhcPSwqwFpxcrFsQ2hXqFcZ8S56KM/shZEjxR/tYl8 y77TWFGoFDjQJLYQHSt9qBi+ATr5Ea8782mF8n0Ur9SX5wgp+mrg3rsKtquN9EpK/UQm IQAunKd9gFj/ytTqkNwwZhB+I5bjnJxEFm0KBSFFH6RmzWkFbvXWsa5PA15fHQ0fZ3B2 8O2F+BuCUkeLtqJsSq7DmNzL2bYCFBS9Um1TNFuBc82G3jzD9T/EsS8SHIVklAWw8pzP kQXivbbP/nI6y//CteYFvyKhvr2zSr1BcMK7pX8dCR21R0nE54fxzwoNEltjnJhSLVhk GKXQ== X-Gm-Message-State: AOAM530jsnlv1v5e74pbHMDIVb9OkUSE2jYXOPaAFe8MtJxxG28ew2vt 9SqAqzLxXJQfbdNLvLyIGpE= X-Google-Smtp-Source: ABdhPJxI2rlWZrjCihmqISJIIbAvkk6s7Id2kl/F6jpv2xuztv0fFrshNY9YNkNOtkIHFS53/Y/ClA== X-Received: by 2002:a7b:c7d2:: with SMTP id z18mr1571050wmk.149.1594082598894; Mon, 06 Jul 2020 17:43:18 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id m16sm21998989wro.0.2020.07.06.17.43.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 17:43:18 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN> <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> <87d05aoowh.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN> Date: Tue, 7 Jul 2020 03:43:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87d05aoowh.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 05.07.2020 02:12, João Távora wrote: > I actually have multiple people working with me in Eglot, potentially > eager to see how things in Emacs core can be solved properly and > effectively, and being utterly disappointed by your opposition in this > eldoc.el case. That's the sad state of affairs IMO. A part of "solving things properly" is listening to feedback.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 5 Jul 2020 15:13:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 05 11:13:14 2020
Received: from localhost ([127.0.0.1]:32893 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1js6KQ-0005Rl-Cx
for submit <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:13:14 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14424)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1js6KO-0005RW-JM
for 41531 <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:13:12 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3BC48806C9;
Sun, 5 Jul 2020 11:13:07 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 939F980640;
Sun, 5 Jul 2020 11:13:05 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1593961985;
bh=d8p1k07pI8fOCj31ibI6Y5kNg/WEmPPWzrKt3LaSCq4=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=ibKriJv9pz841c8WFk/7qGyswvrXst+WSYzChURlsspRqO6TDOSn8qDnOtpgKMrj4
/L/VRnY9X+vc3iFZpvv3sBa7IoheTkhxf9mRfrs1gGWmMmhhOMxhtmLhnqkRhFNDBi
Cwi0KUQ+9JmGRIf0CxmQAToI59gSg5tQtnM06vRzPKNq0UBs0AEWWGJ1QVUZBYoIkH
EIETambOGaSJRheMEfe9zhMXTb5bkPpdV2t1izXfW/R+sOjnysGZxiB0lM6GD18VJP
2LGPc2yar8Qs2OeAHstRiHMzhSKWDUtnSWhIj6CIS9CVRRjouewum1Cx9U1rVdy7g3
hdNJUqJdHbn/g==
Received: from alfajor (unknown [157.52.0.200])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 18933120264;
Sun, 5 Jul 2020 11:13:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwv3666ov1m.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<83k0zjvi4c.fsf@HIDDEN> <87o8oui2xn.fsf@HIDDEN>
Date: Sun, 05 Jul 2020 11:13:04 -0400
In-Reply-To: <87o8oui2xn.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Sun, 05
Jul 2020 13:03:48 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.024 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, andreyk.mad@HIDDEN,
dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> -(defun eldoc-message (&optional string)
>>> +(make-obsolete
>>> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0")
>>
>> Isn't the version part of the obsolete message supposed to tell the
>> version of Emacs?
>
> Stuck with "1.1.0", because of the GNU ELPA criterion. But maybe the
> string could be "1.1.0-elpa" or something like that.
I recommend "eldoc-1.1.0" to clarify which version number we're talking about.
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 5 Jul 2020 15:09:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 05 11:09:15 2020 Received: from localhost ([127.0.0.1]:32882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1js6GZ-0005LT-I1 for submit <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:09:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1js6GV-0005LD-Qq for 41531 <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:09:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33768) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1js6GP-0005Q9-Lj; Sun, 05 Jul 2020 11:09:05 -0400 Received: from [176.228.60.248] (port=3862 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1js6GP-0002DO-4t; Sun, 05 Jul 2020 11:09:05 -0400 Date: Sun, 05 Jul 2020 18:09:08 +0300 Message-Id: <837dvit2wb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <87o8oui2xn.fsf@HIDDEN> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sun, 05 Jul 2020 13:03:48 +0100) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <87o8oui2xn.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, > andreyk.mad@HIDDEN, dgutov@HIDDEN > Date: Sun, 05 Jul 2020 13:03:48 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> -(defun eldoc-message (&optional string) > >> +(make-obsolete > >> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0") > > > > Isn't the version part of the obsolete message supposed to tell the > > version of Emacs? > > Stuck with "1.1.0", because of the GNU ELPA criterion. But maybe the > string could be "1.1.0-elpa" or something like that. AFAIK, the obsolescence message we display says "since N.M.X", and the intent is always to an Emacs version, right? How can the user understand that in this case you are talking about the version of some other package? > > The doc strings have some words in UK English spelling "(e.g., > > "honour"), please fix that. Also, please make sure comments all start > > with a capital letter, end with a period, and comprise full English > > sentences. > > I fixed all I could find, but is this a a hard rule? I like to break it > once in a while: > > ;; We have to foo bar separately ... > (foo bar) > ;; ... because the bazness might be too quuxy. > (if (quux) (foo baz)) This is fine.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 5 Jul 2020 12:04:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 05 08:04:01 2020
Received: from localhost ([127.0.0.1]:60167 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1js3NI-0000tE-QE
for submit <at> debbugs.gnu.org; Sun, 05 Jul 2020 08:04:01 -0400
Received: from mail-wr1-f66.google.com ([209.85.221.66]:36801)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1js3NF-0000sy-S2
for 41531 <at> debbugs.gnu.org; Sun, 05 Jul 2020 08:03:59 -0400
Received: by mail-wr1-f66.google.com with SMTP id k6so37783141wrn.3
for <41531 <at> debbugs.gnu.org>; Sun, 05 Jul 2020 05:03:57 -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=N+iaL/HybVXXg6rGMlteyVqNVTIbraO6UWN+cjt00R4=;
b=mNEEL5T2yv9VBbuIV//fLz3ykYkbF/SZGepqH8L2SxL0cGraf+EZGq2DcfD4vvVONZ
CzOseNW8PMXBI30wJhcvYLpTPzNqdx0YILTEL+H94OKQ9lFTpMbEfa5R77Ga2VuSngrl
2uYO3vdFr/F8l3uOve6j/DeRS4ynhpAZeNHH4YWs66oVVJZULm181wKFkAfNXOcuuSkK
JzbvsSmkk1ZQ5vY5NXkRTsgiR4cWz+8utgqfRyoJWd68HRqVv5ymSvvGrorgk8K9MDL0
M8ixiVIJSciWcpLAoqQWy/sAlTulOVnBaIs8A5eeNmTGLrutDWDxDDhJMDXpSbxWIGv7
c6tA==
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=N+iaL/HybVXXg6rGMlteyVqNVTIbraO6UWN+cjt00R4=;
b=Hw5qoxD3VuMTj23DMMK7MjT+ooUADej8pGG+SODS/ouPAyMOgHIfD915hPySlqdOv5
xXXx/FpPLNU4/HTlgapPXlVl966oB9HkytwMLJYR7RaCK3jiJ8c1pxPtpYdoPSt69AC3
U5/rKNDljBOnN+0lolPvGZ9+NNUXPuVuf5URz9vxoRfZH9iq8Oo/qUnex0V2tbWtuHww
O5hN0ZCPk3Ka8uWqVYngIxFPVIRmqNMsRaqI7IZ0IsscCPhbJf2gEpd2x9FJ3ThjqVIO
M/APb1u1Xgtoj7zGv7QIvylChSvRXyY8j3BXdzf4t2AvvVkbcRGjSOepPoV4NOuu/EQO
Sucw==
X-Gm-Message-State: AOAM530biVllWCsDr7QCPSzBt1cfKXOs681Ror/Arjwj/XJpeAR8u/vt
5vNFNn4xT3V6cL7i3NQyuyE=
X-Google-Smtp-Source: ABdhPJz5z18M734ZWllWD4h/l6CJ2IrD4RdfcHNTB7CN67yaFiG/zTkPXuWQ+eOGK/g9ynzqw8xGqg==
X-Received: by 2002:adf:e60a:: with SMTP id p10mr42289122wrm.181.1593950631904;
Sun, 05 Jul 2020 05:03:51 -0700 (PDT)
Received: from krug (89-180-156-25.net.novis.pt. [89.180.156.25])
by smtp.gmail.com with ESMTPSA id z1sm20049371wru.30.2020.07.05.05.03.50
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 05 Jul 2020 05:03:50 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<83k0zjvi4c.fsf@HIDDEN>
Date: Sun, 05 Jul 2020 13:03:48 +0100
In-Reply-To: <83k0zjvi4c.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jul
2020 10:45:07 +0300")
Message-ID: <87o8oui2xn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN,
dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> -(defun eldoc-message (&optional string)
>> +(make-obsolete
>> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0")
>
> Isn't the version part of the obsolete message supposed to tell the
> version of Emacs?
Stuck with "1.1.0", because of the GNU ELPA criterion. But maybe the
string could be "1.1.0-elpa" or something like that.
> The change to the number of arguments of the functions in the
> eldoc-documentation-functions hook is backward-incompatible, isn't it?
> I see you've changed the relevant functions in our sources, but what
> about 3rd-party packages?
Answered this already.
> Also, the doc string of this hook needs clarification regarding the
> arguments: it first says that CALLBACK is the only mandatory argument
> to the hook functions, but then, out of the blue, appear additional
> arguments DOCSTRING and a list of key-value pairs. Confusing.
Changed that paragraph to
To call the CALLBACK function, the hook function must pass it an
obligatory argument DOCSTRING, a string containing the
documentation, followed by an optional list of keyword-value
pairs of the form (:KEY VALUE :KEY2 VALUE2...). KEY can be:
The situation is very similar to Flymake's flymake-diagnostic-functions.
If you still find this docstring confusing, maybe I should copy that
docstring's structure.
> The doc strings have some words in UK English spelling "(e.g.,
> "honour"), please fix that. Also, please make sure comments all start
> with a capital letter, end with a period, and comprise full English
> sentences.
I fixed all I could find, but is this a a hard rule? I like to break it
once in a while:
;; We have to foo bar separately ...
(foo bar)
;; ... because the bazness might be too quuxy.
(if (quux) (foo baz))
I ended up not doing that this time, though.
> The doc string of eldoc-documentation-compose doesn't say a word about
> the function's argument.
I fixed that by creating a helper eldoc--documentation-compose-1 that
both eldoc-documentation-compose and eldoc-documentation-compose-eagerly
call. I describe the arg in the helper.
> This doc string doesn't explain the use of the timer, it explains the
> reason for its existence. It should also describe the use:
See the new version below. I think it is sufficient. Be aware this is
an internal variable, we don't even let the user customize the time (we
could though, but I think it's overcomplicating, for now).
(defvar eldoc--enthusiasm-curbing-timer nil
"Timer used by the `eldoc-documentation-enthusiast' strategy.
When a doc string is encountered, it must endure a certain amount
of time unchallenged until it is displayed to the user. This
prevents blinking if a lower priority docstring comes in shortly
before a higher priority one.")
> Last, but not least: the "async" part of the branch's name hints on
> some advanced and extremely useful functionality that these changes
> are supposed to allow, but I see no mention of that in NEWS and in the
> manual bits. What did I miss?
I reworded it, caught a bug, and mentioned
eldoc-echo-area-use-multiline-p. Let me know it if you're missing
anything.
Jo=C3=A3o
PS: Actually a proper section for Eldoc in the Emacs manual is probably
missing, but I don't have time to work on it straight away. Or at least
I think the fix should go in first.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 23:12:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 19:12:57 2020 Received: from localhost ([127.0.0.1]:59820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrrL7-0003B0-94 for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:12:57 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:40214) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jrrL3-0003Al-UE for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:12:56 -0400 Received: by mail-wm1-f67.google.com with SMTP id f139so37887925wmf.5 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 16:12:53 -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=nSERJ/0ipU+OAZKibo4XfuxaTijFZp30rP8PyOSouxw=; b=UdIwH1Bp2jmg4zcIO2/NZqWFWGVXXDXALIP2aMiNg6ICFV2BP2MGmQ4MfyyOuO9CqW BwH08Tc3t4v7CpfZEtWLTwlH5IkklrsHWXDyhh8F2GpnumGDv8ZG7/KL3sg/+6uHhZ9g XTjdFb5FZkiN0UswpPq1AbfYEWCOo7razd6xG1TQZtgbRtHToTiR1By05o9owHDBI+Z0 IVTYQhWHJIz3H2lnkea7gvmS3s59rKMSBMafIa85Nyp8hMm/E9XBJgW+e91FLe6q0GZ4 /LzUjaTV+7PSJR1sNgU4k7QpdOciuNtqsvU8NXX4kIu+HnNiVqKAZxzE4I6dx6r8gKAZ CBgA== 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=nSERJ/0ipU+OAZKibo4XfuxaTijFZp30rP8PyOSouxw=; b=WUvNd6t2Npf4oHpZAmamCOOxglwbsX0qgbLvg7lYx2N06Px3hI8h08K0/friskqTCn zYqBBWRE9ESgu0TH/Y6YGOT1dCyFQAI5s8FOetfdkPbOjp3zUUIeEXBv5yI85ER9LWGN QzZrhAVlWjQLx35xfxLAUMstJnnN5N0/3X/Xu9pzZZqLDx+H2+NoCHKQZkLI95OVZ8ZQ oqrwueSAcRSTMgQOJxU8jgrFjBRYdx5GjhNHEEd997m66sNdJhX68mxlLjExkRnq5gbC GPTpvsnxPT0g9AsPD3e8pY7yBrFvhmaE+4TXEEm2RyevPQRlL+uTZEP1cIWrk1HHKf+t J8Ug== X-Gm-Message-State: AOAM530uxzibdlAUIkyDxkokKBi6oGdzS+DIhinEcAf/d0Ew9Y9jXjvY sCZazPU02UQpQyLbtTC/yPk= X-Google-Smtp-Source: ABdhPJxjJGXzGEntnrnict1WeHLvPyFMPiUIowSPNa3LBuMjvrAUUEqSdGRGFjKYbqibn/kG3CA9OQ== X-Received: by 2002:a1c:9c0c:: with SMTP id f12mr1085463wme.179.1593904368203; Sat, 04 Jul 2020 16:12:48 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id e17sm17741691wrr.88.2020.07.04.16.12.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jul 2020 16:12:47 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN> <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> Date: Sun, 05 Jul 2020 00:12:46 +0100 In-Reply-To: <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> (Dmitry Gutov's message of "Sun, 5 Jul 2020 00:06:18 +0300") Message-ID: <87d05aoowh.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 04.07.2020 14:00, Jo=C3=A3o T=C3=A1vora wrote: >> I had intended to streamline >> that release together with these async-related developments, but reality >> (and mostly Dmitry:-) intervened. > > To be fair to yours truly, though, AFAIK we are the only two people in > this discussion who maintain third-party eldoc clients, or work on=20 > integrated development experience in general. > > That's a pretty sad state of affairs, BTW. I actually have multiple people working with me in Eglot, potentially eager to see how things in Emacs core can be solved properly and effectively, and being utterly disappointed by your opposition in this eldoc.el case. That's the sad state of affairs IMO. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 23:07:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 19:07:14 2020 Received: from localhost ([127.0.0.1]:59812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrrFa-000331-6X for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:07:14 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:40673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jrrFX-00032g-Hf for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:07:13 -0400 Received: by mail-wm1-f41.google.com with SMTP id f139so37881995wmf.5 for <41531 <at> 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) 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) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> Date: Sun, 05 Jul 2020 00:07:01 +0100 In-Reply-To: <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> (Dmitry Gutov's message of "Sun, 5 Jul 2020 00:27:20 +0300") Message-ID: <87h7umop62.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, eliz@HIDDEN, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 21:30:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 17:30:33 2020
Received: from localhost ([127.0.0.1]:59763 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jrpk1-0000cL-Kb
for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:30:33 -0400
Received: from mail-wm1-f54.google.com ([209.85.128.54]:35773)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1jrpjz-0000c7-R7
for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:30:32 -0400
Received: by mail-wm1-f54.google.com with SMTP id l2so36247669wmf.0
for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 14:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:subject:from:to:cc:references:message-id:date:user-agent
:mime-version:in-reply-to:content-language:content-transfer-encoding;
bh=kTNAKs7qMsA+MHfa27Hog5lQtvA4JoCkaJGHkMl52Uc=;
b=PI/ht1tqWt/vKCKdZiGd5LrQ1vWdmsQ3llnpHZy6tAkvyH0j7BzYnRo6iKePJwEBBx
1KKVefAVhDuhtoLg9eBEyj/vP5DIQdg1AUBKkFf5djenXZg0aqX0nGPKoisgadHHQ4SH
sEiqjeZbgEgeRWatCDbfLHk/3BaY8lac9spfYRjHig1SVah2QG/eK560lziJmpNHKcKo
tq/5nN6029PC6Gp0PgJoxeXSbI3FQeeiVVgCOykUZJBw4aWrSb0YzIWPzxA/u0AODedF
CyJ7DmyjsAkyBsj1Z2kBR73bp1jjfVJM1ni3eIk8SLnktFIei1nPV9S69JVBsf33oyZy
SFMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:subject:from:to:cc:references:message-id
:date:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=kTNAKs7qMsA+MHfa27Hog5lQtvA4JoCkaJGHkMl52Uc=;
b=VgfYRDL2PEoEAUUVmxDdciq3BYJEONoQ8QoTldY4yNxluiw5VF4elWyOJiBl6KY4MP
H+E2MQ1QjE3GE70O5Sw209UznveNJ8f5WzaruYx/mOv2gSzmlBDFw0VXN6DekBF67/vZ
F2FLK/snSpsrvmedVBjIEdmpB764KTPkA0LgtoVq1+MP8z6G482/kTrdXNESuhfq5GEV
/wCfruPVBY4TzfhjvD0FDmUg4Lh4E2mJDEothD6QSl74g7KUV8bKpfAHPEyJ/jVhdvjY
UaCHzQR/eLO1tDYH5q69zZRsGR7o0yDCzwVc9Rhxjzf/bdNv47bUUCeatmCQtbDQ8Flh
TvtQ==
X-Gm-Message-State: AOAM532F9hf3UJSccOySpnf6EiwRdCvXvHxBf2jZWvowg9rRYSmA3SmC
+BKy1CAh1pFXO793hUfEJpY=
X-Google-Smtp-Source: ABdhPJy7gEGBpH/kVBB2mp9UKuxFqLGdxsqFHgGxT+0lhaLVbc21/Yfh6+PfXtIrAC6w+fLtuH4jMg==
X-Received: by 2002:a1c:acc3:: with SMTP id v186mr44580000wme.79.1593898226040;
Sat, 04 Jul 2020 14:30:26 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
by smtp.googlemail.com with ESMTPSA id y6sm18234015wmy.0.2020.07.04.14.30.24
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 04 Jul 2020 14:30:25 -0700 (PDT)
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
From: Dmitry Gutov <dgutov@HIDDEN>
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
<ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
<5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
Message-ID: <7c4cef6f-6aca-80ff-7633-728031442855@HIDDEN>
Date: Sun, 5 Jul 2020 00:30:22 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)
Sorry,
On 05.07.2020 00:27, Dmitry Gutov wrote:
>> 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
^ But
> experience, this will result in a much longer, protracted discussion, if
^ [moving it to emacs-devel]
> it will result in one at all.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 21:27:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 17:27:30 2020 Received: from localhost ([127.0.0.1]:59759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrph4-0000WR-1y for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:27:30 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:46861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jrph2-0000WF-SO for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:27:29 -0400 Received: by mail-wr1-f46.google.com with SMTP id r12so36457683wrj.13 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 14:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8fGAzBO7qxQEvrHhytcXR47y8aU1Fqh8ePC6ZJC+9+M=; b=QwF4K5QtcK6qgG+Vd6iFWtZyXas4uhDS10NQGPEPvl/TubbRNapWdyZygi/Hiikgxy gR2j6H/oeT+J9E6qDSZzONW8JOxd44IwkmRMMk/Wi5mc/HoXqT2RQdY1jAzCKKj7OcAF kaGcr4QDwnjTstpSTXwc8Jax6WNPrMG8saKU/5FCZDF2kgTdtY/ZY52J8uOfRnbUdumd I271rDSFBWGAedF5vWmmf+uYqKNRNL5WsxAQETg+NHoN5Jj4CSK9TmG9+n4YysMk3NKV GdiIcSYK+70yUmzsYvzmTQJ6qhwtqh6uJJIXLOdpgFczQE+9MWbUW6MxmTTGo+GoviGI uaXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8fGAzBO7qxQEvrHhytcXR47y8aU1Fqh8ePC6ZJC+9+M=; b=pMdWyp5NCUT82UXZ4WGmNKYOw1Oy5HSQeOL34XfHYg2ZKgLbgvu+7JgHyFBJwFU0bR 3+Iiu0wSpOIiRGfU0WFIm9MIlBbm4vtwGEPVwQCJvGVXy8PW4CvGy6Zn1c9wskYYLj7x O07mL9JvW5OoQ6XUnBCyG35SPJ97UettZKo0tXtsA32DrTPsxPw+5J12DPaIx5uFGNVw sB7wF/jJOyE05QZeTXSZSlhfI60MtGhgT1eawGOENptks0+lbozGBU4rO0GYHD2AyF8g nCsdDSYJeX6cRZsfs4ZusftQAFdoXNE0zxqzsxzVNo5zCaEKKronTHUsQ/96Yk8acZ+r 5M6g== X-Gm-Message-State: AOAM5307XaAClbNK/C7JpD2lxQaXQyEInCMbfpPA/NlJE4N7uJFKkbrg /XLOzKtJe2bTmiljHIodKus= X-Google-Smtp-Source: ABdhPJw7lssnIMg52lV03lLvFUJ+P4OLvrhjsJu9PqQthjlfEUlhR+QX0dHv2h5u38rfapE3lPMoeA== X-Received: by 2002:adf:81c7:: with SMTP id 65mr40206857wra.47.1593898042900; Sat, 04 Jul 2020 14:27:22 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a15sm20882146wrh.54.2020.07.04.14.27.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jul 2020 14:27:22 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> Date: Sun, 5 Jul 2020 00:27:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87tuynsdp6.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 04.07.2020 14:48, João Távora wrote: >> Unsurprisingly, I object to this approach. We should have better async >> support in multiple Emacs facilities, and that means standardizing on >> some particular async primitives and functions that can manipulate >> them. There is no need to release support for ad-hoc async values (you >> didn't like mine, so it's only fair play that I object to yours) when >> we can transition to full futures right away. > > I haven't seen a consistent plan "for transitioning to futures". Do you want to see the patch based on your code? It's the only "transition" I meant here. If you have other questions, please ask. > All > I've seen is (complicated, IMO) ideas on how to avoid the > callback-calling style by hiding the callback in an object. Hiding is absolutely not the point. > I've seen > little argument or discussion of what futures are supposed to do or fix > or improve. 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 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. > 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. > Despite that, I've stated here repeatedly, tiringly: In principle, I > don't object to futures at all. I just think it has to be a > thought-through change. Propose your library to emacs-devel and let's > iterate it there. If you think emacs-devel will bring more feedback, no problem. >> I'll get into a little more detail in the more full review, tonight or >> tomorrow, but for now my impression is that, in the absence of such >> standard library and async manipulation functions, you decided to >> implement them specially in Eldoc. > > Of course, and that's what engineering is about. For the most trivial > of changes X there is _always_ a refactoring R that will make > implementing X and a possible Y and Z much simpler, more elegant, more > "meta". Knowing where to stop is what this game is about. In this > case, there is only a vision what Y and Z might be, and a foggier vision > of how bad/good design decisions in R might affect them. The thing about refactoring, is it doesn't change observable behavior. Refactoring would keep the stable interface (and e.g. reuse future-based utility functions under the covers). Whereas the improvement I would like to see here, would change it. So it's not something that could be simply moved to backlog. And as I intent to explain later, I believe you will need future-manipulating functions inside eldoc client code anyway, for best user experience. So we might as well bite the bullet and introduce futures at the API level. > So I fixed the real, actual problem in Eldoc using the async paradigm > that is widely used in Emacs and most widely understood by programmers > of all (most?) trades: callbacks. Please recall how you rejected my proposal along the same lines. And it's fine. We can do better. > 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 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. > It's quite a > 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.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 21:07:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 17:07:08 2020 Received: from localhost ([127.0.0.1]:59754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrpNM-0008VR-8Q for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:07:08 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:40575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jrpNK-0008Uw-Jt for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:07:07 -0400 Received: by mail-wr1-f41.google.com with SMTP id f2so8486048wrp.7 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 14:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rRsUflcTBcHQnpwwNiYHQ6phZcNGgoGpWp5L77Xlzw0=; b=Ke9kgBOfid8BiTlX9qFNYNjgAYFiP1b89LOtvlSbF0h7epkQSrAR/Sk3iU9kECZRpo PcaYGwZC02mZvzIZb2Tdyz9yQhNB91JFYQSBDM2ogyP9KtdhADOm3WLK3zF0HSZl7fdv bPrNCfDTtbl7pqHkOW3tmsWFOCUoKIDVdrYPNDjdSjzEnpGJ7ix/rHqHxSwXuFe6iDnS l28gJvZR9r6fJTW18mULlOyrXKBMInQqonmT9W3WwwfP9HT4rKLnr4JL0kr0eHSOgvdy SJB4DR5b7ANZ2HKgdHog4+UMWwkTqpmBMXWtxFz+L84wcLaAYF4Kmmep1NTnHmTUztMi 0Frw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rRsUflcTBcHQnpwwNiYHQ6phZcNGgoGpWp5L77Xlzw0=; b=Yfp7zpJKIFTjLFWH0GYEx84HTDKBQ2C8o+Yp0vvsY55wfZEplJQkZ/bMvgUUNsa+2c 12A9jeAfENWyI8GcWdoxYswNsfMrO600EYsDbugeFlO6aTkl2qxvtseABLOV5UkfOrzf 7wiIv12WEw1Qx6+TptSGS4Ogm+FZmMlXgVkZJ6uKB6pA48RO5uoWFG1D5m9v4J2CAL31 5Lp71HGZTSNKnuo9a3RXtjsYL51SN0OufXnsitvALqemll8OcWPGMUV9t49HNDgYlhrI QuSZGGCqGEqkUc2rCmCVXWb9SBYPC4x3RRtQdUsVv4phPURxJYv/7ziFg3PTts3DnUBk r/cg== X-Gm-Message-State: AOAM532nE8xGs2xPP36lbioXjhIhqQX0EsqtEBg2E35jKICCGO8T2XWk 1B7E32YlbDfcD6Toh6ivLes= X-Google-Smtp-Source: ABdhPJwJ9eRyc3MfJkRVNuYY/RqoR++ZeIp8eHMD1k3JWBU1wwMVHWdzG8BAM/lwzMTcHtJxEMgqhQ== X-Received: by 2002:adf:b6a4:: with SMTP id j36mr42744125wre.260.1593896782578; Sat, 04 Jul 2020 14:06:22 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d10sm18330967wrx.66.2020.07.04.14.06.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jul 2020 14:06:21 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> Date: Sun, 5 Jul 2020 00:06:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87zh8fsfx2.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 04.07.2020 14:00, João Távora wrote: > I had intended to streamline > that release together with these async-related developments, but reality > (and mostly Dmitry:-) intervened. To be fair to yours truly, though, AFAIK we are the only two people in this discussion who maintain third-party eldoc clients, or work on integrated development experience in general. That's a pretty sad state of affairs, BTW.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 11:49:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 07:49:05 2020 Received: from localhost ([127.0.0.1]:58160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrgfJ-0000dr-A6 for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:49:05 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:40190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jrgfH-0000dM-AY for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:49:04 -0400 Received: by mail-wm1-f45.google.com with SMTP id f139so36675333wmf.5 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 04:49:03 -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=HY+Ka0K/9oo7jlQ0lX0xDowSmPxgNq9vAHBAOUDhzas=; b=fYdty+nmE1OSSjAsxDwpIpGDAoDnTLzmB4uUTaM3c4D1WLWSonqKFUt55Nl5q7/EpE G7dfkw/In4dONm5DQsaLnh/0iBJMIiKat9574EBm6JvMdGFo5MC3ZGN0bYekLKVeHy1G cbBtUIWHI5gbsrLK4dOTpaUCxjEZNlG0QhqQiGK661Qvmf9SrsdoGV6RuxlqLFmM87No T4tw4RSsMBZ9+KATCdnKlWdoYqouflLMNUMCFn1ikv9Dq9oG50TyvEeqPqxhswnon1v3 QeqIWEk5pbUgW+rb8K4PFAFyjAw+2grSqxHIglwVofOldb9djZ8AqaDPUQ1hdyLvPfpZ 8xag== 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=HY+Ka0K/9oo7jlQ0lX0xDowSmPxgNq9vAHBAOUDhzas=; b=i7ngNDd23elQ8/qQEWNVisYYh4M1g8zgd7oWCSsn7DteoY++bD4bXfrFgH4x3F+cqz te8pqmInJzSd/0f7jCBLxcsW1sX8MgzR9QxkK/5NoNoU4a9/xXXKMe7WvcSYEsjN53wm fKScIRi/olVWK/l3kDmOmtW+x0dfTOo7qx2smhK/Y4c6vMqzIFjqis7vZojcDgHxoJps 1kfzr9bG5xdo7SjqVWnHXWxbR8xHKv7vF4r5rb9Pkkv1aXn/SJV6tac/FXUvvUXxN44i Tf811XSjlqmdp/rxJEJHLBgqhFpqLZH+E04bfZiRAO4uqOZHZv3tbAEwDOiYmZpIe5pP 5BjA== X-Gm-Message-State: AOAM533nVQghQrxirObRN8BuUXYqzrL9SA+Oa8YVQrQtcTojHlJMQwxd pQJ0Go+83Q7DNX16Y2qBIso= X-Google-Smtp-Source: ABdhPJybLYR3yvLkV12Qg5Va0/ph15fdfmOmfxTd1eJKHjSJLj3r9AfshzOQ54e1Jjt9eOa0LxJgAA== X-Received: by 2002:a1c:1fd1:: with SMTP id f200mr39651955wmf.162.1593863337254; Sat, 04 Jul 2020 04:48:57 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id z16sm16709966wrr.35.2020.07.04.04.48.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jul 2020 04:48:54 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> Date: Sat, 04 Jul 2020 12:48:53 +0100 In-Reply-To: <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> (Dmitry Gutov's message of "Sat, 4 Jul 2020 13:04:35 +0300") Message-ID: <87tuynsdp6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 30.06.2020 14:31, Jo=C3=A3o T=C3=A1vora wrote: >> Dmitry has expressed his intent to make the new eldoc.el work with a new >> futures/promises library. He prototyped one of those libraries. I have >> nothing against that in the future. However, >> 1. I don't have the resources to make the eldoc.el prototype work >> with >> Dmitry's or other libraries; >> 2. We should revisit the purpose and the details of that and other >> libraries in a separate discussion. For now it's high time we >> advance the Eldoc libray;. > > Unsurprisingly, I object to this approach. We should have better async > support in multiple Emacs facilities, and that means standardizing on=20 > some particular async primitives and functions that can manipulate > them. There is no need to release support for ad-hoc async values (you > didn't like mine, so it's only fair play that I object to yours) when > we can transition to full futures right away. I haven't seen a consistent plan "for transitioning to futures". All I've seen is (complicated, IMO) ideas on how to avoid the callback-calling style by hiding the callback in an object. I've seen little argument or discussion of what futures are supposed to do or fix or improve. 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). Despite that, I've stated here repeatedly, tiringly: In principle, I don't object to futures at all. I just think it has to be a thought-through change. Propose your library to emacs-devel and let's iterate it there. > I'll get into a little more detail in the more full review, tonight or > tomorrow, but for now my impression is that, in the absence of such=20 > standard library and async manipulation functions, you decided to > implement them specially in Eldoc. Of course, and that's what engineering is about. For the most trivial of changes X there is _always_ a refactoring R that will make implementing X and a possible Y and Z much simpler, more elegant, more "meta". Knowing where to stop is what this game is about. In this case, there is only a vision what Y and Z might be, and a foggier vision of how bad/good design decisions in R might affect them. So I fixed the real, actual problem in Eldoc using the async paradigm that is widely used in Emacs and most widely understood by programmers of all (most?) trades: callbacks. 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. It's quite a legitimate inclination, of course, it musn't be needlessly put it in the way of other's work. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 11:01:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 07:01:11 2020 Received: from localhost ([127.0.0.1]:58145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrfuw-0005mk-BC for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:01:11 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:52438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jrfut-0005mL-8x for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:01:08 -0400 Received: by mail-wm1-f51.google.com with SMTP id q15so34296552wmj.2 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 04:01:07 -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=U3jKGvVmvC7vW5tZ6ATbgPWsl1l0Ym+M8Adx0n2gwtM=; b=a8w0HHzthl0KBxDztsqb26qWqRTw9LSympDtrr/UoAvyXgisqYUCrnrO1cV5x5+wUy z1Mk86nUPEQLhGM9ksLWvFPb6cTnxRTMPKtZSveNc30T+daWqxfrZ/58TeJHoIUZiKgX SynvRhUqRo7Qvy2FAW0ti/5sAJ6u5nbmsvoxSzPYgY1LJpAwWpWJcM6dF/FwlUT+5jtR Vl5vt7ro1x4Sa1ZORGympJs3e1hKyx3T1it6PKoopu+6DhI8uX4OfCGCzG38OJMcqdVG DzCStgS98ZEuw8KPXa3wSo9Y7d8E7xHS5ZxDEphFllyuuQSIB8PkYnI9eiaxbLi5TWi5 LgcQ== 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=U3jKGvVmvC7vW5tZ6ATbgPWsl1l0Ym+M8Adx0n2gwtM=; b=fDaC39usPtCY05SRUbBbwYSBHXCWuPwKG3r2BpIZb7BCUr17DjCPkeRpaHMBZPkcaQ /MWZOUB5lADHR0lv/hyhNx5vP1vAQ6VJstipKXXBzrvH53XPw8apNlpWWYMqLf1ksq0u Qw2mv8IDinkRlw6PCWW9LnH5ZMN4lPnQeAXOGqu0vOn7Vje6c7EDndNHE9zHJonzxB51 pbpAtWY64ug/h9pq9tjCwU06qetfocTSgi+qW2BaOF69lXBGdbVr9VQDSprUkU7ehyXK rqG2xwYpxXc5y3QQuDy6ZpKfjHZ+ayQJ5ERuwd/MltiN0DwOd350H7XSVX4IOah8oj/P MXoA== X-Gm-Message-State: AOAM5318BVwtfhjc6EmTiwWaSS0jEZwA8EAmB8Khqiir9l1uPPic0lWM 9FZ7IvuVEQXJbd5zJbdw+bk= X-Google-Smtp-Source: ABdhPJxpwLDg2TPW7LnFRPoHM1Mf5aSUhP68r8FgO9YCZX5ecE9QDseclYgKJfwEJCI/RR6HbWAnJw== X-Received: by 2002:a7b:c18f:: with SMTP id y15mr41408824wmi.85.1593860461240; Sat, 04 Jul 2020 04:01:01 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id k185sm16389237wmk.47.2020.07.04.04.00.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jul 2020 04:01:00 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> Date: Sat, 04 Jul 2020 12:00:57 +0100 In-Reply-To: <83k0zjvi4c.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jul 2020 10:45:07 +0300") Message-ID: <87zh8fsfx2.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Anyway I think my efforts are ready to push to master. I'll do so soon >> unless someone raises a serious problem about it. > > Not a serious problem, but some comments: > >> -(defun eldoc-message (&optional string) >> +(make-obsolete >> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0") > > Isn't the version part of the obsolete message supposed to tell the > version of Emacs? Yes, but eldoc.el is its own versioned piece of software now, because it is a GNU Elpa :core package. So I opted to use that versioning instead. Maybe I shouldn't have? Don't know if there's prior art for this situation, but I'm reasonably confident I personally have taken this decision before. > The change to the number of arguments of the functions in the > eldoc-documentation-functions hook is backward-incompatible, isn't it? > I see you've changed the relevant functions in our sources, but what > about 3rd-party packages? I've checked and there were none. The eldoc-documentation-functions variable came to be in Emacs master: it's not in Emacs 27. I myself "released" eldoc.el to GNU Elpa almost 2 months ago (see 9ebf51999ce58cccc2a228fd07a18c7b472dd3fd). I had intended to streamline that release together with these async-related developments, but reality (and mostly Dmitry :-) intervened. So indeed there is the danger that, in the intervening 2 months, some 3rd party package depending on GNU Elpa's Eldoc, started using the argless eldoc-documentation-functions, and will be surprised by this backwards-incompatible change. However, I think the changes of that are unlikely. I searched Github and Google for such references and couldn't find any. So I think it's safe. (But even if it weren't, I'd still argue for the change + fallout ). > Also, the doc string of this hook needs clarification regarding the > arguments: it first says that CALLBACK is the only mandatory argument > to the hook functions, but then, out of the blue, appear additional > arguments DOCSTRING and a list of key-value pairs. Confusing. Understood. > The doc strings have some words in UK English spelling "(e.g., > "honour"), please fix that. Also, please make sure comments all start > with a capital letter, end with a period, and comprise full English > sentences. OK. > The doc string of eldoc-documentation-compose doesn't say a word about > the function's argument. That function isn't meant to be called by users, and the EAGERLYP is a code-saving trick. But of course I should document it. > In the doc string of eldoc-documentation-strategy, you use the phrase > "queries the special hook for all functions that produce doc strings" > to mean, AFAIU, that the specified functions in the hook-variable list > are called. IMO, this wording could be confusing; suggest to use this > instead: > > `eldoc-documentation-compose': calls all the functions in the hook, > and displays all of the resulting doc strings ... This of course, assumes that people know that "functions in the hook" aren't like "functions in a list". The symbol `t` may be in "in the hook". But it's better for practical purposed, I admit. Because "result" is often conflated with "return value", and that's only _one_ of the ways the functions can produce doc strings, I'd modify that to: `eldoc-documentation-compose': calls all the functions in the hook, and displays the doc strings that they produce... > > This doc string doesn't explain the use of the timer, it explains the > reason for its existence. It should also describe the use: > >> +(defvar eldoc--enthusiasm-curbing-timer nil >> + "Timer used by `eldoc-documentation-enthusiast' to avoid >blinking.") OK. > Last, but not least: the "async" part of the branch's name hints on > some advanced and extremely useful functionality that these changes > are supposed to allow, but I see no mention of that in NEWS and in the > manual bits. What did I miss? Not much, we talked about this. Will change NEWS according to what we discussed. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 10:04:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 06:04:49 2020 Received: from localhost ([127.0.0.1]:58087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrf2O-0004HO-PT for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 06:04:48 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:34171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jrf2L-0004HA-Lk for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 06:04:46 -0400 Received: by mail-wm1-f41.google.com with SMTP id g10so12360449wmc.1 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 03:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VwXM7qoUhqf+HEwuUmgUlTsVIN30W8k0bdpZKi4QzKs=; b=RtyCgyys45QhpoUJYZ7ddJqlVayFuLHTj5NxPJ4ikwBh3G+ghow+QTo9ixZb+rC1jU c1SwCnp7JA9rE/zCIqqhETN6gxbjhF/nQd1LNUafC0koQt/+Lc+pOHv0kYEHlpXZ8isH Q0F+VpcQZb3u1o93Dyd5kbrs9RjYUzTQtCXQr3qyNOyzYSTEgs/e2qBDowArZh0mXBYg XdTGdH+SItLyZApAGtmnkiFVayZxVpfO5H11CYT3lPT6+00862VmOateMPp+I50jpwcP erFWK7PqKMgGi0LJ89ZDa4/MY9KUfbBobu7hcuuuVIej/q/lpKw8xi26Su0mxAjVaIwA mYKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VwXM7qoUhqf+HEwuUmgUlTsVIN30W8k0bdpZKi4QzKs=; b=D9wD4G6D4UR/VkMgWtjcg32QOMA5ZormDqD7hZeU+w1vrv6Y8/WHCSFKHwbYvQqb7J 1o2qsMW8LJJh5FB4pfTggngwvrzqc0fv/72TuFOgIIzX8fvtJjLobSW5/HYNYojB2CJs aa6XK3nYCSpT/8SFUjTncLMTX/pLAPN2ZK0A6kcqCeSF0OXcAaTjh/gcGeGwNKaNv+pK 47sVSo6asTyqpV2W3zsDzU4j4dv11wk0fOgf+oQvdnQqgjoFNh42Qy5CNkQhQ9vv7CUC 4cHqR+Dxc+P/xGUXqEZ3p2XB2WgDotpV9DXnkuj161xnAmYOeVeOULc8goZ/1TjkAG7L TCNA== X-Gm-Message-State: AOAM5318L7HGyPkaEqKQMoXc6lgMui2MXpv2Vcx25uIqNzTNO6JITFTD ifh6mVy4rZU518nOT8UNpZM= X-Google-Smtp-Source: ABdhPJy3E2m7Ex0GKsGxe1mqE8VfwX7XIsvZk927yjXGSeiwH9pS8gVezgvymFYU1D0xPdF+OXPsZw== X-Received: by 2002:a05:600c:258:: with SMTP id 24mr1430404wmj.126.1593857078777; Sat, 04 Jul 2020 03:04:38 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id p4sm17554961wrx.63.2020.07.04.03.04.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jul 2020 03:04:37 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, 41531 <at> debbugs.gnu.org References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> Date: Sat, 4 Jul 2020 13:04:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87sgecssch.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41531 Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On 30.06.2020 14:31, João Távora wrote: > Dmitry has expressed his intent to make the new eldoc.el work with a new > futures/promises library. He prototyped one of those libraries. I have > nothing against that in the future. However, > > 1. I don't have the resources to make the eldoc.el prototype work with > Dmitry's or other libraries; > > 2. We should revisit the purpose and the details of that and other > libraries in a separate discussion. For now it's high time we > advance the Eldoc libray;. Unsurprisingly, I object to this approach. We should have better async support in multiple Emacs facilities, and that means standardizing on some particular async primitives and functions that can manipulate them. There is no need to release support for ad-hoc async values (you didn't like mine, so it's only fair play that I object to yours) when we can transition to full futures right away. I'll get into a little more detail in the more full review, tonight or tomorrow, but for now my impression is that, in the absence of such standard library and async manipulation functions, you decided to implement them specially in Eldoc. Even though most of that logic should be extracted to general purpose code that manipulates async objects (futures/promises or the like). And I wonder how the desire not to have such logic in Eglot has influenced your total vision of the API. Because with futures in standard library, it could look fairly different, and could need fewer changes compared to its current shape. Regarding #1, it should be trivial to reimplement on top of futures. I could do this myself, as long as everybody is fine with the proposed shape of futures on standardize on.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:44:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 05:44:44 2020 Received: from localhost ([127.0.0.1]:58083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jreiy-0003mx-3C for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:44:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1jreiw-0003mj-DW for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:44:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60599) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1jreiq-0007py-JU; Sat, 04 Jul 2020 05:44:36 -0400 Received: from [176.228.60.248] (port=1648 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1jreip-0005cj-Rd; Sat, 04 Jul 2020 05:44:36 -0400 Date: Sat, 04 Jul 2020 12:44:38 +0300 Message-Id: <83a70fvcl5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <CALDnm52m5MZurAzGMVAjvgvjwU1iDw1_=-tvwW=5K7xHWu8iHw@HIDDEN> (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 4 Jul 2020 10:37:50 +0100) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN> <83blkvvd7q.fsf@HIDDEN> <CALDnm52m5MZurAzGMVAjvgvjwU1iDw1_=-tvwW=5K7xHWu8iHw@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Sat, 4 Jul 2020 10:37:50 +0100 > Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, > dgutov@HIDDEN > > I can add some things to mention that async is now supported in a > "first class" sense. Please do, I think it's important. You don't have to tell too many details in NEWS about that, just mention it, and say that the details are in the ELisp manual and the doc strings of this-and-that. TIA
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:38:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 05:38:04 2020 Received: from localhost ([127.0.0.1]:58078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrecW-0003cy-77 for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:38:04 -0400 Received: from mail-il1-f172.google.com ([209.85.166.172]:45081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jrecU-0003cV-Bp for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:38:03 -0400 Received: by mail-il1-f172.google.com with SMTP id o3so11697202ilo.12 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 02:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eJCEPdd5HLzCOUFFbN8BZBu3wRwL6iq83UVPpcxXoPI=; b=POle9iPshb8GvArqtBGtS5Pbo9F+KAjHksOhL7ifIVinDaReCp5AysDNRdy+P+7rme qn657l4LEZ65TCnWkstJoz3tzb+uSJzStbZc0bHCYj1lrm9O2WgTh0nknLNuvuL7JQMc Fsh71BP/DyLViwZwcX97qzGcJbH9HQ6zz4mG2FSMUegBay+dERhBFjwFmaqnAcCh7eAN icbYobwOlzd8g1rKUwY8WPVT7LioIp9TTv59YOklmC3fYq1fj9XtShcBw603pEIiXBiX AS341lOhU1CxZMciVqUiqVEyEgBnlgVMF1aSSaOfOIO5M+LzBfjIe1WFUSkdQ6CINgKd 3Egg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eJCEPdd5HLzCOUFFbN8BZBu3wRwL6iq83UVPpcxXoPI=; b=DH32bkzA2PV/7eqPeV7ITrDpcC4HeQ8LTKd7zgE4sYu8wtqVGeRwtygycE5idiCCha Yo3ObdkcwZO6S4/jOELrVAluZv7FWl2p89U3909UBTxgePgtXmWl3JOaQ+lBo07LxErz mrFjmDxNWgSGGQSsvrAPTaKn+2Q6sThji1js9QQ51Cyfw6a6AsMZ33bQd3ee8r903dhV bDzIdXXYFrc8pyz9TjG+ejUU4vh38XJsmx+lUBo7d+g+TH9a381YsafLtCVN98EilMmF eSG9kAwiYsOdCbHmln97NNyHB/cSdLJcTjGci0+tFNz+JeWZdpfbniPIQxXvaa+53ufe d20Q== X-Gm-Message-State: AOAM533zSrblYzZ6XDLhAQrZV2jQJI3CBaEHXNjsGmbVCsxEUFASfeHB dqElZNcPuyXO/UDSc0jpdkfR8Mr/VIXCnxlgcNDz7A== X-Google-Smtp-Source: ABdhPJwocdD8D71Z+sn8l8uryYkDj9tq+SDvwoGSKPVttxwAwJFXQThpqQYkuFYywf+bpQay1vsxuBkFPolpJ+dKQZQ= X-Received: by 2002:a05:6e02:1212:: with SMTP id a18mr19598863ilq.97.1593855476874; Sat, 04 Jul 2020 02:37:56 -0700 (PDT) MIME-Version: 1.0 References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN> <83blkvvd7q.fsf@HIDDEN> In-Reply-To: <83blkvvd7q.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Sat, 4 Jul 2020 10:37:50 +0100 Message-ID: <CALDnm52m5MZurAzGMVAjvgvjwU1iDw1_=-tvwW=5K7xHWu8iHw@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000085c58905a99a659c" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000085c58905a99a659c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, ok I see what you mean. I didn't feel it was necessary to enter into details since it is backwards compatible. But I can add some things to mention that async is now supported in a "first class" sense. Jo=C3=A3o On Sat, Jul 4, 2020, 10:31 Eli Zaretskii <eliz@HIDDEN> wrote: > > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> > > Date: Sat, 4 Jul 2020 10:21:43 +0100 > > Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, > andreyk.mad@HIDDEN, > > dgutov@HIDDEN > > > > I'm surprised the NEWS entry I had written got lost. In the git rebasin= g, > > maybe. > > There is a NEWS entry in the branch, but it only says this: > > -*** 'eldoc-documentation-function' is now a user option. > -Modes should use the new hook instead of this user option to register > -their backends. > +*** New user option 'eldoc-documentation-strategy' > +The built-in choices available for this user option let users compose > +the results of 'eldoc-documentation-functions' in various ways. The > +user option replaces 'eldoc-documentation-function', which is now > +obsolete. > > I don't see how by reading this anyone could understand that the > change allows significant new functionality. maybe you wrote more > than that, and it did get lost somehow? > > (FTR, I did "git diff ...origin/scratch/eldoc-async" to see the > changes on the branch.) > --00000000000085c58905a99a659c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Ah, ok I see what you mean.</div><div dir=3D"auto"><= br></div><div dir=3D"auto">I didn't feel it was necessary to enter into= details since it is backwards compatible. But I can add some things to men= tion that async is now supported in a "first class" sense.</div><= div dir=3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o<br><br><div class=3D= "gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Ju= l 4, 2020, 10:31 Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@gnu= .org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Jo= =C3=A3o T=C3=A1vora <<a href=3D"mailto:joaotavora@HIDDEN" target=3D"_= blank" rel=3D"noreferrer">joaotavora@HIDDEN</a>><br> > Date: Sat, 4 Jul 2020 10:21:43 +0100<br> > Cc: <a href=3D"mailto:41531 <at> debbugs.gnu.org" target=3D"_blank" rel=3D"= noreferrer">41531 <at> debbugs.gnu.org</a>, Stefan Monnier <<a href=3D"mailto= :monnier@HIDDEN" target=3D"_blank" rel=3D"noreferrer">monnier@iro= .umontreal.ca</a>>, <a href=3D"mailto:andreyk.mad@HIDDEN" target=3D"_= blank" rel=3D"noreferrer">andreyk.mad@HIDDEN</a>, <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:dgutov@HIDDEN" target= =3D"_blank" rel=3D"noreferrer">dgutov@HIDDEN</a><br> > <br> > I'm surprised the NEWS entry I had written got lost. In the git re= basing,<br> > maybe.<br> <br> There is a NEWS entry in the branch, but it only says this:<br> <br> =C2=A0 -*** 'eldoc-documentation-function' is now a user option.<br= > =C2=A0 -Modes should use the new hook instead of this user option to regist= er<br> =C2=A0 -their backends.<br> =C2=A0 +*** New user option 'eldoc-documentation-strategy'<br> =C2=A0 +The built-in choices available for this user option let users compo= se<br> =C2=A0 +the results of 'eldoc-documentation-functions' in various w= ays.=C2=A0 The<br> =C2=A0 +user option replaces 'eldoc-documentation-function', which = is now<br> =C2=A0 +obsolete.<br> <br> I don't see how by reading this anyone could understand that the<br> change allows significant new functionality.=C2=A0 maybe you wrote more<br> than that, and it did get lost somehow?<br> <br> (FTR, I did "git diff ...origin/scratch/eldoc-async" to see the<b= r> changes on the branch.)<br> </blockquote></div></div></div> --00000000000085c58905a99a659c--
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:31:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 05:31:14 2020 Received: from localhost ([127.0.0.1]:58056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jreVu-0003SQ-Fc for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:31:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1jreVs-0003S6-6u for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:31:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60542) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1jreVk-0004xM-Hr; Sat, 04 Jul 2020 05:31:06 -0400 Received: from [176.228.60.248] (port=4704 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1jreVj-0000in-17; Sat, 04 Jul 2020 05:31:03 -0400 Date: Sat, 04 Jul 2020 12:31:05 +0300 Message-Id: <83blkvvd7q.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN> (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 4 Jul 2020 10:21:43 +0100) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Sat, 4 Jul 2020 10:21:43 +0100 > Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, > dgutov@HIDDEN > > I'm surprised the NEWS entry I had written got lost. In the git rebasing, > maybe. There is a NEWS entry in the branch, but it only says this: -*** 'eldoc-documentation-function' is now a user option. -Modes should use the new hook instead of this user option to register -their backends. +*** New user option 'eldoc-documentation-strategy' +The built-in choices available for this user option let users compose +the results of 'eldoc-documentation-functions' in various ways. The +user option replaces 'eldoc-documentation-function', which is now +obsolete. I don't see how by reading this anyone could understand that the change allows significant new functionality. maybe you wrote more than that, and it did get lost somehow? (FTR, I did "git diff ...origin/scratch/eldoc-async" to see the changes on the branch.)
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:21:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 05:21:59 2020 Received: from localhost ([127.0.0.1]:58051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jreMx-0003D4-BY for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:21:59 -0400 Received: from mail-io1-f50.google.com ([209.85.166.50]:38071) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jreMv-0003Cs-4w for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:21:57 -0400 Received: by mail-io1-f50.google.com with SMTP id f6so19041948ioj.5 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 02:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B8tYZnjh4Ij0tuHzim3NUUigGwD8Yj54B/Cp6F7Zlfg=; b=GyFiVIULbm72Q1DjuI52B1FKT/hERS2h+AYg+2meFTX6g8MyfWgnuTURZyBzw9e1Tj fGFGUfdNsgUpeHX6awYZxRZBsWrZkBsKO1b5KmXVzC1W0Op9UcjottSSrctTP7kcVpIq 6qLe1Bv1LkL0AJiaRMbugeNyQFseY6sME6rFGltWUu9py6Cly/oWHawvnV2hKYs85nP4 6SItKrxlVAzYhm5pBsCSJc9itE82h6z//WzC3HkwXJ8vAdRYHZ8VmK1+Qf69kdFnzb8E w2BKVLjq2P06Hpz7DrZ+7mAnAzhrhShw+cwPA/Cz+34nR8BUKE+BEdsMw931QSfT9tGS EU/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B8tYZnjh4Ij0tuHzim3NUUigGwD8Yj54B/Cp6F7Zlfg=; b=UwTuG8ht7DCel4QTp/vUOIqSOWCAy/2QtCCtTH1gNsmaf8sMmcEJrGG6VqpINj/0cK Yu0qobCKn2u16a27o2/DmLBWvO48exL6mK0En9VBPcuhDfHs6/pKs83ywlsR9Hto+UFB g4xtl4AWhJRwaS+q/ahljun4umzmgdU8+UlvNHkSrGewXT7SWrAmK6IGsEZkEsSX7ori ND4DIeWLcf9DGcOOQIg/7BnSfv3RwNCT1UKMB4tkCtGLJhGNJZ4EWywPMhVIGzlaMKIm JcHFj0CbzX4yBDnCj+DqmOwuB8miMyNJ+O59O25F1ah1K9HE529gmymLEOAkakMSRD4U PcwA== X-Gm-Message-State: AOAM531pif/rBVFtZTC/AJZuF0l6xXMkFd3QMBe9YZ4cRwVkxtaHsGIc cWGQSQKZmraRHlbbIai+Ss7PZFvSR/99RV/+bMA= X-Google-Smtp-Source: ABdhPJy1HD0q4aGulmElEXSnhPaFHvzBP5ErCHx9Rkj9zsdo48Gbtm1FHsgQq7NZsZ81K4sijURAhnFSIPIVi9snM7Y= X-Received: by 2002:a02:9642:: with SMTP id c60mr42634940jai.71.1593854510393; Sat, 04 Jul 2020 02:21:50 -0700 (PDT) MIME-Version: 1.0 References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> <83k0zjvi4c.fsf@HIDDEN> In-Reply-To: <83k0zjvi4c.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Sat, 4 Jul 2020 10:21:43 +0100 Message-ID: <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000ea6e9b05a99a2bab" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000ea6e9b05a99a2bab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback, Eli. I'll get to each point later on. But I'm surprised the NEWS entry I had written got lost. In the git rebasing, maybe. Jo=C3=A3o On Sat, Jul 4, 2020, 08:45 Eli Zaretskii <eliz@HIDDEN> wrote: > > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> > > Date: Tue, 30 Jun 2020 12:31:10 +0100 > > Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, > > Dmitry Gutov <dgutov@HIDDEN> > > > > The work that started with this discussion is now mostly complete. It > > has been sitting in the scratch/eldoc-async branch of the Savannah repo > > for a while, but I've been very busy and didn't have time to annouce it= . > > Thanks. > > > Anyway I think my efforts are ready to push to master. I'll do so soon > > unless someone raises a serious problem about it. > > Not a serious problem, but some comments: > > > -(defun eldoc-message (&optional string) > > +(make-obsolete > > + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0"= ) > > Isn't the version part of the obsolete message supposed to tell the > version of Emacs? > > The change to the number of arguments of the functions in the > eldoc-documentation-functions hook is backward-incompatible, isn't it? > I see you've changed the relevant functions in our sources, but what > about 3rd-party packages? > > Also, the doc string of this hook needs clarification regarding the > arguments: it first says that CALLBACK is the only mandatory argument > to the hook functions, but then, out of the blue, appear additional > arguments DOCSTRING and a list of key-value pairs. Confusing. > > The doc strings have some words in UK English spelling "(e.g., > "honour"), please fix that. Also, please make sure comments all start > with a capital letter, end with a period, and comprise full English > sentences. > > The doc string of eldoc-documentation-compose doesn't say a word about > the function's argument. > > In the doc string of eldoc-documentation-strategy, you use the phrase > "queries the special hook for all functions that produce doc strings" > to mean, AFAIU, that the specified functions in the hook-variable list > are called. IMO, this wording could be confusing; suggest to use this > instead: > > `eldoc-documentation-compose': calls all the functions in the hook, > and displays all of the resulting doc strings ... > > This doc string doesn't explain the use of the timer, it explains the > reason for its existence. It should also describe the use: > > > +(defvar eldoc--enthusiasm-curbing-timer nil > > + "Timer used by `eldoc-documentation-enthusiast' to avoid blinking.") > > Last, but not least: the "async" part of the branch's name hints on > some advanced and extremely useful functionality that these changes > are supposed to allow, but I see no mention of that in NEWS and in the > manual bits. What did I miss? > --000000000000ea6e9b05a99a2bab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Thanks for the feedback, Eli.<div dir=3D"auto"><br></div>= <div dir=3D"auto">I'll get to each point later on. But I'm surprise= d the NEWS entry I had written got lost. In the git rebasing, maybe.</div><= div dir=3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o</div></div><br><div = class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 4, = 2020, 08:45 Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN<= /a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Jo=C3=A3o= T=C3=A1vora <<a href=3D"mailto:joaotavora@HIDDEN" target=3D"_blank" = rel=3D"noreferrer">joaotavora@HIDDEN</a>><br> > Date: Tue, 30 Jun 2020 12:31:10 +0100<br> > Cc: Stefan Monnier <<a href=3D"mailto:monnier@HIDDEN" tar= get=3D"_blank" rel=3D"noreferrer">monnier@HIDDEN</a>>, <a href= =3D"mailto:andreyk.mad@HIDDEN" target=3D"_blank" rel=3D"noreferrer">andr= eyk.mad@HIDDEN</a>,<br> >=C2=A0 Dmitry Gutov <<a href=3D"mailto:dgutov@HIDDEN" target=3D"_= blank" rel=3D"noreferrer">dgutov@HIDDEN</a>><br> > <br> > The work that started with this discussion is now mostly complete.=C2= =A0 It<br> > has been sitting in the scratch/eldoc-async branch of the Savannah rep= o<br> > for a while, but I've been very busy and didn't have time to a= nnouce it.<br> <br> Thanks.<br> <br> > Anyway I think my efforts are ready to push to master.=C2=A0 I'll = do so soon<br> > unless someone raises a serious problem about it.<br> <br> Not a serious problem, but some comments:<br> <br> > -(defun eldoc-message (&optional string)<br> > +(make-obsolete<br> > + 'eldoc-message "use `eldoc-documentation-functions' ins= tead." "1.1.0")<br> <br> Isn't the version part of the obsolete message supposed to tell the<br> version of Emacs?<br> <br> The change to the number of arguments of the functions in the<br> eldoc-documentation-functions hook is backward-incompatible, isn't it?<= br> I see you've changed the relevant functions in our sources, but what<br= > about 3rd-party packages?<br> <br> Also, the doc string of this hook needs clarification regarding the<br> arguments: it first says that CALLBACK is the only mandatory argument<br> to the hook functions, but then, out of the blue, appear additional<br> arguments DOCSTRING and a list of key-value pairs.=C2=A0 Confusing.<br> <br> The doc strings have some words in UK English spelling "(e.g.,<br> "honour"), please fix that.=C2=A0 Also, please make sure comments= all start<br> with a capital letter, end with a period, and comprise full English<br> sentences.<br> <br> The doc string of eldoc-documentation-compose doesn't say a word about<= br> the function's argument.<br> <br> In the doc string of eldoc-documentation-strategy, you use the phrase<br> "queries the special hook for all functions that produce doc strings&q= uot;<br> to mean, AFAIU, that the specified functions in the hook-variable list<br> are called.=C2=A0 IMO, this wording could be confusing; suggest to use this= <br> instead:<br> <br> =C2=A0 `eldoc-documentation-compose': calls all the functions in the ho= ok,<br> =C2=A0 and displays all of the resulting doc strings ...<br> <br> This doc string doesn't explain the use of the timer, it explains the<b= r> reason for its existence.=C2=A0 It should also describe the use:<br> <br> > +(defvar eldoc--enthusiasm-curbing-timer nil<br> > +=C2=A0 "Timer used by `eldoc-documentation-enthusiast' to av= oid blinking.")<br> <br> Last, but not least: the "async" part of the branch's name hi= nts on<br> some advanced and extremely useful functionality that these changes<br> are supposed to allow, but I see no mention of that in NEWS and in the<br> manual bits.=C2=A0 What did I miss?<br> </blockquote></div> --000000000000ea6e9b05a99a2bab--
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 07:45:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 04 03:45:21 2020 Received: from localhost ([127.0.0.1]:57988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jrcrR-0000rM-1M for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 03:45:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1jrcrN-0000r6-Mb for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 03:45:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59655) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1jrcrF-00009f-Nm; Sat, 04 Jul 2020 03:45:10 -0400 Received: from [176.228.60.248] (port=1618 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1jrcrC-0002ah-OP; Sat, 04 Jul 2020 03:45:08 -0400 Date: Sat, 04 Jul 2020 10:45:07 +0300 Message-Id: <83k0zjvi4c.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <87sgecssch.fsf@HIDDEN> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Tue, 30 Jun 2020 12:31:10 +0100) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Tue, 30 Jun 2020 12:31:10 +0100 > Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, > Dmitry Gutov <dgutov@HIDDEN> > > The work that started with this discussion is now mostly complete. It > has been sitting in the scratch/eldoc-async branch of the Savannah repo > for a while, but I've been very busy and didn't have time to annouce it. Thanks. > Anyway I think my efforts are ready to push to master. I'll do so soon > unless someone raises a serious problem about it. Not a serious problem, but some comments: > -(defun eldoc-message (&optional string) > +(make-obsolete > + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0") Isn't the version part of the obsolete message supposed to tell the version of Emacs? The change to the number of arguments of the functions in the eldoc-documentation-functions hook is backward-incompatible, isn't it? I see you've changed the relevant functions in our sources, but what about 3rd-party packages? Also, the doc string of this hook needs clarification regarding the arguments: it first says that CALLBACK is the only mandatory argument to the hook functions, but then, out of the blue, appear additional arguments DOCSTRING and a list of key-value pairs. Confusing. The doc strings have some words in UK English spelling "(e.g., "honour"), please fix that. Also, please make sure comments all start with a capital letter, end with a period, and comprise full English sentences. The doc string of eldoc-documentation-compose doesn't say a word about the function's argument. In the doc string of eldoc-documentation-strategy, you use the phrase "queries the special hook for all functions that produce doc strings" to mean, AFAIU, that the specified functions in the hook-variable list are called. IMO, this wording could be confusing; suggest to use this instead: `eldoc-documentation-compose': calls all the functions in the hook, and displays all of the resulting doc strings ... This doc string doesn't explain the use of the timer, it explains the reason for its existence. It should also describe the use: > +(defvar eldoc--enthusiasm-curbing-timer nil > + "Timer used by `eldoc-documentation-enthusiast' to avoid blinking.") Last, but not least: the "async" part of the branch's name hints on some advanced and extremely useful functionality that these changes are supposed to allow, but I see no mention of that in NEWS and in the manual bits. What did I miss?
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 30 Jun 2020 11:31:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 30 07:31:22 2020
Received: from localhost ([127.0.0.1]:50342 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jqETy-0005uA-0G
for submit <at> debbugs.gnu.org; Tue, 30 Jun 2020 07:31:22 -0400
Received: from mail-wm1-f67.google.com ([209.85.128.67]:37216)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jqETv-0005oF-Sf
for 41531 <at> debbugs.gnu.org; Tue, 30 Jun 2020 07:31:21 -0400
Received: by mail-wm1-f67.google.com with SMTP id o2so19250802wmh.2
for <41531 <at> debbugs.gnu.org>; Tue, 30 Jun 2020 04:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:user-agent:date
:message-id:mime-version:content-transfer-encoding;
bh=LVuAsIci5xxFQPp0JLCOkrOuIMwzgb8Nsyc0ubuUT+k=;
b=hk3GCQO5/2nLJ3JilndH7UkgrJjFKJ4c3OfrNcssSBv1BKwTx0NCzutMbR3kSnCOe0
C3Wqg/lKsoA16JOt0R2JgcBq5sDTy0nVcPEiFw9vvEmmDsoBIG5kcw9V12KV07X7Xoas
GmehTrl3KZaG2Wr8buzHTg4bHL8hYtquJBd2a57aeE1AL6dAqoYMYj68PeFwky3Yl37q
uqSi0PjVQoB+0Q8uJP8fojzv/DjZWd7c3hH+BTRdvfE7fraSWyVy+OOyxqQZS8Xx6Lti
tAyMHP3ixMbMQvlcwPdvYwv6vefdM/OxnXH0MbJ9dtC9gG496Q5bFgSGR03zt0y7Z2PJ
nFkQ==
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:in-reply-to:references
:user-agent:date:message-id:mime-version:content-transfer-encoding;
bh=LVuAsIci5xxFQPp0JLCOkrOuIMwzgb8Nsyc0ubuUT+k=;
b=GMEH+8V/IJ2nEmZ204xZ3SBWIoiOoB184xwxeoi7DZXHX/W1el7Kt1dvx0k6LZ1kk6
pSnrS1a0qGYgxdr8ZEktRjt+SkWXKWjLu1bfbjlQ7Nu/N0YaVdPG+6hwZcls1hcjdyPS
3E2lUXA/an7VCAkhhggCKs67Ef1rHVjHE9/FpEtxFnmLZucffUfJY4XrFA1Q8xmJBSmf
B7gzxiCi+72fbsVtIYBZPEHFNq4pl7+Kq2bimZSanRTA0gUIiubSa+Is7kYTSwPJHzQl
GLF5LCjiHo2PR5z0WkaKYMJqqfDILus9TGg3/Ssz36kHP51s0qG6pTHtRH0eMJ9Z/lQC
FJ/g==
X-Gm-Message-State: AOAM531eWqaxR22WJWmTjvKkp/JoBd2Qi9rCCUK1kg8QM7uYh4TMmJX4
yCGYzwBoZ2laQAZXJ4zctcM=
X-Google-Smtp-Source: ABdhPJwWdBhoy0gYLj6ujuzd2qc5rAXZT4ZNIQy3xQ+ZlWJVlLth1HQmQonS1Uf4M303FJSRHCF/JQ==
X-Received: by 2002:a1c:345:: with SMTP id 66mr6053391wmd.31.1593516673946;
Tue, 30 Jun 2020 04:31:13 -0700 (PDT)
Received: from krug ([89.180.148.126])
by smtp.gmail.com with ESMTPSA id g16sm3696913wrh.91.2020.06.30.04.31.12
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 30 Jun 2020 04:31:12 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: 41531 <at> debbugs.gnu.org
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
In-Reply-To: <875zckuet9.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?=
=?utf-8?Q?a=22's?= message of "Mon, 25 May 2020 18:04:02 +0100")
References: <875zckuet9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Date: Tue, 30 Jun 2020 12:31:10 +0100
Message-ID: <87sgecssch.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> Hi Stefan, Dmitry, Andrii and maintainers,
>
> Moving the discussion that started in
> https://github.com/joaotavora/eglot/pull/459 to the bug tracker, and
> attaching the two patches that contain what I think is a decent
> short-term solution to the eldoc/async problems.
Hello again,
The work that started with this discussion is now mostly complete. It
has been sitting in the scratch/eldoc-async branch of the Savannah repo
for a while, but I've been very busy and didn't have time to annouce it.
I've cleaned it up to to a four commit effort which.
99fd115a8c Make more parts of Emacs use new Eldoc capabilities
aaf5dfc71e * lisp/emacs-lisp/eldoc.el (Version): Bump to 1.1.0
62dc1d4824 New M-x eldoc for on-demand and interactive documentation re=
quests
6c54414d5f Better handle asynchronous Eldoc sources
I had good feedback on and off-list about it. It works with a version
of Eglot in its scratch/work-with-new-eldoc branch.
There is of course a lot that can still be fixed or added, especially in
the domain of controlling the outlets for documentation (which now are
restricted to the echo area, and poorly formatted buffer).
Anyway I think my efforts are ready to push to master. I'll do so soon
unless someone raises a serious problem about it.
Dmitry has expressed his intent to make the new eldoc.el work with a new
futures/promises library. He prototyped one of those libraries. I have
nothing against that in the future. However,
1. I don't have the resources to make the eldoc.el prototype work with
Dmitry's or other libraries;
2. We should revisit the purpose and the details of that and other
libraries in a separate discussion. For now it's high time we
advance the Eldoc libray;.
Thanks,
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 11 Jun 2020 11:11:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 11 07:11:49 2020
Received: from localhost ([127.0.0.1]:36127 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jjL7d-0004ex-Je
for submit <at> debbugs.gnu.org; Thu, 11 Jun 2020 07:11:49 -0400
Received: from mail-lj1-f193.google.com ([209.85.208.193]:37526)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <andreyk.mad@HIDDEN>) id 1jjL7b-0004ej-Ra
for 41531 <at> debbugs.gnu.org; Thu, 11 Jun 2020 07:11:48 -0400
Received: by mail-lj1-f193.google.com with SMTP id e4so6433729ljn.4
for <41531 <at> debbugs.gnu.org>; Thu, 11 Jun 2020 04:11:47 -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=sYeVq2pd5RoGtD/W8xpKWgT7IBEGsOZb6ldNsVlJjwc=;
b=PLfIEIu+wt1cvMgwp6LEYaTnz3G9fNCFpyiaDtCGPw944w4RR+nm9tMVlob/3dsBa7
e/Qa79TLDM753DxsXMTagcQ71Zi4HZGwg+T/eCfOhgrOYe/rcfzl7gxGKYiMQK2Bd4Lq
/+TN5B+xS8Uy05brqbwOKn+RshSniDTW8ziZmau22kxGF6mRqRfrHBa6qQan4UgVY4P+
KlumQUlDLj3rUDKVI7zk7WdlwIG3TmtTEwNtx0t6KAWbm1+4zyJHVtTxsA6LGwAINOq9
v5nzL6ks+BXSxQWBaO50CKJLD1qCPDrrdexosz47FHFsOIe8wRaPWzxncazIORo5V0pU
ZYDg==
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=sYeVq2pd5RoGtD/W8xpKWgT7IBEGsOZb6ldNsVlJjwc=;
b=K8PwXrhQWQ1Bmxt0FWcfroZD6B0TDZGCohLJb+CC4HEDdYRO+UHGtKn5pX6kcf26dY
4LMTbyBxizmKeJ6AOIeg9uaPy2OTe6mp6655Fv3dTbpXCaKblwA5MPmARKRNSgVgNGWe
x0MUSrvm7JaQuGrmOmcmG5hBLbGNE9K8wH7C5aGr+V4lPRxIdAbqMCvlDUAPP+lz7wp5
9JkbM9AJQhneVSbffYbYo9bF+9ik1cIA+e1ovRn1jYq4jbIkHuO2t+/SwSpsyA6wWkvP
95TPRfvbEQIxfzUajsdblLri8EWAn7z7mcnQUDeIcs1JVaB7y6jC1FsOnpeHgIUqZyjo
FiLg==
X-Gm-Message-State: AOAM532Mw4z6C1PAtS2cZ4PsVYCe42oSj3aIVgP2Ah+ev4cbhHvh6hov
L1BwqB+AyeJ78bc8iXAQkgk=
X-Google-Smtp-Source: ABdhPJxxWns3JHqzJjxIfimu3i5ZH74F34gvc3/Ub3MH/Xf1mcQLgd12b6ZXgJPi6tOFbrfTOuIFNQ==
X-Received: by 2002:a2e:b5b9:: with SMTP id f25mr4281775ljn.50.1591873901681;
Thu, 11 Jun 2020 04:11:41 -0700 (PDT)
Received: from muffinmac.local ([91.206.110.148])
by smtp.gmail.com with ESMTPSA id f74sm716399lfd.68.2020.06.11.04.11.40
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 11 Jun 2020 04:11:41 -0700 (PDT)
From: Andrii Kolomoiets <andreyk.mad@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 28.0.50; proper Eldoc async support
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
<87img5lqty.fsf@HIDDEN>
Date: Thu, 11 Jun 2020 14:11:39 +0300
In-Reply-To: <87img5lqty.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?=
=?utf-8?Q?a=22's?= message of "Fri, 05 Jun 2020 12:00:57 +0100")
Message-ID: <m2r1ul26xg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Sorry for the late reply. João Távora writes: >> 1. Display
only first line of the hover info. Again :-) > > You should be able to do
this with either > > (setq eldoc-echo-area-use-multiline-p 1) > > or > >
(setq eldoc-echo-area-use-multiline-p n [...]
Content analysis details: (3.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[91.206.110.148 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (andreyk.mad[at]gmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.208.193 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.208.193 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, theothornhill@HIDDEN, mvoteiza@HIDDEN,
Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>,
Fredrik Bergroth <fbergroth@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Sorry for the late reply. João Távora writes: >> 1. Display
only first line of the hover info. Again :-) > > You should be able to do
this with either > > (setq eldoc-echo-area-use-multiline-p 1) > > or > >
(setq eldoc-echo-area-use-multiline-p n [...]
Content analysis details: (2.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[91.206.110.148 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.208.193 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.208.193 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (andreyk.mad[at]gmail.com)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Sorry for the late reply.
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>> 1. Display only first line of the hover info. Again :-)
>
> You should be able to do this with either
>
> (setq eldoc-echo-area-use-multiline-p 1)
>
> or
>
> (setq eldoc-echo-area-use-multiline-p nil)
>
> Did you try this? If so, what exactly didn't work for you when you
> did?
This way the signature info is truncated. For the function with many
parameters the info of the last parameters is not visible.=20
>> 2. The hover info is sometimes displayed right before the signature info
>> making the echo area to "blink". I suppose this must be fixed on Eglot
>> side by not requesting both the hover and the signature infos at the
>> same time.
>
> Not something to be fixed in Eglot, definitely, it's not its fault or
> responsibility: it just reports whatever it has.
According to specification, server may send `triggerCharacters` in the
`SignatureHelpOptions`: the characters that trigger signature help
automatically. Maybe Eglot should not always request the signature
info.
Though I like the current implementation.
>> 3. That IMO useless "...truncated, see *help* buffer" message is moved
>> to Eldoc. Do we really need to show this message every time?
>
> I see. Maybe not _every time_ but at least _once_, I'd say. Once per
> Eldoc session (but what is an Eldoc session)? Once per x truncated
> messages? Customization variable? (I hate those, but maybe).
>
> Or maybe never show it?
Yep. Just like no additional message like "Press C-h v for the full
documentation" is shown hovering the variable in the `emacs-lisp-mode`.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 6 Jun 2020 01:57:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 21:57:41 2020
Received: from localhost ([127.0.0.1]:50427 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jhO5c-0005HK-Vc
for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 21:57:41 -0400
Received: from mail-wm1-f49.google.com ([209.85.128.49]:35010)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1jhO5a-0005H6-6z
for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 21:57:38 -0400
Received: by mail-wm1-f49.google.com with SMTP id q25so10794506wmj.0
for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 18:57:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-language;
bh=JGJgGG+LBCJdCbud5Cx4q8YSPWzILkaDeg+hAAZJMRE=;
b=lcmSRfiMZjMr3vST+jWxriHxlUVQG2+gZCvGaPClRyQe+JnfqSPXZLz8eCIhnBIMGg
CcXgr4XAP7f4zaooJKjLr2Rj/BFsTtzR271wC+2bNmBihDIvb45v4PBPfp/50U/b+L+r
pu5Y0f/O7eiIf1k5TxLyJvpn/C0hi/TUnDhMS4apd+wMSZceyEaDRjMJKQnTjZA7BHpg
S8Et7qJbsQDD7GMf8JXvanUH9pmCZcb+L01gUzBkqcoCEWd6I+2/CyzYYbhe0ZrAy+zc
ZIjMlgUB4v5+jBCbbC+0gucoIHITwQvozKPu2S/MqsYgvYh0dpxbGqn58SsWQDPRYqDw
oBiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
:date:user-agent:mime-version:in-reply-to:content-language;
bh=JGJgGG+LBCJdCbud5Cx4q8YSPWzILkaDeg+hAAZJMRE=;
b=miDVpQGaBhRN+iCtX4i3+WdxyMsZQLHwnx5Eil8mriXZx4WWT+pszdZbmm5jZmfwXJ
+SbTVOCs54sccmjITeMNoA8E1R13Thy5hDKWrjsiaLWM7q06xXfSwgJ6qgY4FXI2h3Pk
hpQnfCatm20/VWP63G5eckAofywhv3EboFatuNevOHcjOqfvuJ+cCZ1/KZjBDDxv9Hwj
5C/6Pgl++id4RKiTc2BmbEBCAR+KB5HMKFvfaJ5TI/ir7c1OLT3xjcmtLZv/PP8kaHAn
0H2eOsnUTM+wRjtGXzNUG0WPF0AbhUJmU/2qZNjEucp0rH9qM6sRQ8Wn0UjZmgGK1kVO
kKOQ==
X-Gm-Message-State: AOAM533BoCq1CXqPUz6VjO0N+5VeYs08tRXjUGtQWegwXy/b8VuIaKKD
rZA57UMpO98AukfrbB/65Uk=
X-Google-Smtp-Source: ABdhPJxqYUTqywXBM9fu26E3JPtCr7wTBylDzHSd8cwTVgFjDzHVaUPXbK7AQQ364CbG6X0ohAXKlA==
X-Received: by 2002:a1c:c2d6:: with SMTP id s205mr5606798wmf.140.1591408652319;
Fri, 05 Jun 2020 18:57:32 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
by smtp.googlemail.com with ESMTPSA id l18sm12646226wmj.22.2020.06.05.18.57.30
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 05 Jun 2020 18:57:30 -0700 (PDT)
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
To: Stefan Monnier <monnier@HIDDEN>,
=?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <63d261d3-62e5-8c60-f191-8734aa37752b@HIDDEN>
Date: Sat, 6 Jun 2020 04:57:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
Content-Type: multipart/mixed; boundary="------------05307B20715A0076A57CEA31"
Content-Language: en-US
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)
This is a multi-part message in MIME format.
--------------05307B20715A0076A57CEA31
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi!
On 26.05.2020 17:53, Stefan Monnier wrote:
>> But really: now we have deadlock too? I just want to solve this
>> problem: please let's commit something, and move on to the next bug.
> Can you use the sample `eldoc-future-*` code I sent earlier?
How about the attached file for a rough, but a largely feature complete
first version of futures?
To remind from previous discussions, we wanted futures:
- To be cancelable, so that the issuer could abort their calculations,
if they so desire.
- Force-able, meaning the consumer should be able to "realize" the
future synchronously, with the future's creator being able to support
their, most optimal, version of that logic. The default needs to be
useful and reliable enough, though, that callers could use it in 99% of
cases anyway.
The error callback probably wasn't mentioned, but it seems logical to
have it anyway.
For the first two features, I also considered using cl-generic, but
result might turn out to be clunkier, and we need overridability only
for two of these functions. But suggestions welcome.
TBD:
- Probably rename to "promises" in the end.
- It would be nice to have a certain degree of compatibility with
Christopher Wellons's emacs-aio, so that its promises could be accepted
by code that expects "our" futures/promises. Not sure if we can do that
without making the API more complex (aio-resolve's signature comes to
mind), or if we adopt its approach, importing the package wholesale
might make more sense.
--------------05307B20715A0076A57CEA31
Content-Type: text/x-emacs-lisp; charset=UTF-8;
name="future.el"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="future.el"
;;; future.el --- Futures, a concurrency primitive -*- lexical-binding: t; -*-
;; Copyright (C) 2020 Dmitry Gutov
;; Author: Dmitry Gutov <dgutov@HIDDEN>
;; Keywords: lisp
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;; You should have received a copy of the GNU General Public License
;; along with this program. If not, see <https://www.gnu.org/licenses/>.
;;; Commentary:
;;
;;; Code:
(require 'cl-lib)
(cl-defstruct (future
(:conc-name future--)
(:constructor future-make (&key force-fn
cancel-fn)))
"This structure represents a \"future\" value."
value
error
(status 'pending)
(force-fn #'future-force--apo)
(cancel-fn #'ignore)
callback
errback)
(defun future-force (f)
(funcall (future--force-fn f)))
(defun future-force--apo (f)
(while (eq (future--status f) 'pending)
(accept-process-output nil 0.05)))
(defun future-cancel (f)
(when (eq (future--status f) 'pending)
(setf (future--status f) 'canceled)
(funcall (future--cancel-fn f))))
(defun future-set (f v)
;; FIXME: Probably shouldn't error on 'canceled'.
(cl-assert (eq (future--status f) 'pending))
(setf (future--value f) v
(future--status f) 'success)
(when (future--callback f)
(funcall (future--callback f) v)))
(defun future-error (f e)
;; FIXME: Probably shouldn't error on 'canceled'.
(cl-assert (eq (future--status f) 'pending))
(setf (future--error f) e
(future--status f) 'error)
(when (future--errback f)
(funcall (future--errback f) e)))
;; Or we can make these both lists of functions...
(defun future-set-callback (f c)
(cl-assert (null (future--callback f)))
(setf (future--callback f) c)
(when (eq (future--status f) 'success)
(funcall c (future--value f))))
;; ...and rename to -add-callback/-add-errback.
(defun future-set-errback (f c)
(cl-assert (null (future--errback f)))
(setf (future--errback f) c)
(when (eq (future--status f) 'error)
(funcall c (future--error f))))
(provide 'future)
;;; future.el ends here
--------------05307B20715A0076A57CEA31--
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 23:28:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 19:28:15 2020
Received: from localhost ([127.0.0.1]:50338 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jhLl1-0001mS-5L
for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:28:15 -0400
Received: from mail-wm1-f47.google.com ([209.85.128.47]:39382)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jhLkz-0001mF-LJ
for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:28:13 -0400
Received: by mail-wm1-f47.google.com with SMTP id k26so10577955wmi.4
for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 16:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:user-agent:date
:message-id:mime-version:content-transfer-encoding;
bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
b=IQYazU0xKJNlbKSwX5diUO5+2yno17srluZzz045ssfKhXeDZERbIYQpVyi2lwDVlb
WMujL67FgNQyA0go3iXpyzcNlvONZhLACjdxi6j6wWimLT/F2hE0puJvZRiibBGGOoMM
lbvpbzuofI6CddK3ReuUE0koZKK5i6hTFeYiUR4Zu2B8t+WUON+ekW9Yo37PE2ZhLh6y
dZW0fFS8Z39Bqb7KP2x2QfDj+EMBGkU3S1tJ3aeS0unbUrjYqT53MheDVheznoPT3SX2
I2GYd1VhSoJ30OtJtU8S2n/TSUJ9GsamvQW2ZJmxgFWT2zzJs5WpMIIDRljRCnCb00sd
RzGg==
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:in-reply-to:references
:user-agent:date:message-id:mime-version:content-transfer-encoding;
bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
b=BF1iQA9hkzc0/V2uWqpC/nCEW2628rfxEXivJIRgbTIa2ji343QJjn7+vngo6ueY2k
q1wxAZlx++n2w+Tir0267Ng7GGnz3Et1atkn/pEhOi6CMTKC6Sfi0nja40qWUclQdyYM
fKNe9SmYGaErDb3Zq1kAQf8SuTpRJBXrR6pfx4FUbg2H7Ar/NCt3kEsOaF0HVwPvwo8U
HNNWeSL6Wq3SuNJDwkQ8l46D8yd0zTLWQcILjbtu2JURoNbRFLjvxz95u3yi4Qa/jIKI
ljA4dY+6z5H7sdVBxRifTaXAGRfgZAR0+vNgFFZ9/p7CQElppSRdSO61hUbVrTeUuxmL
2EMQ==
X-Gm-Message-State: AOAM530iSMSkyCjRhQHybNdt7VLRM9cOBC2qZjK29t+y8pF9kCy631+U
80dRIO145XWdTvUOYesqDhU=
X-Google-Smtp-Source: ABdhPJx7NXKRUVDOAJ3kIT+7LHVrTEJsaveZZwN39NmieTwDLAVc6nPqvRaVZ4CmKSP15kSoJ5bemg==
X-Received: by 2002:a1c:f401:: with SMTP id z1mr4696647wma.44.1591399687875;
Fri, 05 Jun 2020 16:28:07 -0700 (PDT)
Received: from krug ([89.180.147.39])
by smtp.gmail.com with ESMTPSA id a1sm12851031wmj.29.2020.06.05.16.28.06
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 05 Jun 2020 16:28:07 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Theodor Thornhill <theothornhill@HIDDEN>
Subject: Re: bug#41531: 28.0.50; proper Eldoc async support
In-Reply-To: <87img55rmm.fsf@HIDDEN> (Theodor Thornhill's message of
"Fri, 05 Jun 2020 17:50:38 +0000")
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
<87img5lqty.fsf@HIDDEN> <87img55rmm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Date: Sat, 06 Jun 2020 00:28:05 +0100
Message-ID: <874krpjdoa.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@HIDDEN>,
mvoteiza@HIDDEN, Stefan Monnier <monnier@HIDDEN>,
Dmitry Gutov <dgutov@HIDDEN>, Fredrik Bergroth <fbergroth@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Theodor Thornhill <theothornhill@HIDDEN> writes:
> Bug 1:=20=20=20=20=20=20
> 1. Open a file
> 2. Start eglot
> 3. Hover something with "C-h ."
> 4. Switch to the new window that popped up.
> 5. C-x k (kill buffer)
> 6. Repeat step 3.
> 7. "invalid buffer" and eldoc is dead.=20
> 8. Starting and stopping eldoc doesn't work=20=20=20
>
> This seems to happen since it uses the new buffer and updates it. When th=
at buffer is deleted, it gets confused.
Thanks. This is easy to fix. It's a buffer-live-p call somewhere.
> Bug 2:
> 1. (setq eldoc-echo-area-use-multiline-p nil)
> 2. eglot spits the whole thing on one line. This looks a bit weird since =
it uses both the signature and the documentation.
>
> This may not be a bug, but right now IMO it looks a bit strange.
It was intended. But I agree it's not good. I will change it: instead
of joining all lines, then trucating, I will just truncate the first
line if needed.
> Bug 3:
> 1. "M-:"
> 2. Type "("
> 3. Minibuffer shows: eldoc-error: (wrong number of arguments (0 . 0) 1)
I couldn't reproduce this one.
> I think the first bug is the most problematic one though :)
>
> However, I've started to take a liking to the no options set, with
> this version. I think I like the "truncate, press M-x ..." message
> more than the previous one.
Yes, and if `eldoc-doc-buffer` is bound to something shorter, then it
will be even simpler to read. I will eventually recommend we rebind
`C-h .` (display-local-help) to it. But in the meantime, I think I will
make Eglot bind it to that key, as an exception to Eglot's
no-keybindings policy.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 23:26:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 19:26:08 2020
Received: from localhost ([127.0.0.1]:50325 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jhLix-0001j2-Sd
for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:26:08 -0400
Received: from mail-wr1-f44.google.com ([209.85.221.44]:37144)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jhLiw-0001iX-6E
for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:26:06 -0400
Received: by mail-wr1-f44.google.com with SMTP id x13so11301831wrv.4
for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 16:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:user-agent:date
:message-id:mime-version:content-transfer-encoding;
bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
b=pwfxlDYsQ1gWgx75N5UKKdZadJrTyvZbV9eB4moEJwYvz+GXcEvTKqWU1jsZVPEO9n
hP5wCl+Xj/B29Uml0ChAZcMQoR7GZLfacvaXiDJT+GmxTeA5tWChkXYqyEjqu1xrjT7L
K1MbbmO8PNnOp+c0/JozVkRJyQmkxAsAekz8Iqlo8glh7MBofIAeYQo0lV262uEsytRv
PIQDKOgQkkRt+IysodY1Ie6+ZYYuftqLjpNeMpzvFOAGPB6X9MnNp8OgC9uTvoLv/0Aj
ocISFNY9nifueb6AtmO8kagNNKD2jlMrBps8SqzTTt2Bp4dIDc+ZuyZF7Bn6q2INKtky
469A==
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:in-reply-to:references
:user-agent:date:message-id:mime-version:content-transfer-encoding;
bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
b=NZoNUBlI6w2ui9YUxKQJglZBgFZ68/5zeWrsHqBuCXBvjNQEyDSI83Ww/3PRKGipUY
dGwXn/qQnOhJcD+fRgLQ/SO0QQDkx/E0VnPnoizyAD3tjINHnPg3wK9PKq22Yx7BVGWH
pFnYIImJhkxv/6zvx/J9dZfMvnwmB2ho4MQUGORPGUKzPPieogLFWmkQF3F6lmtFAHva
+ca+4XESPMxGrChXSEk9gMZsx7rnoiir2sGEnprxsq9wpzxKcEZ+3w0LzXPS3iDDyg5s
8kr1MaQukQCZxeSLZZde9jlR97pRvfjmbu16WdlvEGP/69Vvwsiuv1KcISpJexGfjzmq
3n4A==
X-Gm-Message-State: AOAM533r+EsifAvsds/FPUDRxSNgvdNzf3Rawd7P32hjcaV39SIJsc4d
BSGUQjH+Ac2ciKF5L2cukw0=
X-Google-Smtp-Source: ABdhPJyQI/cv3M1TNXVQDZ1YKvxC/92c3atpzNylXIbz8f3nQt46pkxWC84fCek2+PANz8s4owGvYw==
X-Received: by 2002:adf:f44b:: with SMTP id f11mr11645465wrp.165.1591399560210;
Fri, 05 Jun 2020 16:26:00 -0700 (PDT)
Received: from krug (89-180-151-23.net.novis.pt. [89.180.151.23])
by smtp.gmail.com with ESMTPSA id c65sm13442797wme.8.2020.06.05.16.25.41
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 05 Jun 2020 16:25:59 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Theodor Thornhill <theothornhill@HIDDEN>
Subject: Re: bug#41531: 28.0.50; proper Eldoc async support
In-Reply-To: <87img55rmm.fsf@HIDDEN> (Theodor Thornhill's message of
"Fri, 05 Jun 2020 17:50:38 +0000")
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
<87img5lqty.fsf@HIDDEN> <87img55rmm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Date: Sat, 06 Jun 2020 00:25:34 +0100
Message-ID: <877dwljdsh.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@HIDDEN>,
mvoteiza@HIDDEN, Stefan Monnier <monnier@HIDDEN>,
Dmitry Gutov <dgutov@HIDDEN>, Fredrik Bergroth <fbergroth@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Theodor Thornhill <theothornhill@HIDDEN> writes:
> Bug 1:=20=20=20=20=20=20
> 1. Open a file
> 2. Start eglot
> 3. Hover something with "C-h ."
> 4. Switch to the new window that popped up.
> 5. C-x k (kill buffer)
> 6. Repeat step 3.
> 7. "invalid buffer" and eldoc is dead.=20
> 8. Starting and stopping eldoc doesn't work=20=20=20
>
> This seems to happen since it uses the new buffer and updates it. When th=
at buffer is deleted, it gets confused.
Thanks. This is easy to fix. It's a buffer-live-p call somewhere.
> Bug 2:
> 1. (setq eldoc-echo-area-use-multiline-p nil)
> 2. eglot spits the whole thing on one line. This looks a bit weird since =
it uses both the signature and the documentation.
>
> This may not be a bug, but right now IMO it looks a bit strange.
It was intended. But I agree it's not good. I will change it: instead
of joining all lines, then trucating, I will just truncate the first
line if needed.
> Bug 3:
> 1. "M-:"
> 2. Type "("
> 3. Minibuffer shows: eldoc-error: (wrong number of arguments (0 . 0) 1)
I couldn't reproduce this one.
> I think the first bug is the most problematic one though :)
>
> However, I've started to take a liking to the no options set, with
> this version. I think I like the "truncate, press M-x ..." message
> more than the previous one.
Yes, and if `eldoc-doc-buffer` is bound to something shorter, then it
will be even simpler to read. I will eventually recommend we rebind
`C-h .` (display-local-help) to it. But in the meantime, I think I will
make Eglot bind it to that key, as an exception to Eglot's
no-keybindings policy.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 22:53:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 18:53:59 2020 Received: from localhost ([127.0.0.1]:50165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jhLDr-0000sa-HY for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 18:53:59 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:50344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jhLDq-0000sO-9Q for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 18:53:58 -0400 Received: by mail-wm1-f43.google.com with SMTP id v19so9767558wmj.0 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 15:53:58 -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; bh=SY8VRQQOBIAfZcVWMXaMNk8SmCKdcyQIl850/POSJ0I=; b=h/DOmcByxY0Rq+tuMaq3tLudH6l4e65Ml1h+Xc//5H3ozou2coUTUYUFpgGrNk/gJz LFqQR/jx+iGP72hwauY1GRld4JmFR/rZNwHnn71w4/ja2mVMhe/75Sdvpk3HsB+0vsfE 98vtM3DJuEQERLvM98/41jrIReOdqHKQcLUpV7JyEArJmGDfj+9gmftivnU6UgKGoa3w HTQy8agpZuJfrWkRMG/qASungC0Qr5/SmcEAvIUrFMiicJIRo3Zp8m/1nRqlLOyIiWJL 3LCTszRW1dRqQQ8eH90AZH5Oal7BZAaezTxeBNcmxr7wUFyOMyaeeqX4JUYEETQ5JNk9 tPIg== 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; bh=SY8VRQQOBIAfZcVWMXaMNk8SmCKdcyQIl850/POSJ0I=; b=IbKdVXxRP6++yLD9LOVT0ben8F25tO1XGHw60d9/yVeM8ru/bbrKxPRb9rJ3NMZcdI qSIGYwEsvGB8uzXRZlKNIbKzP6tik0tiQ2V/BelX4XNbOgQ/Ne1d+cGgnZk0Ul96aMdQ wLsg7PTq1CNIx4ug9W5Lob/hMbS8WpA+i2KKBe26NhAD71RWAsto0UL2zPcTuMuy/vzL KHOc/gtg6pUPnH9zaNrktQEbL5X+7ScQPL/5aMA4/qtK/pnISFI2qpVX0r9s2UcP20+F 8uX/gqBLGC7cQUiZuOMaHJaN6xxx8Vu9wpRg8/6jP1flIU88Ar562MJSUaE7foaEBOY5 evMg== X-Gm-Message-State: AOAM5338WWg3PdXic6ZdVcIW6iV6vHKa/noS1OtsXy95nKWs+mHY2A2k vdZ0zMtoyLusabM3cB9R5pk= X-Google-Smtp-Source: ABdhPJzjboyWNYrHT8WgXDCB+vtk3/GrTgB9bOC5KNk6CPO2bQ2VIDoQ7eQKvyxHWLvKhidKJhSUCQ== X-Received: by 2002:a7b:c04f:: with SMTP id u15mr4769383wmc.98.1591397632221; Fri, 05 Jun 2020 15:53:52 -0700 (PDT) Received: from krug ([89.180.147.39]) by smtp.gmail.com with ESMTPSA id y66sm13221532wmy.24.2020.06.05.15.53.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 15:53:51 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Andrii Kolomoiets <andreyk.mad@HIDDEN> Subject: Re: bug#41531: 28.0.50; proper Eldoc async support References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN> <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN> <m2lfl21wsq.fsf@HIDDEN> Date: Fri, 05 Jun 2020 23:53:49 +0100 In-Reply-To: <m2lfl21wsq.fsf@HIDDEN> (Andrii Kolomoiets's message of "Thu, 04 Jun 2020 22:00:05 +0300") Message-ID: <87k10ljf9e.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Andrii Kolomoiets <andreyk.mad@HIDDEN> writes: > Dmitry Gutov <dgutov@HIDDEN> writes: >> On 04.06.2020 19:20, Andrii Kolomoiets wrote: >>> 3. That IMO useless "...truncated, see*help* buffer" message is moved >>> to Eldoc. Do we really need to show this message every time? That one >>> last line can be used to show additional documentation. >> The truncation can be indicated as ellipsis at the end of the (first) >> line. Maybe ellipsis in parentheses (...). > > Good idea. I think is is easily missed, and will not inform of the keybinding for `eldoc-doc-buffer'. But it's clearly better than nothing for the strictly-one-line people. >> Whether to use multiple lines of not, seems like individual preference. > > Absolutely. That's why there are customizable variables so anyone can > tweak behavior to their likes. Current version of Eglot pays attention > to the eldoc-echo-area-use-multiline-p variable and proposed one do > not. It does not because most of that variable (except for the very special "truncate-sym-name-if-fit" value) is now handled in eldoc.el. Modulo bugs, of course, which I will endeavour to fix. I also agree, of course this is individual preference.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 18:17:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 14:17:20 2020
Received: from localhost ([127.0.0.1]:49899 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jhGu7-0006du-GD
for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 14:17:20 -0400
Received: from mail-40134.protonmail.ch ([185.70.40.134]:16436)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <theothornhill@HIDDEN>) id 1jhGUc-0003xO-1z
for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 13:51:02 -0400
Date: Fri, 05 Jun 2020 17:50:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail;
t=1591379451; bh=XKCZNxRwaLTFmCroMCzwpX5+zs0jeepoY5zA0OiEKwA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=CMlqp/RC6WQ5AoOQzr6hUtqmqA3JHXBvpZJpVZMs8SU5tnP4pJ87u9e/Ic0UGpBL6
kB56V9b7tMVGhq50k7iwPpqG8JIWADhVBiZbLVEynX3UbcmkVHCcktYV5t8ue5Y/Qj
lHPR2VdYwn+kye/8UyMFiiYdRoNWe6GEQEqGUDcxx3LPfhXLdAZeF6Mg6SHsqqmXSh
wfyOIVp2LIW6WOCFspcSOwFagFoL4Q/gCr2/mszj//PwChV9w0+FAEGwRFb/FPl9Bq
RYxStUbsXwdqBUFisG8gKBywFq+fmsrmauOi9vPLy7Mf71htJBg5ZXTCk9X9XwSoSi
ID5mRtMRDklSA==
To: =?UTF-8?Q?Jo=C3=A3o_T=C3=A1vora?= <joaotavora@HIDDEN>,
Andrii Kolomoiets <andreyk.mad@HIDDEN>
From: Theodor Thornhill <theothornhill@HIDDEN>
Subject: Re: bug#41531: 28.0.50; proper Eldoc async support
Message-ID: <87img55rmm.fsf@HIDDEN>
In-Reply-To: <87img5lqty.fsf@HIDDEN>
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
<87img5lqty.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no
autolearn=disabled version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 41531
X-Mailman-Approved-At: Fri, 05 Jun 2020 14:17:18 -0400
Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org,
Fredrik Bergroth <fbergroth@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Theodor Thornhill <theothornhill@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
Hello!
Thanks for pinging me -
I tried it, and it looks pretty cool. However, I noticed a few bugs.
(When using both the new eldoc and eglot):
Bug 1: =20
1. Open a file
2. Start eglot
3. Hover something with "C-h ."
4. Switch to the new window that popped up.
5. C-x k (kill buffer)
6. Repeat step 3.
7. "invalid buffer" and eldoc is dead.=20
8. Starting and stopping eldoc doesn't work =20
This seems to happen since it uses the new buffer and updates it. When that=
buffer is deleted, it gets confused.
Bug 2:
1. (setq eldoc-echo-area-use-multiline-p nil)
2. eglot spits the whole thing on one line. This looks a bit weird since it=
uses both the signature and the documentation.
This may not be a bug, but right now IMO it looks a bit strange.
Bug 3:
1. "M-:"
2. Type "("
3. Minibuffer shows: eldoc-error: (wrong number of arguments (0 . 0) 1)
I think the first bug is the most problematic one though :)
However, I've started to take a liking to the no options set, with this ver=
sion. I think I like the "truncate, press M-x ..." message more than the pr=
evious one.
All the best,
Theodor
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> [ Theodor and Fredrik, adding you since you were also interested in this
> Eglot/Eldoc matter. You can review the messages in the bug list if
> you're interested: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531=
]
>
> Andrii Kolomoiets <andreyk.mad@HIDDEN> writes:
>
>> I was planning to remove the eglot-put-doc-in-help-buffer variable in
>> the near future PR as well as the use of the eglot--message function for
>> the documentation display ;-)
>
> I'm guess I'm happy to have shot these plans into the depths of the
> ocean ;-)
>
>> However, after briefly using new Eldoc and Eglot I found some issues
>> that, I hope, we can fix:
>>
>> 1. Display only first line of the hover info. Again :-)
>
> You should be able to do this with either
>
> (setq eldoc-echo-area-use-multiline-p 1)
>
> or
>
> (setq eldoc-echo-area-use-multiline-p nil)
>
> Did you try this? If so, what exactly didn't work for you when you did?
> I'm sorry if you've already given me this information in the multiple
> PR's you opened about this, but let's have it again.
>
>> 2. The hover info is sometimes displayed right before the signature info
>> making the echo area to "blink". I suppose this must be fixed on Eglot
>> side by not requesting both the hover and the signature infos at the
>> same time.
>
> Not something to be fixed in Eglot, definitely, it's not its fault or
> responsibility: it just reports whatever it has. I've fixed this in
> Eldoc, in the last commit. It only affected the "eager" strategy (which
> should really be called the "enthusiast" strategy). I'll post a commit
> soon using better names for strategies, I'm thinking:
>
> eldoc-documentation-function -> eldoc-strategy (with obsolete al=
ias)
> eldoc-documentation-functions -> eldoc-functions (maybe)
>
> eldoc-documentation-default -> eldoc-patient
> eldoc-documentation-compose -> eldoc-compose-patiently
> eldoc-documentation-eager -> eldoc-enthusiast (Eglot uses this)
> <doesn't exist yet> -> eldoc-compose-eagerly (Stefan mentioned=
this)
>
>> 3. That IMO useless "...truncated, see *help* buffer" message is moved
>> to Eldoc. Do we really need to show this message every time?
>
> I see. Maybe not _every time_ but at least _once_, I'd say. Once per
> Eldoc session (but what is an Eldoc session)? Once per x truncated
> messages? Customization variable? (I hate those, but maybe).
>
> Or maybe never show it?
>
>> That one last line can be used to show additional documentation.
>> Hadn't a chance to take a closer look at the code, so reporting those
>> issues is the most I can do for now.
>
> Yes, and that's fine for now, though a second pair of eyes in the code
> is certainly appreciated too.
>
> Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 11:26:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 07:26:49 2020 Received: from localhost ([127.0.0.1]:48410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jhAUr-0006zl-BZ for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:26:49 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:37543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jhAUq-0006zZ-77 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:26:48 -0400 Received: by mail-wm1-f48.google.com with SMTP id y20so1021393wmi.2 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 04:26:48 -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=xxOYCOM/ZtKjqtBwBmFlfl3dHatjIzR/tty1FP0Lqns=; b=rFXJ6RcA5J5E2DDR0990Bxab2sYYxZa50ykwOdkXoBBP0fd1gEQCUp/3OcaQFyxdlt UZKBAlN6owK/360/fxwn3WW7hS+a3pdc9BWAfN6Z2+Vlg2crLLIzZo5uFNOP3MwIPNvf nEnXSAjBeitXkR6fuOwYjfYlcks1wkYCZQcUX46vqqqRSOfSYWziCj9q8hhDB5qL8y+x YpPuIDOOVwJ6CQ5JFogpzpAWBhJh+nTSD0ZuG3CU4pMUELC96Thp9EM+1yUgKsnNs3tA NeUEGuhY9o77apByP2P7WAWnS/NGCko1GZzbvIFGAPtkLSEG3zsex2cyHf2PFP/HwUJW 9r+g== 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=xxOYCOM/ZtKjqtBwBmFlfl3dHatjIzR/tty1FP0Lqns=; b=HsX1b1y5/KVeYaxc90E6ddY8/aa4HjIv6mIu/xUn7fuuiVwmmJ0F6tbdWj/I30428c Qy5sxsBWFWIGbTJ0fwDKPnzA1xVqhAYhS/90fqdMC30vfm76EB6dL4DzBBSNRKxhsg0r umowwvl/pwYHZhT8hOc8ywb+9iDblJJ7dZ+LYzTywzP6Ov/Eo+/XVzi+5l1bGQcO3UbI IdlSyfQnBqWP/I6YbiqhziN4pQjTz3QHgEa7q0lYS/0lrafruZLk0QkNKig1JC83en3c mWjjjBORG0aVy4xnFGcZjvt/Wsk3u86hhn4Z6EYYMomQlSBx5QDvPafwZFUwD7rBnBd4 KRFQ== X-Gm-Message-State: AOAM531vF/rM7o6NV/U9V+cbVaSiveKgmFYj1OVE4ie3EfXBh3zIWHrA 5JV1XLwcyIsjkYDl/qL/EfU= X-Google-Smtp-Source: ABdhPJyniLwZjerjcKrfb4szY3j8bwRIg6L139GRXC9Lv962JLpFdIrSTAZcp7m6RkgUAr8V03txgw== X-Received: by 2002:a1c:6244:: with SMTP id w65mr2249800wmb.82.1591356402127; Fri, 05 Jun 2020 04:26:42 -0700 (PDT) Received: from krug ([89.180.149.24]) by smtp.gmail.com with ESMTPSA id r2sm12565802wrg.68.2020.06.05.04.26.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 04:26:39 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN> <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN> <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN> <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN> <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN> <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN> <877dwnnaxx.fsf@HIDDEN> <jwvmu5jyhm2.fsf-monnier+emacs@HIDDEN> Date: Fri, 05 Jun 2020 12:26:37 +0100 In-Reply-To: <jwvmu5jyhm2.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Wed, 03 Jun 2020 17:21:53 -0400") Message-ID: <878sh1lpn6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: >>> 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). > Great. Indeed, I can see 3 eldoc sources for emacs-lisp mode, in this order: - function signature - docstring - special variable value If emacs-lisp-mode one uses the default display strategy (eldoc-documentation-default or some rename of that) and sets eldoc-echo-area-use-multiline-p to 1, it should be fully backward compatible to the current behaviour. Alternatively, we can have emacs-lisp-mode keep out of eldoc-echo-area-use-multiline-p and use 4 sources: - function signature - one-line docstring - special variable value - remaining paragraphs of docstring ( At some point, if we compose all of these bits of information in the volatile *eldoc* buffer, it will start looking a lot like *Help* for C-h o, There's some integration work to do there, but I'd rather not open that can of worms just now. ) >>>> 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)). > > I find the difference largely irrelevant. Much more important is > what kinds of :foo and bar are allowed and what they do. I agree. Content is more important than style. Of course style matters, too. Occasionally, it matters overwhelmingly. But not here. I'd say. The promises-vs-callbacks discussion is a matter of style. >> 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. > > Sounds very good. Changing its name will make it possible to fix the > current backward-incompatibility (which we'd fix by re-introducing a(n > obsolete) eldoc-documentation-function). Yes, that's the plan. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 11:01:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 07:01:12 2020 Received: from localhost ([127.0.0.1]:48380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jhA63-0006MO-VX for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:01:12 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:41912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jhA5y-0006Lt-Kw for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:01:10 -0400 Received: by mail-wr1-f48.google.com with SMTP id j10so9286158wrw.8 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 04:01:06 -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=y7nSKXsjG4BSOHM8rqvk+w+CFeR9SniJOhZn0MnTosI=; b=iCak68Ljf7d9T8hu4hBmCLL9+n76zFUxREb4qwQZ/eCBts9z97B8jcivlg9c6/XcqX oJzdsiLSiy7jidf2xwsd1EF44cXHiTH8/2bS528khqDPZxLNVrZ49QRZw8WoGRt+210z LmEAhmrZO0kgrRRXeb1Di7Bu03XGqR8AL1inlbQGx3CvWoONS3n/jkhwESUCxR9meyhH LEQiw75X7Pr2erQRcMQ/Qw1/ZOE4W8Om94xYfpk0vXxSEmEy9t8/3Tc5bPW+SxV66sdP g7wQocjsq62j378JWy45HSqe0JhDfU6+JKLCvoPrTPB2dw/VwJv+e9aRcis3higEUasF /9nA== 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=y7nSKXsjG4BSOHM8rqvk+w+CFeR9SniJOhZn0MnTosI=; b=HqOlSaOJk29/T2++Gs5jWSQsSYJ7aQpRXhdoGyMdc0QM1Iayt1ig1FtQdLhe54thIR j7L/0cha8eN+ImLqqoQV0Gc31r9pdfuvRZVruy2l7bCODMqdxpSthiW+HoqugT8vIQk5 DJQO3XbEpKmSXa/SZYctMPgU0K1UMf/cUAxK6vGTDsVIt3XoKQHE9wX7KI8E+3RtHEVB FzNJN/0HiLvhNriwBlCUNNozac6kz68ne/0dcn0sbxwgrOhZE4hLhILIVW/dfVxBJGyq uIwz1gCW1BRx0vrnK2hxyhtCOgpgVDAB2MI0y1DjyUDT0efMQpQ6HIBUW84vmu/aa2mL qW+w== X-Gm-Message-State: AOAM531EvtmU4AnzoYGXLSzllqNbsxI/IxiTTfAyQxPlAVWcJgP6UTsm pIXd/kUfK5PTTKEK71THR/8= X-Google-Smtp-Source: ABdhPJzQaKCDxC9MMXDOK8GZeSoRSzZloH6XtDuRdAPwI/Vg2AYpipZwHWMG64Posqbw6GafXRzn7g== X-Received: by 2002:adf:f58b:: with SMTP id f11mr9021417wro.155.1591354860719; Fri, 05 Jun 2020 04:01:00 -0700 (PDT) Received: from krug ([89.180.149.24]) by smtp.gmail.com with ESMTPSA id 1sm10984852wmz.13.2020.06.05.04.00.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 04:00:59 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Andrii Kolomoiets <andreyk.mad@HIDDEN> Subject: Re: bug#41531: 28.0.50; proper Eldoc async support References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN> Date: Fri, 05 Jun 2020 12:00:57 +0100 In-Reply-To: <m2pnae2462.fsf@HIDDEN> (Andrii Kolomoiets's message of "Thu, 04 Jun 2020 19:20:53 +0300") Message-ID: <87img5lqty.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, theothornhill@HIDDEN, mvoteiza@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, Fredrik Bergroth <fbergroth@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) [ Theodor and Fredrik, adding you since you were also interested in this Eglot/Eldoc matter. You can review the messages in the bug list if you're interested: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531] Andrii Kolomoiets <andreyk.mad@HIDDEN> writes: > I was planning to remove the eglot-put-doc-in-help-buffer variable in > the near future PR as well as the use of the eglot--message function for > the documentation display ;-) I'm guess I'm happy to have shot these plans into the depths of the ocean ;-) > However, after briefly using new Eldoc and Eglot I found some issues > that, I hope, we can fix: > > 1. Display only first line of the hover info. Again :-) You should be able to do this with either (setq eldoc-echo-area-use-multiline-p 1) or (setq eldoc-echo-area-use-multiline-p nil) Did you try this? If so, what exactly didn't work for you when you did? I'm sorry if you've already given me this information in the multiple PR's you opened about this, but let's have it again. > 2. The hover info is sometimes displayed right before the signature info > making the echo area to "blink". I suppose this must be fixed on Eglot > side by not requesting both the hover and the signature infos at the > same time. Not something to be fixed in Eglot, definitely, it's not its fault or responsibility: it just reports whatever it has. I've fixed this in Eldoc, in the last commit. It only affected the "eager" strategy (which should really be called the "enthusiast" strategy). I'll post a commit soon using better names for strategies, I'm thinking: eldoc-documentation-function -> eldoc-strategy (with obsolete alia= s) eldoc-documentation-functions -> eldoc-functions (maybe) eldoc-documentation-default -> eldoc-patient eldoc-documentation-compose -> eldoc-compose-patiently eldoc-documentation-eager -> eldoc-enthusiast (Eglot uses this) <doesn't exist yet> -> eldoc-compose-eagerly (Stefan mentioned t= his) > 3. That IMO useless "...truncated, see *help* buffer" message is moved > to Eldoc. Do we really need to show this message every time? I see. Maybe not _every time_ but at least _once_, I'd say. Once per Eldoc session (but what is an Eldoc session)? Once per x truncated messages? Customization variable? (I hate those, but maybe). Or maybe never show it? > That one last line can be used to show additional documentation. > Hadn't a chance to take a closer look at the code, so reporting those > issues is the most I can do for now. Yes, and that's fine for now, though a second pair of eyes in the code is certainly appreciated too. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jun 2020 19:00:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 04 15:00:16 2020 Received: from localhost ([127.0.0.1]:47456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jgv68-0007xD-HV for submit <at> debbugs.gnu.org; Thu, 04 Jun 2020 15:00:16 -0400 Received: from mail-lj1-f181.google.com ([209.85.208.181]:35320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <andreyk.mad@HIDDEN>) id 1jgv66-0007x0-9C for 41531 <at> debbugs.gnu.org; Thu, 04 Jun 2020 15:00:14 -0400 Received: by mail-lj1-f181.google.com with SMTP id c11so8703036ljn.2 for <41531 <at> debbugs.gnu.org>; Thu, 04 Jun 2020 12:00:14 -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; bh=nEAW7cNI0vce7xeF6xKwIpahbcZqX19u3MNRMWja/AE=; b=ahuyVn3T3Z7Ti0r0ramN3OsoWG0smAwaTVu4yJakGYG+By/+jAsJ/dHmAxCaANZEd/ otSZ5P7AefPMlpqj1NarEAROJ18inqTN90xncB6L8r0reIedLI2Ux26FF5Vq3jrx85rj 9Pi4+TgZFRrGwPquM9LLh3X7hjH/PabGmqIYcgUPdlK8OjSwW/0/FIGFpep1cZPERK5A /q6kSr6qJEzQYgCclAb1kXmrZ6q+rvKrN6yo2qt/Il9RKqvf1g0aK+Oiag1Fq9RmAyiU wE4O/9tbgs1d6++TetBmnFLhX2pSFeIu8HMBv7ZSUZvNmfyhM6SREv9HT+4iczu2foBC +npA== 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; bh=nEAW7cNI0vce7xeF6xKwIpahbcZqX19u3MNRMWja/AE=; b=g40H6QAmgCEJixMyvoHPPIl7wX8fOcPxnjVEi9DnpdZHMQIvEC8w0/T66XE3jA+tFg qiPcwqa4MIF6GWMIFnlNe3m3oNaZUIKo+55Y1+K8qYkMF8c+ltXB1QVlCixLKwP9tP7f PBU0OjHaB/VF/TDnFlRdjMYJqwL2ZFpUKCgiCmLFQNT89SP25yzYUydD/veJgvFb7POx YJ5OyRpybqJ4NeP4VbWNw2FOEFTbRzZV42+U+mgyRqshdwRlQ7Wft/bo/wlyFkN5wr8F mf1kpSNBdXsTlJUCJIsjtJnAP1GoT67pBzIFcjn+xI7R0gWmBnqvgKOD/RJoLdv88QsT gOCA== X-Gm-Message-State: AOAM530qaFB1FbZ4iLgujZv1qi9mRdvr9+eyJRHczv+Ls7XBPrxd4xtb 31GmACdfG/L+rYyBnczdXU8= X-Google-Smtp-Source: ABdhPJyowZxPZCik7fn/9TU0mkAYTp150YVe2k2ezyhCcugt/+sKLL+wAvSCpujjDP3MySZ03E5QWQ== X-Received: by 2002:a2e:9586:: with SMTP id w6mr2793711ljh.274.1591297208049; Thu, 04 Jun 2020 12:00:08 -0700 (PDT) Received: from muffinmac.local ([91.206.110.130]) by smtp.gmail.com with ESMTPSA id 130sm106982lfl.37.2020.06.04.12.00.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2020 12:00:07 -0700 (PDT) From: Andrii Kolomoiets <andreyk.mad@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 28.0.50; proper Eldoc async support References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN> <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN> Date: Thu, 04 Jun 2020 22:00:05 +0300 In-Reply-To: <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN> (Dmitry Gutov's message of "Thu, 4 Jun 2020 21:22:00 +0300") Message-ID: <m2lfl21wsq.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 04.06.2020 19:20, Andrii Kolomoiets wrote: >> 3. That IMO useless "...truncated, see*help* buffer" message is moved >> to Eldoc. Do we really need to show this message every time? That one >> last line can be used to show additional documentation. > > The truncation can be indicated as ellipsis at the end of the (first) > line. Maybe ellipsis in parentheses (...). Good idea. > Whether to use multiple lines of not, seems like individual preference. Absolutely. That's why there are customizable variables so anyone can tweak behavior to their likes. Current version of Eglot pays attention to the eldoc-echo-area-use-multiline-p variable and proposed one do not.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jun 2020 18:22:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 04 14:22:10 2020 Received: from localhost ([127.0.0.1]:47443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jguVF-00071t-W1 for submit <at> debbugs.gnu.org; Thu, 04 Jun 2020 14:22:10 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:35033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jguVE-00071h-O6 for 41531 <at> debbugs.gnu.org; Thu, 04 Jun 2020 14:22:09 -0400 Received: by mail-wr1-f44.google.com with SMTP id x14so7197526wrp.2 for <41531 <at> debbugs.gnu.org>; Thu, 04 Jun 2020 11:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KP+9kffa5YgPItx7lC94yw053wFlSHcqj3JEKcZBYWw=; b=eSZWQgpBL7X2EmP1SSF+mLrKxIl3Qp+CzenlnNUC4t5ZO580wB78mCSpQfrXvBxOEQ UF61Uh8gdw6Q3ISn3Weu0RDcQIepjusxbWRpvav4c+5fdhNzIYkIe3X/pw6p1QqjD7vB ThA+BaF8u7nJxfGEphPowhM3uhDBjh67v3HLpusRr00kXMz3T89IGf71TnHR6Q10ikdu nmrfTMgfbYAdQ+lyTILnqQlJx/7H34SHijp995H0KxLeK3hH72Yw0CM3qmh/9IUrMKrm JRYrBTxtecESzYEA1M2Bp+4WRtyeuwOp2KXS0J3vpibZ4yB6qvOqQ+V4FnUVUUAwb4NN EFzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KP+9kffa5YgPItx7lC94yw053wFlSHcqj3JEKcZBYWw=; b=rEJTnSiXTAfftrnXUujkvNLzEQrZAjyj4idTTDm/W9nwh7I402tFHb/gRnK2K7NOGj mquN8y7500shhG3bGufAm/svASo/hk3u6uVJZgaWlF9XyebmM2Ac6qHpr/Dc8yEev6Uy z+9dPhxJ45QoXBH1EbLhuDQcr6nVQysCMYRc4b8gz/w9iSV/1RPp2c4v0aY6BsoeekFy YcgGPkLYMTjdYeH4hmOx/Z1BYNrNaFIBedF5ptH0WEZDEx7nRDCsaP3hEydrnLJP/oCZ NjWjcnJJRJL3ioN7fIiLNvkg0km730OFXDdJqix3NSMIrnn/mAK+s3VDyvFFWAOz49WH gVUg== X-Gm-Message-State: AOAM533v+Wh8Wh92aKGUL/gx5m51toRCtU4RqW1Wfp5zdVEVRZ7ULVVk LHGVIr9s631Wc1fogPvzhYc= X-Google-Smtp-Source: ABdhPJwXQgyA4NikxiC1tUmqcJsxrB8KXliYCj+YW/0X7CnEt4GJFoxic43Y4hFfQNJguN1uxILNjg== X-Received: by 2002:a5d:61d0:: with SMTP id q16mr5970488wrv.182.1591294922877; Thu, 04 Jun 2020 11:22:02 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id q5sm9093843wrm.62.2020.06.04.11.22.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 11:22:02 -0700 (PDT) Subject: Re: bug#41531: 28.0.50; proper Eldoc async support To: Andrii Kolomoiets <andreyk.mad@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN> Date: Thu, 4 Jun 2020 21:22:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <m2pnae2462.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41531 Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 04.06.2020 19:20, Andrii Kolomoiets wrote: > 3. That IMO useless "...truncated, see*help* buffer" message is moved > to Eldoc. Do we really need to show this message every time? That one > last line can be used to show additional documentation. The truncation can be indicated as ellipsis at the end of the (first) line. Maybe ellipsis in parentheses (...). Whether to use multiple lines of not, seems like individual preference.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 4 Jun 2020 16:21:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 04 12:21:08 2020 Received: from localhost ([127.0.0.1]:47359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jgsc8-0001rd-2G for submit <at> debbugs.gnu.org; Thu, 04 Jun 2020 12:21:08 -0400 Received: from mail-lj1-f177.google.com ([209.85.208.177]:42733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <andreyk.mad@HIDDEN>) id 1jgsc2-0001qm-Pm for 41531 <at> debbugs.gnu.org; Thu, 04 Jun 2020 12:21:06 -0400 Received: by mail-lj1-f177.google.com with SMTP id y11so6400611ljm.9 for <41531 <at> debbugs.gnu.org>; Thu, 04 Jun 2020 09:21:02 -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=a5XQyh4Jm1hMe8Xdtol2G2P1KkSyxrWcA4gLfuCFPq8=; b=Ia3PjM584cX6Y9LmEwPkl8eNikkHZAZwe0n0A08l7eKIhOh/h38p4U1DNIx2xiQpMO yRWGsk7z77cO8GCIFU0OQVbbmS7A853+S/+Xuq36EDsKGLxjZFoUTTqqkfqvIXwSeZZ3 /g9WKrBztDns6iuO1nzblLen2NFrQJ321O7UlO42njNworKBDGYpA570rAkzfTkX2x8w L0U3J96vuME2LiZJIxD4oEFYXRFZcYLU79VMu5/pMZ53UhJ5TaFHfZ3esj8ynp/aEwbj LCS+3g32UHKx4G8D9ZJT8+m6AVs6spHzKJlEqB1G/60ffKpq1dd+IYiXrYU28JuD94o7 WBoQ== 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=a5XQyh4Jm1hMe8Xdtol2G2P1KkSyxrWcA4gLfuCFPq8=; b=aQ7UY/XshHKfxgsuDjQ9pihpbfq99n4vIUWGSfM/cYWOC5lWPfhxaeq680Csi6FPYn 1mSBWtF67nGCEbVglb7UYkA0JOwu70Zzo1qZETaE+nfPLZl9Rx6UN5OOXumnw2meEeHm 67WJJ/PZWt24e/kUNXonYNQ6xm341fdipod6m4ZSbMdRTLSCg1clNpJIITECHEIyrn7J ahoUlG7oiu4Lwt23gTr2PkRm3QK5Vsh8CGvG5l+ofUQv9/oe5FG/Jtlx3IM5aVa2Kv6V qKRjkBFnxPN7TfNk362aSwlqxE2skIGP1SzJEsBlgBosCzAzC3yRaGV72pp03h7UVg+g nlOg== X-Gm-Message-State: AOAM530gTfTQ30Fvnwz3joSXLQKAeLIrBWbHtuCJJ0m7+hy2PMJAvWb/ NwTomBsUq6+X6awU2JK24kOAU6gxnmQ= X-Google-Smtp-Source: ABdhPJxC6b6OJoUT1f05daJkBbnO7i0bJB7LOYZQ/zrZlMbNBFiUGf5FwqU23peA3QAfR1GWBK16Jg== X-Received: by 2002:a05:651c:93:: with SMTP id 19mr2614955ljq.245.1591287655744; Thu, 04 Jun 2020 09:20:55 -0700 (PDT) Received: from muffinmac.local ([91.206.110.130]) by smtp.gmail.com with ESMTPSA id f22sm13169ljn.28.2020.06.04.09.20.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2020 09:20:54 -0700 (PDT) From: Andrii Kolomoiets <andreyk.mad@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#41531: 28.0.50; proper Eldoc async support References: <87eeqwm101.fsf@HIDDEN> Date: Thu, 04 Jun 2020 19:20:53 +0300 In-Reply-To: <87eeqwm101.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Wed, 03 Jun 2020 19:56:46 +0100") Message-ID: <m2pnae2462.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Hello again gang, Hi Jo=C3=A3o, > When applied, these improvements result in a substantial reduction of > Eglot's documentation handling code. Yes, Andrii, that means all our > hand-crafted, hard work of doc handling functions is soon gone, > including the awkward eglot-put-doc-in-help-buffer, > eglot-auto-display-help-buffer and the *eglot-help* buffer. > > Feels sad but also good, because deleted code is good code. And it's > not in vain because your feedback and testing was fundamental here. And > the good news is that the logic problems about blinking and giving > priority to some docs is gone. I for one completely support moving documentation handling code to eldoc. I was planning to remove the eglot-put-doc-in-help-buffer variable in the near future PR as well as the use of the eglot--message function for the documentation display ;-) However, after briefly using new Eldoc and Eglot I found some issues that, I hope, we can fix: 1. Display only first line of the hover info. Again :-) 2. The hover info is sometimes displayed right before the signature info making the echo area to "blink". I suppose this must be fixed on Eglot side by not requesting both the hover and the signature infos at the same time. 3. That IMO useless "...truncated, see *help* buffer" message is moved to Eldoc. Do we really need to show this message every time? That one last line can be used to show additional documentation. Hadn't a chance to take a closer look at the code, so reporting those issues is the most I can do for now. Thanks!
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 21:28:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 03 17:28:31 2020 Received: from localhost ([127.0.0.1]:44667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jgaw3-0002sy-BO for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:28:31 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:38154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jgaw1-0002sl-RX for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:28:30 -0400 Received: by mail-wm1-f42.google.com with SMTP id f185so3573161wmf.3 for <41531 <at> debbugs.gnu.org>; Wed, 03 Jun 2020 14:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ip3L0ljstINhrnBI9r2Hf6N5g9/HQnfrIAic3dVZISQ=; b=ZZX1VvifS3QbPrYe8hScB4YUZbUA01eQIANh5nS8Knlr4RQi64Dr7Q6Tr689+dXu53 E97+wFWdikI5xK7a4PDouDZ81P8okyKfmnuewds+WSBFnk5iaa5aGav7oJ72zA/JCilm jNRruWGE2eZUfYucOvL+vMHJM7oYQK2AmAHUMXPfBYhWgf7Gg7tX5PZF529kJv7F80P+ mefmyQ+ETZipJMGmn9Gn7GJ3CmtGOwETpyzcU1bjXNp8MmpyFEMRE0zXsRHeRfDAswKA C/9bpMaYm9FfOo/aVdehjHGIJRiMg1IUPqyu8piyd8eyIW/HqyCb1O0IcUDZbB0UdA8w c8Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ip3L0ljstINhrnBI9r2Hf6N5g9/HQnfrIAic3dVZISQ=; b=GTeL5xdKqJl5BiM+tAX2YopSUGWpD2t4OwryvJ1O/hABOcWloWzh67qPt7gUt9Q5+L fuiR5eXqiZmq7B3zwVAM3a2LgGFfpajdtfkzSaAVVx6X5kz0uvlcNKI1wPJeZbAquEd/ mLzpPeBg2wmpqXZKfZeUUIxukUh5sz4VZVPjwdlevJQkngBMkyav0AY0lUPcxI1RWNRu HwNy2SS+aiqWUt54r8ZY5KEj7NkcYdosRn+cFdX7klZSKFZBJpYb2Pv72hahBhCZvPSI e5l8zEUz2+aBVPjIQ3O65D+Sus1Eo1ooQs/ecv8ujzsJfxJQPpRlT8/CMAIg3zLiMxpQ Pbeg== X-Gm-Message-State: AOAM530p9d4GhJtq+RegRJ3U+bD286aBTzW0bqZk3yg5rjJcJ9FZ21Q7 W/u6zEgmCtUCcSxLIoApdIhAvXt5 X-Google-Smtp-Source: ABdhPJzB/XdBrL/bxXj8iLCr5obaEOr8xxBFhwCzvv5b8tIuh9yfuphFxC+LFMbNzg2DTrg1+TDBmA== X-Received: by 2002:a1c:8048:: with SMTP id b69mr901662wmd.169.1591219703637; Wed, 03 Jun 2020 14:28:23 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id l1sm6026133wrb.31.2020.06.03.14.28.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 14:28:22 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN> <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN> <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN> <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN> <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <6d309720-ab64-0311-50b6-c50b7b7bfa15@HIDDEN> Date: Thu, 4 Jun 2020 00:28:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <875zc8nhue.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41531 Cc: Christopher Wellons <wellons@HIDDEN>, andreyk.mad@HIDDEN, 41531 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 03.06.2020 21:07, João Távora wrote: > The equivalent in futures is just to say clients can set the value nil, > or some other application-specific indication of "sorry, I failed". They should call 'eldoc-future-set-error'. One design point I'm not sure of, is whether the argument should be a string (coming from the error message), or a "proper" exception/error object, previous captured inside a condition-case. We might make that choice just based on whether url-retrieve passes the same kind of data as, say, error-message-string expects. The same "proper" object, that is.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 21:22:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 03 17:22:07 2020
Received: from localhost ([127.0.0.1]:44662 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jgapr-0002kE-LA
for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:22:07 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19342)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jgapq-0002jk-1r
for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:22:06 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 63A9F4413B7;
Wed, 3 Jun 2020 17:22:00 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 95A024413B3;
Wed, 3 Jun 2020 17:21:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1591219314;
bh=TvARp4dfsdq7aherZgSKK3BVroL7isR+Gvy87oTB8qU=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=O8/7GKR3w72yAIkNWQfirMVD3BRY5Q1R6a003yTKMveQ2RFFBM7P86U0bx5mQy+7v
DzynAnqkrYpCGB7SMuXwZDYTD4ZTDNkuq7DoO3Bh/c5ws/0AswuNriCrpWcDv+WxmC
o57a/Af0bb61h3cplKlA6G7sGH7TDHg6fWCkUnpIxd0CTlQZ4b5UV4uuIUFriHrJna
Yl7WlzIrH+NjfUU+Rce68ozl95hJkawBA/WA9nV6axMMkR3s0GLEpPordClO67Yv0L
ceaJoCH8YDV/BgBeAn5YezLCZcjce4Ks0Me0clGtXKftWGLWkOy7/k16f3OuJub42l
nMMTS5/3DNZxg==
Received: from alfajor (76-10-137-254.dsl.teksavvy.com [76.10.137.254])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EDE171206C3;
Wed, 3 Jun 2020 17:21:53 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvmu5jyhm2.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
<jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
<jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
<jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN>
<jwvy2p3ykko.fsf-monnier+emacs@HIDDEN> <877dwnnaxx.fsf@HIDDEN>
Date: Wed, 03 Jun 2020 17:21:53 -0400
In-Reply-To: <877dwnnaxx.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Wed, 03
Jun 2020 21:36:42 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.072 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org,
andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> 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).
Great.
>>> 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)).
I find the difference largely irrelevant. Much more important is
what kinds of :foo and bar are allowed and what they do.
> 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.
Sounds very good. Changing its name will make it possible to fix the
current backward-incompatibility (which we'd fix by re-introducing a(n
obsolete) eldoc-documentation-function).
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 20:36:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 03 16:36:53 2020 Received: from localhost ([127.0.0.1]:44639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jga84-0001hQ-UD for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:36:53 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:36881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jga83-0001hD-Pg for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:36:52 -0400 Received: by mail-wr1-f43.google.com with SMTP id x13so3787006wrv.4 for <41531 <at> 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) 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) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN> <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN> <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN> <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN> <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN> <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN> Date: Wed, 03 Jun 2020 21:36:42 +0100 In-Reply-To: <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Wed, 03 Jun 2020 16:22:44 -0400") Message-ID: <877dwnnaxx.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: >>>> + "<WORLD CLASS DOCSTRING>" >> Ahem. >>>> + "<WORLD CLASS DOCSTRING>" >> 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
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 20:23:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 03 16:23:01 2020
Received: from localhost ([127.0.0.1]:44618 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jgZuf-0001M8-Ib
for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:23:01 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16376)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jgZue-0001Ld-0k
for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:23:00 -0400
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)
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==
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)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
<jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
<jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
<jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN>
Date: Wed, 03 Jun 2020 16:22:44 -0400
In-Reply-To: <875zc8nhue.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Wed, 03
Jun 2020 19:07:37 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.001 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org,
andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> + "<WORLD CLASS DOCSTRING>"
> Ahem.
>>> + "<WORLD CLASS DOCSTRING>"
> 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
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 18:56:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 03 14:56:56 2020
Received: from localhost ([127.0.0.1]:44556 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jgYZM-0007gN-3C
for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:56:56 -0400
Received: from mail-wm1-f46.google.com ([209.85.128.46]:51523)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jgYZL-0007g6-2W
for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:56:55 -0400
Received: by mail-wm1-f46.google.com with SMTP id u13so2936072wml.1
for <41531 <at> debbugs.gnu.org>; Wed, 03 Jun 2020 11:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:date:message-id:mime-version
:content-transfer-encoding;
bh=Za6Xfh8TpSblVWbnvn+Ep7XieO81rpeTYCKxycWgDHY=;
b=pot5BMIKcgObyqZNJ5b4lM6rJra6NLsMb2VEVYljDGaoAjBV10HBaR4SBWdKyzsj9Y
HHkP1khwnWs6wgNqhM5JVO3tp2/LD+8pxw8TGgvfTvk6MIA7a1Mre+tp92HjYobi87jC
wiZAJVUai6ASHzBrtuw5I6K/EOxAL5vA7WTRiQ00Kgiq0sQesl24MJS65+NhR0uTR2jG
2OLPvb22XQ7U7kpt9uCcErLB+a8WzbB1US0sHQocjR6UI+WLo7Xco2f8/YMRaU7gJHm8
i3u8PeCMhG42lNBWYDNViJgWR4MS7IUdykR9+ECowZwF0wRcaDt9isvPAk6mKSroicFo
1IfQ==
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:date:message-id:mime-version
:content-transfer-encoding;
bh=Za6Xfh8TpSblVWbnvn+Ep7XieO81rpeTYCKxycWgDHY=;
b=tqadmucdo+dMwgry2o9HzQ89azytpOVuyHo2SicVws52nEcOchDyr9s82U7/+f+D+t
YNsJhpUWAxHEig/vPX5ayMfdPsnMx1noZnH2yLAA0zWHkc9038uqQS03Rl0XJ8fSgKdQ
RUiZn6HUZR2LGyH/cnFOhvoCs6IfYUSAugtXN4397Zcz/oNFkgNe01xASgJXruYLPjr6
/5TcuNWDrC4PmM9aAsmiY5t4KPSE1yYF4/9LS/0fcfTFNWNNqbzUy9uENxVk1LaR096H
fnPqAO/xIUt2gWAWpq2xTL0h0cbSRPYlfY8IuQ6cDHLCWDpYeJVko0bzn1RRkxAdu/3C
/wgQ==
X-Gm-Message-State: AOAM532E4CIzrpqoaVBLRCktm+kLVH9NaXmJpHsgbBtBaCKD3nXIsHUQ
SGc5DdEhxHIp8T8I0MC+EdZ40UaUyyY=
X-Google-Smtp-Source: ABdhPJwH0iZTKw9fG2+cUPDpY57Idm42mlDvtfuf8h8PDwAM8DVQYcPprKjvL9vldd8NZkrr3HAUxQ==
X-Received: by 2002:a1c:b155:: with SMTP id a82mr521305wmf.46.1591210608543;
Wed, 03 Jun 2020 11:56:48 -0700 (PDT)
Received: from krug (89-180-148-153.net.novis.pt. [89.180.148.153])
by smtp.gmail.com with ESMTPSA id x8sm4606288wrs.43.2020.06.03.11.56.47
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 03 Jun 2020 11:56:47 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, Dmitry
Gutov <dgutov@HIDDEN>, mvoteiza@HIDDEN
Subject: Re: bug#41531: 28.0.50; proper Eldoc async support
Date: Wed, 03 Jun 2020 19:56:46 +0100
Message-ID: <87eeqwm101.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hello again gang,
As you might have seen in emacs-diffs, I have pushed a new
scratch/eldoc-async branch to the Savannah repo. If you don't have this
repo setup you can find the commits here in the meantime:
https://github.com/emacs-mirror/emacs/tree/scratch/eldoc-async
The code, which touches mostly lisp/emacs-lisp/eldoc.el contains the
logical continuation of the improvements I started building two weeks
ago.
When applied, these improvements result in a substantial reduction of
Eglot's documentation handling code. Yes, Andrii, that means all our
hand-crafted, hard work of doc handling functions is soon gone,
including the awkward eglot-put-doc-in-help-buffer,
eglot-auto-display-help-buffer and the *eglot-help* buffer.
Feels sad but also good, because deleted code is good code. And it's
not in vain because your feedback and testing was fundamental here. And
the good news is that the logic problems about blinking and giving
priority to some docs is gone.
There are 6 commits in total, that build on top of each other. In
reverse order
10834f20ec * lisp/emacs-lisp/eldoc.el (Version): Bump to 1.1.0
fe93e5b9d5 Make eldoc-print-current-symbol-info a command
0612bb7ab5 Introduce eldoc-prefer-doc-buffer defcustom
40d45067ba Overhaul and handle (most of) eldoc-echo-area-use-multiline-=
p in Eldoc itself
600b9c0a71 New eldoc-documentation-eager value for eldoc-documentation-=
function
cde8a6ab98 Better handle asynchronously produced eldoc docstrings
And the new version of Eglot that makes uses of this eldoc is here.
https://github.com/joaotavora/eglot/tree/scratch/work-with-new-eldoc
It's important to note that Eldoc remains backward-compatible to all its
previous users.
In eldoc.el, things build on top of existing work, which includes the
reasonably new eldoc-documentation-functions (plural). Earlier, I
thought of this variable somewhat useless, but it's really not. In
fact, it's exactly what Eglot, SLY and other modes are after. Even
emacs-lisp-mode itself could benefit as it's often the case that one
loses the documentation for a special variable just because one happen
to be inside a function call, or vice versa.
eldoc-documentation-functions allows us to split up these two competing
sources of documentation, so thank you Mark, or whomever had this great
idea.
An orthogonal question is how to display the documentation we gather
from multiple sources. That is handled by eldoc-documentation-function
(singular), another variable I had underestimated. In my changes, I
have added a third option to the two already existing ones.
:type '(radio (function-item eldoc-documentation-default)
(function-item eldoc-documentation-compose)
(function-item eldoc-documentation-eager)
(function :tag "Other function"))
:version "28.1")
Eglot defaults to eldoc-documentation-eager, which simulates its
previous behavior. I suggest you see the docstring for each.
Certainly we can have more strategies to combine documentation sources.
Another important development is that now that the display is
centralized, the formatiing can also be. Thus a big part of
eldoc-echo-area-use-multiline-p can be easily honoured in eldoc.el
itself.
But the most complex changes pertain to async backends, such as Eglot's
and some (but not all) of SLY. This is also covered.
On this point, it is also extremely super-important to note that even
though I have NOT used "futures" or "promises" in these patches, the
very same things can be achieved with them, give or take some code here
and there and some head-wrapping around different debugging techniques.
I have NOT focused on the particular async programming technique: I just
used the simplest and most commonly used in Emacs.
Finally, there is a bit of future-proof unused API. Backends can call
the documentation-reporting callback with keyword arguments, such as
`:hint`. But they're not really used yet for anything yet. Some more
sophisticated text formatting in the *eldoc doc* buffer, including
renaming it like Eglot used to do to its *Eglot doc* buffer, is a
possibility.
Another possibility yet, also left unexplored, is for Flymake diagnostic
messages at point to be reported as independent documentation sources.
This is a frequent complain about Eglot. But in fact I think it should
be Flymake-mode itself that adds some function to
eldoc-documentation-functions.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 18:07:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 03 14:07:49 2020 Received: from localhost ([127.0.0.1]:44539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jgXno-0006Xu-Mh for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:07:48 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:55821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jgXnm-0006Xd-06 for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:07:47 -0400 Received: by mail-wm1-f51.google.com with SMTP id c71so2792899wmd.5 for <41531 <at> debbugs.gnu.org>; Wed, 03 Jun 2020 11:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=YhkHaOYvVZReJOV3EtfsOXmD0b1cweClyD2c5FNJIac=; b=YNwNLjLbO9wr/Ou7MsnAIfhYa0FRT5ZB85LeBIDsSl/OSYhRev+/Snqu8rU2KdPFGJ fq9H5vWppxScEOQqGi7tveVxq+io5fSNwFqGQqHj6MS59UVLw5DzyIz54u/f+1bJjMyI uqG3EOLsJIcLugmhb8OPVG9H6/sKs7s9o1shMa6MjHfy6qe/P2aojfjwGonfDW/YHMLh uSy02W5D8mr8lXzF5h4AImeesDL+8D8+xjuYfc9b3vADw3Ys+IttFi+ZBh1PBCx1b3MM l6QsGcJTES3N3EoWGUUWVjRoCniaqVMj6OPNFkA71/mhH0kmxIA5RTJWAMzcCbRkN0db r06A== 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:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=YhkHaOYvVZReJOV3EtfsOXmD0b1cweClyD2c5FNJIac=; b=nvi6GLVQY3rJkCCaEXLrzMkLIkyK1phDy+vqU13iFL8sA22u3vpOkwzXsG5Vu1MSKk XUBCtDCAwv6Ssa6FCUvoyuN69ijUPeN9uImQPcoK2m2Jz3coA/UKOjrmlaQ4KPYyHfXh ecvGdQVSJuQao4KLdM6FeipVQy358er9wbSZnERDjJS2DX0DmFA66HU458/s+i4X/Z0t 22+1NvbOcZTANagRmsX4qsFG6jrN+rlXF4gNUeUN2b/SjUAXM3IaPAPEAiTclTW8zeSs VxcMycsUI6qZPCCDNdyD6rUchKdwk/+gA/m4I7XyrZ8vo3JG1qeZrq/tLMhev8AB6SAI vFcg== X-Gm-Message-State: AOAM531xPZcP73ipB55lI1EgO+6yrD2yXMe9ki+2tXVLNlRL+UDOX7by vPwa8tKylw2fe41FClLPFNE= X-Google-Smtp-Source: ABdhPJz9t1LiBgrdBlk36ZJJlhfpYORQaZa7Sc1JHOzckX9XS+FJ8oWn3x9UpdkgcVAdIiewJsYhgQ== X-Received: by 2002:a1c:544d:: with SMTP id p13mr376788wmi.25.1591207660103; Wed, 03 Jun 2020 11:07:40 -0700 (PDT) Received: from krug ([89.180.148.153]) by smtp.gmail.com with ESMTPSA id b187sm4193939wmd.26.2020.06.03.11.07.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 11:07:38 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends In-Reply-To: <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Tue, 02 Jun 2020 22:45:42 -0400") References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN> <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN> <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN> <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN> <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Date: Wed, 03 Jun 2020 19:07:37 +0100 Message-ID: <875zc8nhue.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: > "Future object." >> + (value 'eldoc-future--unset) >> + callback) >> + >> +(defun eldoc-future-set (f v) >> + "<WORLD CLASS DOCSTRING>" Ahem. >> + (cl-assert (eq (eldoc-future--value f) 'eldoc-future--unset)) >> + (setf (eldoc-future--value f) v) >> + (when (eldoc-future--callback f) >> + (funcall (eldoc-future--callback f) v))) >> + >> +(defun eldoc-future-set-callback (f c) >> + "<WORLD CLASS DOCSTRING>" Ahem hem :-) >> +<WORLD CLASS DOCSTRING GOES HERE> > > "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. In this case it would be, for instance, the type of the docstring being returns (function signature, value of a variable, etc). The callback strategy makes it easy because there are lambda lists of all shapes and sizes. How does the future approach handle this? Do clients return structured lists of things? > 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. In other situation, indeed we can be greedy. But I don't think you can just say to clients they dont'need to do anything. If they returned the future they are making _a promise_. If they don't fullfil it something goes wrong. The callback case is the same, if you return non-nil non-string, you, the eldoc function, are _required_, by Eldoc law, to call it, even if with nil. The equivalent in futures is just to say clients can set the value nil, or some other application-specific indication of "sorry, I failed". > 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. But indeed that's only an implementation detail. If you can make the defined behaviour work work in some other simpler way, I have no objections, of course. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 02:45:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 02 22:45:53 2020
Received: from localhost ([127.0.0.1]:41543 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jgJPc-0008T5-NM
for submit <at> debbugs.gnu.org; Tue, 02 Jun 2020 22:45:52 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64798)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jgJPa-0008Sr-H6
for 41531 <at> debbugs.gnu.org; Tue, 02 Jun 2020 22:45:51 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CF62E10050D;
Tue, 2 Jun 2020 22:45:44 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1C3A51001CB;
Tue, 2 Jun 2020 22:45:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1591152343;
bh=tRAT4wE/oz9Jtp50xzy2iH1Ts+ixAfEdB++6xP6C/BA=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=DYDnGwGme8tfoS01TspSPm+HuQDevgPDdrvMS1IYF2/9PjMJ6XjO66rd6bRrs0n0g
DdZgp+I2hK7rYXG/I6mzSLV+USWlz5W+bAAZgggz1lBnMD+5cgroRwC3HVmDFle+46
IlJqgEiNF86nASphjeBUCGkLw5iYJZBmb+6hZtY72WbUpqanvXnogl2kl6emxDwV7U
kuiolMGyuEuJGoLode2LXOnWt04JvWWN/MOsv+vVgIhGnMwU7Gmw2rxOq3ifvzqwiz
nAPPY/oBD9cEamuWQ9LRfdGiE15pzz3GZr8qE1dM2Y50YVmCJiIwgvT1d4X9V2cZ/r
TZXZ7S6IYgA9A==
Received: from alfajor (76-10-137-254.dsl.teksavvy.com [76.10.137.254])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A6CEB120328;
Tue, 2 Jun 2020 22:45:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
<jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
<jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
Date: Tue, 02 Jun 2020 22:45:42 -0400
In-Reply-To: <871rn6r0pr.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Tue, 26
May 2020 19:49:04 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.002 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org,
andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> --- a/lisp/emacs-lisp/eldoc.el
> +++ b/lisp/emacs-lisp/eldoc.el
> @@ -337,18 +337,32 @@ eldoc-display-message-no-interference-p
> (not (or executing-kbd-macro (bound-and-true-p edebug-active))))
>
>
> +;;;; Futuristic interlude
> +(cl-defstruct (eldoc-future
> + (:conc-name eldoc-future--)
> + (:constructor eldoc-future-make ())) ; become Yoda we?
> + "<WORLD CLASS DOCSTRING>"
"Future object."
> + (value 'eldoc-future--unset)
> + callback)
> +
> +(defun eldoc-future-set (f v)
> + "<WORLD CLASS DOCSTRING>"
> + (cl-assert (eq (eldoc-future--value f) 'eldoc-future--unset))
> + (setf (eldoc-future--value f) v)
> + (when (eldoc-future--callback f)
> + (funcall (eldoc-future--callback f) v)))
> +
> +(defun eldoc-future-set-callback (f c)
> + "<WORLD CLASS DOCSTRING>"
> + (cl-assert (null (eldoc-future--callback f)))
> + (setf (eldoc-future--callback f) c)
> + (unless (eq (eldoc-future--value f) 'eldoc-future--unset)
> + (funcall c (eldoc-future--value f))))
> +
> +
> (defvar eldoc-documentation-functions nil
> "Hook of functions that produce doc strings.
> -Each hook function should accept at least one argument CALLBACK
> -and decide whether to display a doc short string about the
> -context around point. If the decision and the doc string can be
> -produced quickly, the hook function can ignore CALLBACK and
> -immediately return the doc string, or nil if there's no doc
> -appropriate for the context. Otherwise, if its computation is
> -expensive or can't be performed directly, the hook function
> -should arrange for CALLBACK to be asynchronously called at a
> -later time, passing it either nil or the desired doc string. The
> -hook function should then return a non-nil, non-string value.
> +<WORLD CLASS DOCSTRING GOES HERE>
"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.
In case the function ends up finding no information it is allowed
not to `eldoc-future-set-value` at all."
> + (let ((x (run-hook-with-args-until-success 'eldoc-documentation-functions)))
> + (if (eldoc-future-p x) (eldoc-future-set-callback x eldoc--callback)
> + x)))
I'd simplify this to:
(let ((x (run-hook-with-args-until-success 'eldoc-documentation-functions)))
(when x (eldoc-future-set-callback x eldoc--callback)))
But I'd expect that there would be no `eldoc--callback` and that it's
each `eldoc-documentation-function` which chooses its own callback
rather than being chosen by their caller.
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 27 May 2020 23:58:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 27 19:58:20 2020 Received: from localhost ([127.0.0.1]:50336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1je5wB-0007ay-VZ for submit <at> debbugs.gnu.org; Wed, 27 May 2020 19:58:20 -0400 Received: from mail-io1-f53.google.com ([209.85.166.53]:36582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1je5w6-0007af-DZ for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 19:58:18 -0400 Received: by mail-io1-f53.google.com with SMTP id y18so7634558iow.3 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 16:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4ZisIWOGePaVkPJtqrM6MtOFQis99I73k2d/arP9AKk=; b=IqzgYZdLViTOVxwwlvExT3TIRk0ppj9euM28JIr0rqBLhjbS1l4bQqlvQuIX1PjlqP ULV+CYg1Thkg8Un8dOfGYvTnHFDCRuWONqGmN067KER8Ckv0vf3fig545+nint7rbO0y HyTvz3iaswy/sDVJR8YSoBHEG2OxdEbCIhEl9lCIv/nheW8U4NJVeU/60x/Lf5N1amJZ EZMlLMfZQIyRFI0S2Xq0FiAEDYq//7ySAs8pry9EaC1RjaqMrrmZ5UhDyoHuep1wpsuH /4nC/EblqvEpuQxeZjgUgqXuK91mfbin7JHeGRmFne7TWhHkF/MMb5XLLL8Z3cMmNV7S usKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4ZisIWOGePaVkPJtqrM6MtOFQis99I73k2d/arP9AKk=; b=DLqw6trWnHB6yeG+fIEBFGfK5Smne9e163urKV4YDSgZ+Ph2GcqpaHXK8cn6qCNt8s bYec4JIzLEUQ89Zyjer5VhHMzML1NOXL/dBHqOYSMQrSAXDbnrIiCOIJxr6jSnoGmrNF VbKkusHhiWrZV8y2Lpn4WpnPDxw/OnQonUrXhBF4KtHRtuWlGviXqk0ozOVe9WyXIDTn 9C3qfw2ziQaFc5vLABcqMd6eB3HFzi3WaLZKXZIyZMRGLmNBMsaGB1DkY7yHxT/EG4Ov PMjWxiSzXwZJS6wTy4Kr8Jq9kS9arKk/8tQ5A9k+0nPOWWADLLkyycGDZ0g94fFJGsBM uRxA== X-Gm-Message-State: AOAM530wDK9DvVLt4hTyYhksFLvn/3mjQXUxHDaa0xvpUshTh3K4kAQK 4nPvixSf19TPIjNn59hlCi4UtzuSR8mARKp+l5E= X-Google-Smtp-Source: ABdhPJySypImtBw2v1DvVkVl44dbzs9eBTxpsDJ6GOKTmTmd5lLCIjla5mTAMb94SSZKx8sgFQDW35Oc0Vv2ubN4onw= X-Received: by 2002:a6b:6818:: with SMTP id d24mr341223ioc.57.1590623888644; Wed, 27 May 2020 16:58:08 -0700 (PDT) MIME-Version: 1.0 References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> <87tv02pits.fsf@HIDDEN> <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN> <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN> <919188b1-154a-668a-7b0a-82fb96121c9e@HIDDEN> In-Reply-To: <919188b1-154a-668a-7b0a-82fb96121c9e@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 28 May 2020 00:57:56 +0100 Message-ID: <CALDnm53tkR-mm=6frJh9nq8_=7vAvMbC2ehc4oC4D_pDy5h+mg@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Thu, May 28, 2020 at 12:35 AM Dmitry Gutov <dgutov@HIDDEN> wrote: > It's a somewhat incorrect behavior that is, however, easier to implement. In the futures, how would you prevent a client from giving you a stale future? You have the very same problem. Callbacks aren't "easier" to implement than futures, either. I'm not saying they are "superior", as you seem to be pretending with futures, They just happen to be the style that's most used in Emacs. Futures are really good when you bring in continuations: i.e. functions that can halt and resume their processing, so you can write normally, as if there was no async, but still have it happen automatically. But that requires an evaluator, which is what generator.el does, and that's what enables proper futures like the ones in emacs-aio. Anything other than that is just moving objects and funcalls around, for style (or lack thereof, to some people) > Either way, that would require an additional way to signal. Try to fit > this into your proposal. It won't match so well. I've already shown you're mistaken. > > Suspend this discussion? Sure, this discussion yes, if your want. > > But not this bugfix: that would be exactly what "holding hostage" > > means. Don't hold this bugfix hostage: it has nothing to do with > > futures. > > It's a new feature, not a bugfix. No it's not. Async clients are using internal functions. eldoc-message is an internal function. eldoc is broken for async clients, always has been. You know this, of course. I worked on a fix and your're holding it up because of a longing for an abstraction that you kinda like but are still having doubts about. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 27 May 2020 23:35:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 27 19:35:46 2020 Received: from localhost ([127.0.0.1]:50316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1je5aL-00074R-Js for submit <at> debbugs.gnu.org; Wed, 27 May 2020 19:35:46 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:50362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1je5aK-00074F-An for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 19:35:45 -0400 Received: by mail-wm1-f46.google.com with SMTP id v19so1361443wmj.0 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 16:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R5S9j4wWBT0hiIP+jN0OM7D04Jr1lwwSHN/mgxgqvUo=; b=j2OkaFNijkVVdjev9FzMqMb7hs2ZVfbJg/h7fRjcj9JqTOikJFtmhJ3uXMELQu+7fH siw26Pc3qp2rhxgOtgmFI75yF+sDN2VQ1ceJjv9Nsj2UgMd63j8eHTNNVoDMfP5Se7hO h0/cJS9+zSafVLZJFtV+5IrhZImQp9VqBLPfqUuSRxCaR/9Pm5St6QSqpPGoRfV2aG24 Cdfclq3hBXaBDnyNRn9jveTvO/sZF4WLiVjeKfGWvorBE6iHjnzhWWpS3xxKy1agOCFk rA8lK585xC6yTYBvVCbj3ikv0XUM6UVkr3eU8TVS+f+1ulZHrEMgE8+8fgIvTWMsKoZi iN5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R5S9j4wWBT0hiIP+jN0OM7D04Jr1lwwSHN/mgxgqvUo=; b=JGW9ZbFxth6VqTpgvh/6+d6z/cDZy6dVbM5y/7uHcowBcZgIZwClBrg3AKd71njUIP 7c4ZhVg80q6aaY3fOSG0Ab6/cxQGoPrLp9qHGWBLpOU8k2jmFDOtHXtL/0eFa5/QVNjl ynCeA0bkHfoyNOZ4mxnNab34nwBPKkFvop+zIYoOEPrePeBvmPMo642QOWLbvUcMqF6t hVJeYJ7M2gpgoHTIeE8crl8MAC9xjGRhJIq7UZJqT37rOcwfjbbKzBBMEb9ExAL1+9tM BiVErC5oiQn0XIRd7HkcDPwMGupckRhDYF9JUWvo8u2hqxj6snyrOBgkhsVgfdVKnWku 9qsQ== X-Gm-Message-State: AOAM531TRzEeuCyPp/4dc3yNuRHf7d+vyIyJ6sUeJBuLCV67M7P5l5m9 VG6FqaerBO42XjG30jXVvYM= X-Google-Smtp-Source: ABdhPJxPRxdVJxWlHIciIgUWgLqss+UhywQG7ESVaTIpfcmfTylhWNg35q2oHsG3wpb+oA73CCQpLg== X-Received: by 2002:a1c:1983:: with SMTP id 125mr462202wmz.43.1590622538223; Wed, 27 May 2020 16:35:38 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id s2sm4017811wmh.11.2020.05.27.16.35.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 16:35:37 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> <87tv02pits.fsf@HIDDEN> <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN> <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <919188b1-154a-668a-7b0a-82fb96121c9e@HIDDEN> Date: Thu, 28 May 2020 02:35:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 28.05.2020 01:13, João Távora wrote: > On Wed, May 27, 2020 at 10:14 PM Dmitry Gutov <dgutov@HIDDEN> wrote: >>> No, the creditor of the future or issuer of the callback aborts or >>> invalidates the previous version just before issuing a new one. Nothing >>> pre-command-hook here. >> >> Where/when would eldoc-mode do it? > > In the idle timer function. That's when it decides it wants > new info, and so any old info that hasn't arrived yet is probably > out of date. Then eldoc might shows some info when it's no longer pertaining to the context around the point. > But I think I understnad what you mean pre-command-hook. > You suggested pre-command-hook because that's where you > can check if point is far enough away from the place where > the original request originated? Or always abort, as soon as the user invokes the next command. >>> Flymake does this: by invoking a backend again with a new callback >>> instance it is signalling that the preceding one became invalid. If the >>> backend tries to call the previous callback, it is an error and the >>> backend is disabled. >> >> Worse is sometimes better, we know. > > That is a very confusing statement. It's a somewhat incorrect behavior that is, however, easier to implement. Which is fully along the lines of Richard P. Gabriel's "The Rise of Worse Is Better". >> That would be my "alternative" suggestion: for >> eldoc-documentation-functions elements to return a function (denoted as >> FETCHER in the docstring) if they want the async convention. > > They need to _receive_ an object produced externally, somhow. > If they return a function as youv suggest, they are only doing so > they can later _receive_ another object. This is needlessly > complicated. To receive objects in some place, just use argument > the argument list of that place. "Returning a value" is meaningful semantic. Even when that value is a function. >> Okay, creditor != creator. But what you've said a few messages back >> (seen at the top of the quotes chain above) doesn't make sense: the >> creditor will call (future-abort fut), and the issuer of the future can >> make sure that this operation will indeed kill the process. > > No, it does make sense. Read it again. What you're saying is what I > meant. Perhaps you could have agreed then. > But that still means that the process sentinel will have to deal > with out-of-band kills that it must distinguish from other out-of-band > kills (such as, say, a kill -9 from the shell). That is added complexity. It's their choice. Some processes might run too long in certain cases. So that would be a safeguard. > It is better, in my opinion, to make this softer. Let the creditor > signal, I don't need this anymore, and the issuer will take appropriate > measures synchronously, i.e. in the process filter and not in the > process sentinel. Either way, that would require an additional way to signal. Try to fit this into your proposal. It won't match so well. >> That's the main idea behind aborting futures. Or canceling. Whatever >> term we're going to pick. > > But, again, nothing you're describing here can't be implemented > with passing a callback in the arglist. It's independent. Futures > particularly the versions you and Stefan are proposing are just > other places to type basically the same sexps. They're a stylistic > change over callbacks, but nothing more, fundamentally. Hence my request to wait a little. Stefan suggested the simplest version because it both fits your current requirements, and it can be extended without breaking that usage. >> Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose. > > Yeah,I don't get it particularly, either. I mean, I can see its uses. > but I'm glad you're finally getting the overengineered feeling :-) No "finally", that was my opinion of it from the outset. > And it's waay more useful than futures here. Way to extend the bridge and then kick it down. >> Would they need to? As soon as an existing Eglot's implementation is in >> place, that exact part of the code wouldn't need to be touched often. > > Code is read much, much more than is is written. And WTF per minute > _are_ a measure of code quality. I would like to avoid this particular > WTF please. Okay, here's another argument: "Promise", or a "Future", or "Deferred" or whatever, are common notions across many programming languages now. When a programmer encounters an idea familiar to them, they understand a program more easily. No WTFs. >> In any case, you are over-exaggerating. This exact design has been a > > "over-exaggerating". Very meta. Plain English. >> And not once have I seen a complaint that it's overly complex. > > Anyway, count one now. Or don't. I mean, I really dislike > company-backends throughout, but I don't use it, either. Noted. > I mean > I know you inherited it and I had to hack on it to add flex support > for the capf thing, but it's a strange re-implementation of functions > to have one single function that does wildly different things based > on one argument. I guess at the time there weren't generic > functions. And the cons :async thing is equally confusing to me. > Sorry to be frank. But I guess some people will love it, for some > equally legitimate reason: it will seem "right" to them, or "clever". It's very simple. Much simpler than generic functions or c-a-p-f. So I'm surprised to see you disparage both ideas (one simpler than what you do, another a tiny bit more complex) as complex and outlandish. >> Didn't you say that Flymake could use futures as well? > > It could, sure, especially if you have a thousand futuristic devs > itching to write backends but not grokking callbacks. But let's > not kill the existing API, please. Probably not. Unless we find a good use in it for the extra capabilities provided by futures. > Suspend this discussion? Sure, this discussion yes, if your want. > But not this bugfix: that would be exactly what "holding hostage" > means. Don't hold this bugfix hostage: it has nothing to do with > futures. It's a new feature, not a bugfix.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 27 May 2020 22:13:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 27 18:13:22 2020 Received: from localhost ([127.0.0.1]:50237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1je4Ib-0002th-UM for submit <at> debbugs.gnu.org; Wed, 27 May 2020 18:13:22 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:44509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1je4IZ-0002tU-Q9 for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 18:13:20 -0400 Received: by mail-io1-f66.google.com with SMTP id p20so14424422iop.11 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 15:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LwrfUoDvfE+n2dkcmKuNsC5pty6sxSvmNzbwjulIRqY=; b=N4OQBEHn1eb5Abid5nnsoqvgIBwWNgyCd5u9ixijX3fIELEGPxIOfGEY5fylm9ZJ2b jKiFs7MYXIoKmGKb8xnSAbAywaAHt1buGKAhxTdWFR/mEcuNvizAbcwntp+znlMl1zYW M1AljRvxYolOCpUyYTYTz4ClZlcDo78vpZIW0N9HhhLmOiyRs9Nqwb3D67GSwnj/N6qt ttnBkC/netHaupbeKDGRoTxG+PipzXW6ZKOYyPA+dRKkXWryA853v8zV9P8OQR/iRmO4 6VRTlX9mYBmjY6kE+prSHlbBp00o3uY0SB+QX8dQwyfDBA6K1rJysUglAa8/XDnrcr4c F0ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LwrfUoDvfE+n2dkcmKuNsC5pty6sxSvmNzbwjulIRqY=; b=aTB5TaIpTpQfBQcdwjbGrJk0YFYTa/hdOSHv1QUXDN7DsN52fmijt0t9JnVwDiYbCg TM/5JwfJvQG3WlsukRG98fucBnXfbkQTSlT1CgCuWlXocrPAdKEgRXinlIGJE+nuta7b 2soCOUOQNlCgMK861+eTS/drdbtPm2fNgtbX5uJYdCjrkAoCjnUJQU09DQcHelG4yvMY ICetSj1BRtW0hzOBDZSi/w5lKOczLiGS9Ry/TSERwV6YZOAG1wHU0Q8CZKMyANZokQpT 822h33VdCKGAqW4gffPknIY5NBsXsyfG5TCY0wJWQtzMWfJUf3sxrgwygfbm6WRLcJQY oROA== X-Gm-Message-State: AOAM5336eR7fyRPEZU0BL2/8n2rqpspp1I94tPp/xbCakR+ITmbif4X4 SPWV8aqXCfRKIBp9jYpKqqnvdeUtkErY2el80fw= X-Google-Smtp-Source: ABdhPJyUofjkipzHaGZVSySR1k97DYZibO85DIbvTHtEUvlYuj+d8BPT7grOm66Rk0sFOT8d9Qxde37EoHqtPexh2QE= X-Received: by 2002:a6b:6818:: with SMTP id d24mr63731ioc.57.1590617593970; Wed, 27 May 2020 15:13:13 -0700 (PDT) MIME-Version: 1.0 References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> <87tv02pits.fsf@HIDDEN> <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN> In-Reply-To: <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Wed, 27 May 2020 23:13:02 +0100 Message-ID: <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Wed, May 27, 2020 at 10:14 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > > No, the creditor of the future or issuer of the callback aborts or > > invalidates the previous version just before issuing a new one. Nothing > > pre-command-hook here. > > Where/when would eldoc-mode do it? In the idle timer function. That's when it decides it wants new info, and so any old info that hasn't arrived yet is probably out of date. But I think I understnad what you mean pre-command-hook. You suggested pre-command-hook because that's where you can check if point is far enough away from the place where the original request originated? That could work, but I'd prefer that the info to _do_ come in, because after that info is about the last time my point hung out at a particular position long enough to trigger a request. This is how Eglot, SLY and SLIME work, btw. > > Invalidation may or may not entail letting the > > holder of the callback know that the previous call became invalid. > > Letting know the issuer of the future, you mean. Or the holder of the callback depending on which abstraction we're talking about. I define the holder of the callback as he who is about to call it. > > Flymake does this: by invoking a backend again with a new callback > > instance it is signalling that the preceding one became invalid. If th= e > > backend tries to call the previous callback, it is an error and the > > backend is disabled. > > Worse is sometimes better, we know. That is a very confusing statement. > >> It's good to have a well-documented contract. Functions do > >> _everything_. They can't be optimal for everything. > > > > You're missing a Lisp point here. It doesn't matter if it's an CLOS > > object, a struct, a function or my beautiful singing voice: it just has > > to be an object which you can make unique instances of and can respond > > to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf > > errored-p). That's the contract. A function fits perfectly. > > That would be my "alternative" suggestion: for > eldoc-documentation-functions elements to return a function (denoted as > FETCHER in the docstring) if they want the async convention. They need to _receive_ an object produced externally, somhow. If they return a function as youv suggest, they are only doing so they can later _receive_ another object. This is needlessly complicated. To receive objects in some place, just use argument the argument list of that place. > > >>>>> 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. > >>>> It can (barring any complex abstractions). It created the process, > >>>> after all. > >>> Not really, it asked a client to solve a problem, doesn't know how > >>> the client if the client is doing by async process or cointoss. > >> Seems like we're miscommunicating. > > > > Well you implied that the creditor of the future (the caller who > > received) created the process. It does not. See the patch to Stefan. > > Okay, creditor !=3D creator. But what you've said a few messages back > (seen at the top of the quotes chain above) doesn't make sense: the > creditor will call (future-abort fut), and the issuer of the future can > make sure that this operation will indeed kill the process. No, it does make sense. Read it again. What you're saying is what I meant. But that still means that the process sentinel will have to deal with out-of-band kills that it must distinguish from other out-of-band kills (such as, say, a kill -9 from the shell). That is added complexity. It is better, in my opinion, to make this softer. Let the creditor signal, I don't need this anymore, and the issuer will take appropriate measures synchronously, i.e. in the process filter and not in the process sentinel. > That's the main idea behind aborting futures. Or canceling. Whatever > term we're going to pick. But, again, nothing you're describing here can't be implemented with passing a callback in the arglist. It's independent. Futures particularly the versions you and Stefan are proposing are just other places to type basically the same sexps. They're a stylistic change over callbacks, but nothing more, fundamentally. > >> See above about not having to change anything. > > > > But then we don't have to change anything in any case! I already > > changed EVERY user of eldoc-documentation-functions: every single one o= f > > the 5 in existence in the entire world. So we're all good. > > And then we'll need to change them back. Nothing of the sort. > And in the meantime, the new > convention could get external users (some people do live on the bleeding > edge), and this will get messier. That's only if you assume you'll break compatibility, because you dislike callbacks so much that you want to close off the arglist forever. But not only may users may not dislike them, they may even prefer them. And keeping the arglist open, not closed, is a very good idea for extensibility functional API's anyway. > >> OK, I see your point: eldoc-documentation-functions is new. And > >> apparently you don't intend to add this feature to the variable > >> without "s". > > > > Yes, exactly. eldoc-documentation-function should be obsoleted IMO. > > Perhaps. I'm also not buying the usefulness of eldoc-documentation-compos= e. Yeah,I don't get it particularly, either. I mean, I can see its uses. but I'm glad you're finally getting the overengineered feeling :-) And it's waay more useful than futures here. > >>> It just looks like you're holding this problem hostage to introducing > >>> some kind of rushed futures solution. I don't agree with either of > >>> these things. > >> > >> Who's holding what hostage? I showed a smoother approach, you didn't > >> like it. No big surprise about that. > > > > Let me explain. First: it's clearly not "smoother", your're asking user= s > > to wrap their heads around a function that returns a function taking a > > function. That's not what I want to present to Eglot contributors, for > > instance. > > Would they need to? As soon as an existing Eglot's implementation is in > place, that exact part of the code wouldn't need to be touched often. Code is read much, much more than is is written. And WTF per minute _are_ a measure of code quality. I would like to avoid this particular WTF please. > In any case, you are over-exaggerating. This exact design has been a "over-exaggerating". Very meta. > part of "asynchronous" backend calling convention in Company for years. People will use what you give them, if you they have no other option. > And not once have I seen a complaint that it's overly complex. Anyway, count one now. Or don't. I mean, I really dislike company-backends throughout, but I don't use it, either. I mean I know you inherited it and I had to hack on it to add flex support for the capf thing, but it's a strange re-implementation of functions to have one single function that does wildly different things based on one argument. I guess at the time there weren't generic functions. And the cons :async thing is equally confusing to me. Sorry to be frank. But I guess some people will love it, for some equally legitimate reason: it will seem "right" to them, or "clever". > > And I'm not too crazy with presenting them this "future > > thing" that is completely different from Eglot's use of Flymake, > > jsonrpc.el, completion-at-point, etc... > > Didn't you say that Flymake could use futures as well? It could, sure, especially if you have a thousand futuristic devs itching to write backends but not grokking callbacks. But let's not kill the existing API, please. > > In other words, my ambition is > > consistency and you seem to be denying it for reasons I can't > > understand, because nothing in the steps I am taking denies _your_ > > ambitions, which seem to be futures. That's why I speak of "hostage". > > See above. But perhaps we should after all suspend this discussion until > we had a chance to reach a better mutual understanding of the futures > API, and how we expect it to help (or not). I promise to show some > proposals in the near future. Suspend this discussion? Sure, this discussion yes, if your want. But not this bugfix: that would be exactly what "holding hostage" means. Don't hold this bugfix hostage: it has nothing to do with futures. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 27 May 2020 21:14:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 27 17:14:10 2020 Received: from localhost ([127.0.0.1]:50132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1je3NK-0005Z8-B8 for submit <at> debbugs.gnu.org; Wed, 27 May 2020 17:14:10 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:39434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1je3NI-0005Yu-G9 for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 17:14:09 -0400 Received: by mail-wm1-f45.google.com with SMTP id k26so995325wmi.4 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 14:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ToU3oVOpgrnFc3ErbFYGXrSJMEfsfZtE5OOMHRZbsCA=; b=ZvDJRe8fD6O26Mhwi0llsBS1CIwvHNa2ti/QgdA2WsqyhB3lZmf0tlRbA2pTYxO8Fo nhEAh4DlbkTcT+JwlQJ3J07buAKHOjNYkYt9BptzNEFB5JHRqZmZYE+jQ/+XQ7Df7f18 /PSm7JuW7SPEvdmWbt2MgTUnt74NqjVS0KWppTBjTjm0IpBSzhhMmu5+M0Vbvv4R7fM/ J1UwaAT4yRNdPZyEX4msn54o4AIN5FUih8gEljWpr6kjT5J7JpyAFG6hG1KJRoNivu2V FFyPiLcCCxeH0r6LyUkb85Var6Xvnhomar65FEMF8bnE+sZBE7ZFZTuPQRF+BVEOI8p8 5opA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ToU3oVOpgrnFc3ErbFYGXrSJMEfsfZtE5OOMHRZbsCA=; b=mXvQqPZxBF1YUSSTW2PJjjZF36yXhEeUYMHFs/TqS+mbvTBujkosibWRLB56Ti3l9P 5krqpyKRWv6S5E7myZYsIQ7hbisD+6NxapljXub0ho+EM1FVlv08ci6nw2s2i8xpcLgY rqPPCMrl0U7Gh0pgPZ+AO25OaN4/nsL/139OOFhEr2rbJNB5s4YE6ASBjzaGheC08x5q 5F9SFdAZQiyz++cMk31knon6jc/RrVdwYnne9fOT1+RbADcMyoXrjCwhIwACpNXp9bTJ cssVl7bkdzA07rPqE2iFz+UaydUCd2s0rGXXeS3pFZBkth60+CtGLX2OTPN4U2ClM2a+ n39Q== X-Gm-Message-State: AOAM531aWUuwhBXGkX7kdu202kpssgZFxW/7p5wYC3nU6L9KWr9Q99FG ttoHBhSB6BgovmzcYINpxFE= X-Google-Smtp-Source: ABdhPJydkmWNT4zstF310tG1jnryu3yOfMT8t+xsZwVg5rcp/n98dvlkPeirbokSs3GllSBDIkqAHA== X-Received: by 2002:a1c:de46:: with SMTP id v67mr62188wmg.146.1590614042414; Wed, 27 May 2020 14:14:02 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d4sm3766517wre.22.2020.05.27.14.14.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 14:14:01 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> <87tv02pits.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN> Date: Thu, 28 May 2020 00:14:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87tv02pits.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 26.05.2020 23:00, João Távora wrote: > Dmitry Gutov <dgutov@HIDDEN> writes: > >>> no idea of it. In the framework you either make the callback a noop, >>> or you set it aborted for the client to save some work. Or both. >> >> So the abort thing. In pre-command-hook? > > No, the creditor of the future or issuer of the callback aborts or > invalidates the previous version just before issuing a new one. Nothing > pre-command-hook here. Where/when would eldoc-mode do it? > Invalidation may or may not entail letting the > holder of the callback know that the previous call became invalid. Letting know the issuer of the future, you mean. > Flymake does this: by invoking a backend again with a new callback > instance it is signalling that the preceding one became invalid. If the > backend tries to call the previous callback, it is an error and the > backend is disabled. Worse is sometimes better, we know. >> It's good to have a well-documented contract. Functions do >> _everything_. They can't be optimal for everything. > > You're missing a Lisp point here. It doesn't matter if it's an CLOS > object, a struct, a function or my beautiful singing voice: it just has > to be an object which you can make unique instances of and can respond > to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf > errored-p). That's the contract. A function fits perfectly. That would be my "alternative" suggestion: for eldoc-documentation-functions elements to return a function (denoted as FETCHER in the docstring) if they want the async convention. >>>>> 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. >>>> It can (barring any complex abstractions). It created the process, >>>> after all. >>> Not really, it asked a client to solve a problem, doesn't know how >>> the client if the client is doing by async process or cointoss. >> Seems like we're miscommunicating. > > Well you implied that the creditor of the future (the caller who > received) created the process. It does not. See the patch to Stefan. Okay, creditor != creator. But what you've said a few messages back (seen at the top of the quotes chain above) doesn't make sense: the creditor will call (future-abort fut), and the issuer of the future can make sure that this operation will indeed kill the process. That's the main idea behind aborting futures. Or canceling. Whatever term we're going to pick. >> See above about not having to change anything. > > But then we don't have to change anything in any case! I already > changed EVERY user of eldoc-documentation-functions: every single one of > the 5 in existence in the entire world. So we're all good. And then we'll need to change them back. And in the meantime, the new convention could get external users (some people do live on the bleeding edge), and this will get messier. >> OK, I see your point: eldoc-documentation-functions is new. And >> apparently you don't intend to add this feature to the variable >> without "s". > > Yes, exactly. eldoc-documentation-function should be obsoleted IMO. Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose. >>> It just looks like you're holding this problem hostage to introducing >>> some kind of rushed futures solution. I don't agree with either of >>> these things. >> >> Who's holding what hostage? I showed a smoother approach, you didn't >> like it. No big surprise about that. > > Let me explain. First: it's clearly not "smoother", your're asking users > to wrap their heads around a function that returns a function taking a > function. That's not what I want to present to Eglot contributors, for > instance. Would they need to? As soon as an existing Eglot's implementation is in place, that exact part of the code wouldn't need to be touched often. In any case, you are over-exaggerating. This exact design has been a part of "asynchronous" backend calling convention in Company for years. And not once have I seen a complaint that it's overly complex. > And I'm not too crazy with presenting them this "future > thing" that is completely different from Eglot's use of Flymake, > jsonrpc.el, completion-at-point, etc... Didn't you say that Flymake could use futures as well? > In other words, my ambition is > consistency and you seem to be denying it for reasons I can't > understand, because nothing in the steps I am taking denies _your_ > ambitions, which seem to be futures. That's why I speak of "hostage". See above. But perhaps we should after all suspend this discussion until we had a chance to reach a better mutual understanding of the futures API, and how we expect it to help (or not). I promise to show some proposals in the near future.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 26 May 2020 20:00:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 16:00:57 2020 Received: from localhost ([127.0.0.1]:46399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jdfku-0003Qu-Sm for submit <at> debbugs.gnu.org; Tue, 26 May 2020 16:00:57 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:40678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jdfkt-0003Qh-GK for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 16:00:56 -0400 Received: by mail-wm1-f41.google.com with SMTP id r15so817199wmh.5 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 13:00:55 -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=65wzmJ4kjjeU7kCUFUtgkrtM8NVFnj72JMijcRB8Zf8=; b=kCsZ8DIMZFAgJY8V2IaQPFREYAEdn+IhPBlTi7/hqVuJnKXumJELc2oh8JHJtzifrN n6kWzT5tdrgNJyUutv9wipkBFBzR8gGx77uPFIhTvJ6QFpIs3R9moewemGIsrBpm9Fyt 9s1Ry8896UFMXmIocciUfv4okrtG8d22uJ7AzW2CuWYpOj5zxAgwOV5+qpQt1fMsrDRM mCmi/AJZf7hq67IR8EdxZuFrevpL8usWDgljNRywElss789ncJ+tk9+Kkuf8ib7X8BQ3 gOlmZ7P+yFMPlKhFfKGI4irlbB9cGxT/R/C1B1fzsDHU/fE5L0YUwJnLe0+mVxYlgL9V aLjw== 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=65wzmJ4kjjeU7kCUFUtgkrtM8NVFnj72JMijcRB8Zf8=; b=YHZMnulDNkWYnOy08a4PJjwo6fuGOknm/SB4yJQuN1+c58FNmAjTVfdJPfIP5bp3Ho DAkvsbexc7HJAda8qQppnn5A2yO7j9U1R9j4GvnSfa1DrTpk49wubvLJWZj5qnIlyeuN 0TbNIPdKhtmjXDGtJB6hul/XuSyOmunv70+9kC1fvk67Jx9dSW3w2x2gz9h06nlIrMZg t96vHaiBCVCc6pkWdpImzTSnuKX2B3iQR0Sjuz2zSl0M/Xocqa4wTEbt/gDUDDxKvNcN D0GkNf1Mc2WMr0EAVDsHA49ntL+HMh+8zKot+yRey0y8MjAnknQGCxEyd3cniZZ7Bg5w xCVA== X-Gm-Message-State: AOAM531sO/x2uOt5q5zYH+o0SLtfQOef4wio/XDQF7yySTE7DKMwrZ+l g//y9bmwUC+YJ4nsmpNNJD8= X-Google-Smtp-Source: ABdhPJwYed0lXewX0Cse12zQ+mK6KP+Wc6FPf84Q7bZATDnSk+Hy5wNzxiMDvExcQflSNRknT18DPA== X-Received: by 2002:a1c:7c0e:: with SMTP id x14mr751698wmc.1.1590523249276; Tue, 26 May 2020 13:00:49 -0700 (PDT) Received: from krug (89-180-149-243.net.novis.pt. [89.180.149.243]) by smtp.gmail.com with ESMTPSA id z132sm598398wmc.29.2020.05.26.13.00.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 13:00:48 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> Date: Tue, 26 May 2020 21:00:47 +0100 In-Reply-To: <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> (Dmitry Gutov's message of "Tue, 26 May 2020 22:14:31 +0300") Message-ID: <87tv02pits.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: >> no idea of it. In the framework you either make the callback a noop, >> or you set it aborted for the client to save some work. Or both. > > So the abort thing. In pre-command-hook? No, the creditor of the future or issuer of the callback aborts or invalidates the previous version just before issuing a new one. Nothing pre-command-hook here. Invalidation may or may not entail letting the holder of the callback know that the previous call became invalid. Flymake does this: by invoking a backend again with a new callback instance it is signalling that the preceding one became invalid. If the backend tries to call the previous callback, it is an error and the backend is disabled. > It's good to have a well-documented contract. Functions do > _everything_. They can't be optimal for everything. You're missing a Lisp point here. It doesn't matter if it's an CLOS object, a struct, a function or my beautiful singing voice: it just has to be an object which you can make unique instances of and can respond to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf errored-p). That's the contract. A function fits perfectly. >>>> 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. >>> It can (barring any complex abstractions). It created the process, >>> after all. >> Not really, it asked a client to solve a problem, doesn't know how >> the client if the client is doing by async process or cointoss. > Seems like we're miscommunicating. Well you implied that the creditor of the future (the caller who received) created the process. It does not. See the patch to Stefan. >> is a bad idea. An abort switch whose contract is "just letting you know >> I don't need this anymore" is better. But again, in eldoc, not so >> useful. And again, nothing to do with futures here. > > Here as well. OK. The takeaway is that "aborting a future" doesn't need any constructs specific to futures, is all. > See above about not having to change anything. But then we don't have to change anything in any case! I already changed EVERY user of eldoc-documentation-functions: every single one of the 5 in existence in the entire world. So we're all good. >> +;; NOTE: The xref API is still experimental and can change in >> major, >> +;; backward-incompatible ways. Everyone is encouraged to try it, a= nd >> +;; report to us any problems or use cases we hadn't anticiated, by >> +;; sending an email to emacs-devel, or `M-x report-emacs-bug'. >> That has been sitting there for almost three Emacs major versions >> (in >> fact you added it after the initial 25 release). All I'm asking is for >> a little such flexibility with eldoc. > > I wrote that for xref.el because that was the state of affairs, and > xref was relatively new. Especially compared to eldoc. This part of eldoc.el is probably newer than xref.el was when you wrote that. > But we're probably miscommunicating here as well. Doubt it. > OK, I see your point: eldoc-documentation-functions is new. And > apparently you don't intend to add this feature to the variable > without "s". Yes, exactly. eldoc-documentation-function should be obsoleted IMO. >> It just looks like you're holding this problem hostage to introducing >> some kind of rushed futures solution. I don't agree with either of >> these things. > > Who's holding what hostage? I showed a smoother approach, you didn't > like it. No big surprise about that. Let me explain. First: it's clearly not "smoother", your're asking users to wrap their heads around a function that returns a function taking a function. That's not what I want to present to Eglot contributors, for instance. And I'm not too crazy with presenting them this "future thing" that is completely different from Eglot's use of Flymake, jsonrpc.el, completion-at-point, etc... In other words, my ambition is consistency and you seem to be denying it for reasons I can't understand, because nothing in the steps I am taking denies _your_ ambitions, which seem to be futures. That's why I speak of "hostage". Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 26 May 2020 19:14:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 15:14:46 2020 Received: from localhost ([127.0.0.1]:46390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jdf2E-0002Mh-3B for submit <at> debbugs.gnu.org; Tue, 26 May 2020 15:14:46 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:37948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jdf28-0002MO-2l for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 15:14:44 -0400 Received: by mail-wr1-f52.google.com with SMTP id e1so21591948wrt.5 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 12:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wNUlAVh+byE4GVU7DSGyAc6JfvSwOICisVScZZ+D/Ic=; b=JArWoVfXjXSHiOnMZkj6GTHK3PKd78O8jHFeeo2JNOHgT+qWNspZUHGHdsAa/fXVUS hXWvu803rLSk98b/QXAVjaATNw/1MZc/FvLX3MU/uFhlnLTwxTUaWUsx5L/gagBat86B 5tkwZAXnNKd5GCstJ+si+FPGPh+6VZUe0eFK4DenRtGRDHt3rdOog78akCRJ6PMhfkmB Pku4ZpeWAqQJ5gcdHVJtY6noVYCAkbfXzh6elSoPIxpobo/zgTWtZpiQ6r8l7dDYTUO0 FfEweWGpY7bw0wgeqxfotM838wN2q33kJozhUai5bZMMQ07FNEI6fP32Hq97mAjOl40K DP4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wNUlAVh+byE4GVU7DSGyAc6JfvSwOICisVScZZ+D/Ic=; b=HUQKaUPb/2+R1R0LqchDqP+44rjvQruo9KTYNHyYgtQDnJKI71DW9dPGwbgimPjySm vVRhqtjFnraj69BSZYUVvos2Cd443C8PAtBOdejyZaisEdRVcOrK4f0z86lXllk9+iwy QWN9jySnpIBB1oIIFknZfCbIOAhBiz/jQe8vfBntq8EcQcUbxXaPTnCj3I6T4caq9dzI cpK+odtjjUxx0iCNH99zdwfisEscKOCr8Ng5PcuDJzz2II+Xfv75096eHClHuNcHP4qg lXRySFWu9R8fJgEtYPljurDwrRvOuXKkbBx8CT1suF0yLAYVIdubB2Hfj1rbCqsIkjSo g1gQ== X-Gm-Message-State: AOAM531AoRZXZB7JzT9NpLuOpLr8r8drbDBdm3PsPCV2BDEFid4tDYfJ PPSx9rGBTSNKNg8gjLdXgYE= X-Google-Smtp-Source: ABdhPJx5haLX+fJZhAV3cGu8tmmbs/ArxE/JIbRnyH4FrMFYN86Uqczk5O10kEcYJU4M6xs0kruaKg== X-Received: by 2002:adf:f651:: with SMTP id x17mr22656210wrp.277.1590520474022; Tue, 26 May 2020 12:14:34 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id w15sm399520wmi.35.2020.05.26.12.14.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 12:14:33 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> Date: Tue, 26 May 2020 22:14:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87ftbmr8d9.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 26.05.2020 19:03, João Távora wrote: >>> 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" >> >> To clarify, you actually included two proposals (behavior with patch >> 1, and with both patch 1 and patch 2 applied). The first one is the >> one I really didn't like. The second one is better, API-wise, but will >> conflict with the futures-based approach. > > It's not a conflict at all. When you do the futures-based approach > you're going to rewrite the docstring to augment the API. You do the > same here: just add this to the docstring: > > "If you prefer, ignore CALBACK and return a `future-future' object from > this function". > > How is that different from: > > "If you prefer, instead of returning a (:ASYNC . FUNCTION) cons, > return a `future-future' object from this function"" > > ??? We're not going to do either. The :async option is only for those tho need async _right this second_. It would be fully replaced by the "futures" option. Or we can implement it right now. And hopefully we won't have to maintain the eldoc-specific futures "forever" either. >> BTW, maybe eldoc-message should handle this after all? Since it's the >> last link in the chain. Or even do that in the default value of >> eldoc-message-function (create a wrapper for minibuffer-message). > > Doesn't work well becasue eldoc-message is called by both the produced > _and_ the backend, as I showed you earlier. And it certainly doesn't > work with eldoc-documentation-compose. We could split it apart, I guess. Or make two versions. >>> 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, ... >> >> So the client will have to save and then compare the current buffer, >> the value of point and buffer-chars-modification-tick now? > > Ah, _that_ validity. No, no, never do that. The client should have no > idea of it. In the framework you either make the callback a noop, or > you set it aborted for the client to save some work. Or both. So the abort thing. In pre-command-hook? >>>> 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. >> >> Futures are not particularly more complex to use. > > Sure, but they are _more_ complex. And you're mixing up two things: > futures _aren't_ the only way -- or even a particularly easy way -- to > signal to the clients that thety can give up their efforts. All the > client needs to have is access to an object that's shared between it and > the framework. That object _needn't_ be a first-class CLOS object or > struct. It can be a function. It's good to have a well-documented contract. Functions do _everything_. They can't be optimal for everything. And this way we don't add extra arguments, so whoever doesn't need async, doesn't need to change a thing. >>>> 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. >> >> It can (barring any complex abstractions). It created the process, >> after all. > > Not really, it asked a client to solve a problem, doesn't know how the > client if the client is doing by async process or cointoss. Seems like we're miscommunicating. >>> 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. >> >> That would be none of ElDoc's business, though. But the implementation >> will get to be as complex as it needs. > > _That's_ why an abort switch whose contract is "kill this immediately" > is a bad idea. An abort switch whose contract is "just letting you know > I don't need this anymore" is better. But again, in eldoc, not so > useful. And again, nothing to do with futures here. Here as well. >>> 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: >> >> The one thing I want to avoid doing is changing the callsig of every >> documentation function, and then changing them back when we switch to >> futures. > > So _don't_ change the "callsig". If you implement futures you _are_ > going to change the protocol anyway, i.e. write new stuff in the > docstring. See above about not having to change anything. >>> 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. >> >> Um, I'm pretty sure we guarantee a fair amount of stability. > > That's not what Stefan said here: > > https://github.com/joaotavora/eglot/pull/459#issuecomment-633634034 > > And that's not what the Dmitry from 2016 wrote in xref.el > > +;; NOTE: The xref API is still experimental and can change in major, > +;; backward-incompatible ways. Everyone is encouraged to try it, and > +;; report to us any problems or use cases we hadn't anticiated, by > +;; sending an email to emacs-devel, or `M-x report-emacs-bug'. > > That has been sitting there for almost three Emacs major versions (in > fact you added it after the initial 25 release). All I'm asking is for > a little such flexibility with eldoc. I wrote that for xref.el because that was the state of affairs, and xref was relatively new. Especially compared to eldoc. But we're probably miscommunicating here as well. >>> 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. >> >> Kill the arg in all built-in functions, as well as in external >> consumers? > > Yes, if we discover there aren't so many. Currently there are 5 users > in Emacs proper, 0 in GNU ELPA and quite sure 0 elsewhere in the world. OK, I see your point: eldoc-documentation-functions is new. And apparently you don't intend to add this feature to the variable without "s". > It just looks like you're holding this problem hostage to introducing > some kind of rushed futures solution. I don't agree with either of > these things. Who's holding what hostage? I showed a smoother approach, you didn't like it. No big surprise about that. > I think this particular problem shouldn't be held hostage > to rearchitecting async in Emacs, laudable and useful a goal as that > might be. And I think a futures library should be well thought out: I'd > like to discuss this in emacs-devel, at least get some opinions on > Christopher Wellon's solution, which seems very elegant. We should certainly take a look at it. But the built-in futures don't have to provide all the options. Just be functionally compatible. Christopher could pick up from that.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 18:49:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 14:49:23 2020
Received: from localhost ([127.0.0.1]:46381 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdeda-0001nE-SB
for submit <at> debbugs.gnu.org; Tue, 26 May 2020 14:49:23 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:51398)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jdedW-0001my-QD
for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 14:49:17 -0400
Received: by mail-wm1-f45.google.com with SMTP id u13so622593wml.1
for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 11:49:14 -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;
bh=qKDBWxM5ME9WV0JKLHRjiPEUyHxSlaspu6+8OnRo83E=;
b=ub5lbg9otsw8uTPDkuHd1EaEGblIvZt8cYkwWtw2lQD1Rz7rfN68a2bJHFCTNQFP4L
vDD3E6+tP7XjCUA2JqSZTZN0lrbWQQ0vkiWZIB97r/kG8YTdBT83DzsCA/C5hldois5M
oNw5agIUxNIe6PDBqgUUMf+5QDCkhyt7/jTydiT0m73EKD2K6DtRl5+5vz4lI2J/2IQh
o3+W4H+LjKCyl/XY74gSCHO9IIJVtdrm/MZZs15bj3Ig3WVhwtTnjRpsp4+yqVAzUayK
cIGLkeJK+3d4PocCTS2Intn+EN4vJjUi+iK+hxc6dlQOuAdtfMaANljXz+2oB9oqqy8Q
zztA==
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;
bh=qKDBWxM5ME9WV0JKLHRjiPEUyHxSlaspu6+8OnRo83E=;
b=neDY4h+PDDJyZW/STN0PPJA9E1PboIHtkFl4mZaOLN4XW8z2Iu2x9H6boy8ENUdqGg
kGjG6TOevah6xdAZteYzX98WfyTjyHAMOFZS2Jbq0jFKqvfqaLkjXbHOxOpAvrioqWHJ
h1+tEBvNdZWISMv0/rXHvexgizgz9p5G2jeQk0wf4IqvGgFy54/Qa5AMRjlq4ciJUorZ
H8a6fg44foT9nUKoBlvhCUktjcnakHXwga8KYWmUlEjFwC8pCp7X1B17kaxVGiz3JhzE
1b9EJyWJDC4FoeJ+rAWnM4dwV3MhW+oS2y5AHa86rFMyAFh+rJSDAVC6PnkbgzXsAOH/
4FHQ==
X-Gm-Message-State: AOAM530ePQE8ZOIdjDjtShHr23dlaR3Mp4UgNCe1+6+KDpu6byFot2Vh
JpbeRF3Y0yHmYhlHujtufJw=
X-Google-Smtp-Source: ABdhPJz2Eu2NW9XgG0G3QUjxyTZKsy0ybbQZ8EnW9zdYFXo7vkXCEUa8/mwg0bVQVOmzjl/JJPUDCA==
X-Received: by 2002:a1c:f301:: with SMTP id q1mr519221wmq.109.1590518947774;
Tue, 26 May 2020 11:49:07 -0700 (PDT)
Received: from krug ([89.180.149.243])
by smtp.gmail.com with ESMTPSA id 190sm387910wmb.23.2020.05.26.11.49.05
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 26 May 2020 11:49:06 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
<jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
<jwv1rn64n38.fsf-monnier+emacs@HIDDEN>
Date: Tue, 26 May 2020 19:49:04 +0100
In-Reply-To: <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
of "Tue, 26 May 2020 13:39:34 -0400")
Message-ID: <871rn6r0pr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org,
andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Stefan Monnier <monnier@HIDDEN> writes:
>> 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?
>
> Deal, at the condition that the code comes before I write the docstrings =
;-)
Okay. 2 patches attached (my version + your futures). Just search for
'WORLD CLASS DOCSTRING' and fill in your part.
For my part, really feels like I've reimplemented funcall.
Anyway both approaches lightly tested on this foo.el file:
;;; foo.el --- foobarbaz -*- lexical-binding:t; -*-
(setq-local eldoc-documentation-function #'eldoc-documentation-compose)
;; Callback approach
;;
(setq-local eldoc-documentation-functions nil)
(defun eldoc-cback-0 (cback &rest _)
(run-with-timer 0.22 nil
(lambda () (funcall cback (symbol-name (gensym "cback-0-"=
))))))
(defun eldoc-cback-1 (&rest _) (symbol-name (gensym "cback-1-")))
(defun eldoc-cback-2 (cback &rest _)
(run-with-timer 2.22 nil
(lambda () (funcall cback (symbol-name (gensym "cback-2-"=
))))))
(add-hook 'eldoc-documentation-functions #'eldoc-cback-0 00 t)
(add-hook 'eldoc-documentation-functions #'eldoc-cback-1 10 t)
(add-hook 'eldoc-documentation-functions #'eldoc-cback-2 20 t)
;; Very futuristic approach
;;
(setq-local eldoc-documentation-functions nil)
(defun eldoc-future-0 ()
(let ((f (eldoc-future-make)))=20
(run-with-timer 0.22 nil (lambda () (eldoc-future-set
f (symbol-name (gensym "future-0-"=
)))))
f))
(defun eldoc-future-1 () (symbol-name (gensym "future-1-")))
(defun eldoc-future-2 ()
(let ((f (eldoc-future-make)))
(run-with-timer 2.22 nil (lambda () (eldoc-future-set
f (symbol-name (gensym "future-2-"=
)))))
f))
(add-hook 'eldoc-documentation-functions #'eldoc-future-0 00 t)
(add-hook 'eldoc-documentation-functions #'eldoc-future-1 10 t)
(add-hook 'eldoc-documentation-functions #'eldoc-future-2 20 t)
> [ I like this deal: it's always better for someone else to write the
> docstrings, so at least 2 persons need to agree on what they think the
> code does (assuming the author of the code checks the resulting docstri=
ngs). ]
Yes, it's called cascade dev, and it gets a bad rep nowadays. Tho the
person who writes the docstrings usually goes first ;-)
Jo=C3=A3o
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=0001-Better-handle-asynchronously-produced-eldoc-docstrin.patch
From b97c0cfb0cbfea20cbf75ad7ea8abf9f4c51ec54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 16:39:40 +0100
Subject: [PATCH 1/2] Better handle asynchronously produced eldoc docstrings
No longer do clients of eldoc need to call eldoc-message (an internal
function) directly. They may return any non-nil, non-string value and
call a callback afterwards. This enables eldoc.el to exert control
over how (and crucially also when) to display the docstrings to the
user.
* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions):
Overhaul docstring.
(eldoc-documentation-compose, eldoc-documentation-default): Handle
non-nil, non-string values of elements of
eldoc-documentation-functions.
(eldoc-print-current-symbol-info): Redesign.
(eldoc--handle-multiline): New helper.
(eldoc--callback): New internal special var.
(Version): Bump to 1.1.0.
* lisp/hexl.el (hexl-print-current-point-info): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/cfengine.el (cfengine3-documentation-function):
Adjust to new eldoc-documentation-functions protocol.
* lisp/progmodes/elisp-mode.el
(elisp-eldoc-documentation-function): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/octave.el (octave-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/python.el (python-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
---
lisp/emacs-lisp/eldoc.el | 101 ++++++++++++++++++++++++++---------
lisp/hexl.el | 2 +-
lisp/progmodes/cfengine.el | 2 +-
lisp/progmodes/elisp-mode.el | 6 ++-
lisp/progmodes/octave.el | 4 +-
lisp/progmodes/python.el | 2 +-
6 files changed, 84 insertions(+), 33 deletions(-)
diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..fa36987014 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
;; Author: Noah Friedman <friedman@HIDDEN>
;; Keywords: extensions
;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
;; Package-Requires: ((emacs "26.3"))
;; This is a GNU ELPA :core package. Avoid functionality that is not
@@ -338,12 +338,24 @@ eldoc-display-message-no-interference-p
(defvar eldoc-documentation-functions nil
- "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point. It should return nil if there's no doc
-appropriate for the context. Typically doc is returned if point
-is on a function-like name or in its arg list.
+ "Hook of functions that produce doc strings.
+Each hook function should accept at least one argument CALLBACK
+and decide whether to display a doc short string about the
+context around point. If the decision and the doc string can be
+produced quickly, the hook function can ignore CALLBACK and
+immediately return the doc string, or nil if there's no doc
+appropriate for the context. Otherwise, if its computation is
+expensive or can't be performed directly, the hook function
+should arrange for CALLBACK to be asynchronously called at a
+later time, passing it either nil or the desired doc string. The
+hook function should then return a non-nil, non-string value.
+
+Note that this hook is only in effect if the value of
+`eldoc-documentation-function' (notice the singular) is bound to
+one of its pre-set values.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
Major modes should modify this hook locally, for example:
(add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,30 +363,30 @@ eldoc-documentation-functions
taken into account if the major mode specific function does not
return any documentation.")
+(defun eldoc--handle-multiline (res)
+ "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+ (if eldoc-echo-area-use-multiline-p res
+ (truncate-string-to-width
+ res (1- (window-width (minibuffer-window))))))
+
(defun eldoc-documentation-default ()
"Show first doc string for item at point.
Default value for `eldoc-documentation-function'."
- (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
- (when res
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (run-hook-with-args-until-success 'eldoc-documentation-functions
+ eldoc--callback))
(defun eldoc-documentation-compose ()
"Show multiple doc string results at once.
Meant as a value for `eldoc-documentation-function'."
- (let (res)
- (run-hook-wrapped
- 'eldoc-documentation-functions
- (lambda (f)
- (let ((str (funcall f)))
- (when str (push str res))
- nil)))
- (when res
- (setq res (mapconcat #'identity (nreverse res) ", "))
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (let ((res 0))
+ (run-hook-wrapped 'eldoc-documentation-functions
+ (lambda (f)
+ (let ((str (funcall f eldoc--callback)))
+ (if (stringp str) (funcall eldoc--callback str)
+ (when str (setq res (1+ res))))
+ nil)))
+ ;; play ball with `eldoc-print-current-symbol-info'
+ (if (plusp res) (1- res) "")))
(defcustom eldoc-documentation-function #'eldoc-documentation-default
"Function to call to return doc string.
@@ -408,6 +420,11 @@ eldoc--supported-p
;; there's some eldoc support in the current buffer.
(local-variable-p 'eldoc-documentation-function))))
+;; this variable should be unbound, but that confuses
+;; `describe-symbol' for some reason.
+(defvar eldoc--callback nil
+ "Dynamically bound. Passed to `eldoc-documentation-functions'.")
+
(defun eldoc-print-current-symbol-info ()
"Print the text produced by `eldoc-documentation-function'."
;; This is run from post-command-hook or some idle timer thing,
@@ -417,11 +434,43 @@ eldoc-print-current-symbol-info
;; Erase the last message if we won't display a new one.
(when eldoc-last-message
(eldoc-message nil))
- (let ((non-essential t))
+ (let ((non-essential t)
+ (buffer (current-buffer)))
;; Only keep looking for the info as long as the user hasn't
;; requested our attention. This also locally disables inhibit-quit.
(while-no-input
- (eldoc-message (funcall eldoc-documentation-function)))))))
+ (let* (;; `wanted' and `received' keep track of how many
+ ;; docstrings we expect from the clients. negative
+ ;; `wanted' means store docstring for later but don't
+ ;; message yet; likewise for a positive value, but we
+ ;; decrease it by one. Any other value (including 0)
+ ;; means the next time the callback is called we're
+ ;; composing and outputting whatever we got.
+ (wanted -1) (received '())
+ (eldoc--callback
+ (lambda (string)
+ (with-current-buffer buffer
+ (cond ((and (numberp wanted) (not (zerop wanted)))
+ (if (plusp wanted)
+ (setq wanted (1- wanted))) ; decf where art thou?
+ (push string received))
+ (wanted
+ (unless (string= string "") (push string received))
+ (setq wanted nil)
+ (eldoc-message
+ (eldoc--handle-multiline
+ (mapconcat #'identity (nreverse received) ", "))))
+ (t
+ ;; For now, silently swallow anything the
+ ;; client unexpectedly gives us
+ )))))
+ (res (funcall eldoc-documentation-function)))
+ (cond (;; we got a string, we should output immediately
+ (stringp res) (setq wanted t) (funcall eldoc--callback res))
+ (;; got something else, trust eldoc--callback will be called
+ res (setq wanted res))
+ (;; got nil, clear the echo area
+ t (eldoc-message nil)))))))))
;; If the entire line cannot fit in the echo area, the symbol name may be
;; truncated or eliminated entirely from the output to make room for the
diff --git a/lisp/hexl.el b/lisp/hexl.el
index cf7118f208..38eca77e26 100644
--- a/lisp/hexl.el
+++ b/lisp/hexl.el
@@ -515,7 +515,7 @@ hexl-current-address
(message "Current address is %d/0x%08x" hexl-address hexl-address))
hexl-address))
-(defun hexl-print-current-point-info ()
+(defun hexl-print-current-point-info (&rest _ignored)
"Return current hexl-address in string.
This function is intended to be used as eldoc callback."
(let ((addr (hexl-current-address)))
diff --git a/lisp/progmodes/cfengine.el b/lisp/progmodes/cfengine.el
index f25b3cb9e2..9a6d81ce06 100644
--- a/lisp/progmodes/cfengine.el
+++ b/lisp/progmodes/cfengine.el
@@ -1294,7 +1294,7 @@ cfengine3-make-syntax-cache
'symbols))
syntax)))
-(defun cfengine3-documentation-function ()
+(defun cfengine3-documentation-function (&rest _ignored)
"Document CFengine 3 functions around point.
Intended as the value of `eldoc-documentation-function', which see.
Use it by enabling `eldoc-mode'."
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index d37eb8c152..d7865a7319 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1402,8 +1402,10 @@ elisp--eldoc-last-data
or argument string for functions.
2 - `function' if function args, `variable' if variable documentation.")
-(defun elisp-eldoc-documentation-function ()
- "`eldoc-documentation-function' (which see) for Emacs Lisp."
+(defun elisp-eldoc-documentation-function (_ignored &rest _also-ignored)
+ "Contextual documentation function for Emacs Lisp.
+Intended to be placed in `eldoc-documentation-functions' (which
+see)."
(let ((current-symbol (elisp--current-symbol))
(current-fnsym (elisp--fnsym-in-current-sexp)))
(cond ((null current-fnsym)
diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index 352c1810d1..2cf305c404 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -1639,8 +1639,8 @@ octave-eldoc-function-signatures
(nreverse result)))))
(cdr octave-eldoc-cache))
-(defun octave-eldoc-function ()
- "A function for `eldoc-documentation-function' (which see)."
+(defun octave-eldoc-function (&rest _ignored)
+ "A function for `eldoc-documentation-functions' (which see)."
(when (inferior-octave-process-live-p)
(let* ((ppss (syntax-ppss))
(paren-pos (cadr ppss))
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 1ca9f01963..404a67ba9f 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -4571,7 +4571,7 @@ python-eldoc-function-timeout-permanent
:type 'boolean
:version "25.1")
-(defun python-eldoc-function ()
+(defun python-eldoc-function (&rest _ignored)
"`eldoc-documentation-function' for Python.
For this to work as best as possible you should call
`python-shell-send-buffer' from time to time so context in
--
2.20.1
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=0002-Reimplement-funcall-but-in-the-future.patch
From c039a4356fa363ef10b8320c3856eb3466eb32f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 26 May 2020 19:38:08 +0100
Subject: [PATCH 2/2] Reimplement funcall, but in the future
* lisp/emacs-lisp/eldoc.el (eldoc-future, eldoc-future-set)
(eldoc-future-set-call): New functions.
(eldoc-documentation-functions): Prepare for Stefan's genius
docstring.
(eldoc-documentation-default, eldoc-documentation-compose): Use
futuristic stuff.
---
lisp/emacs-lisp/eldoc.el | 54 ++++++++++++++++++++++++++--------------
1 file changed, 36 insertions(+), 18 deletions(-)
diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index fa36987014..e015076c4d 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -337,18 +337,32 @@ eldoc-display-message-no-interference-p
(not (or executing-kbd-macro (bound-and-true-p edebug-active))))
+;;;; Futuristic interlude
+(cl-defstruct (eldoc-future
+ (:conc-name eldoc-future--)
+ (:constructor eldoc-future-make ())) ; become Yoda we?
+ "<WORLD CLASS DOCSTRING>"
+ (value 'eldoc-future--unset)
+ callback)
+
+(defun eldoc-future-set (f v)
+ "<WORLD CLASS DOCSTRING>"
+ (cl-assert (eq (eldoc-future--value f) 'eldoc-future--unset))
+ (setf (eldoc-future--value f) v)
+ (when (eldoc-future--callback f)
+ (funcall (eldoc-future--callback f) v)))
+
+(defun eldoc-future-set-callback (f c)
+ "<WORLD CLASS DOCSTRING>"
+ (cl-assert (null (eldoc-future--callback f)))
+ (setf (eldoc-future--callback f) c)
+ (unless (eq (eldoc-future--value f) 'eldoc-future--unset)
+ (funcall c (eldoc-future--value f))))
+
+
(defvar eldoc-documentation-functions nil
"Hook of functions that produce doc strings.
-Each hook function should accept at least one argument CALLBACK
-and decide whether to display a doc short string about the
-context around point. If the decision and the doc string can be
-produced quickly, the hook function can ignore CALLBACK and
-immediately return the doc string, or nil if there's no doc
-appropriate for the context. Otherwise, if its computation is
-expensive or can't be performed directly, the hook function
-should arrange for CALLBACK to be asynchronously called at a
-later time, passing it either nil or the desired doc string. The
-hook function should then return a non-nil, non-string value.
+<WORLD CLASS DOCSTRING GOES HERE>
Note that this hook is only in effect if the value of
`eldoc-documentation-function' (notice the singular) is bound to
@@ -372,19 +386,23 @@ eldoc--handle-multiline
(defun eldoc-documentation-default ()
"Show first doc string for item at point.
Default value for `eldoc-documentation-function'."
- (run-hook-with-args-until-success 'eldoc-documentation-functions
- eldoc--callback))
+ (let ((x (run-hook-with-args-until-success 'eldoc-documentation-functions)))
+ (if (eldoc-future-p x) (eldoc-future-set-callback x eldoc--callback)
+ x)))
(defun eldoc-documentation-compose ()
"Show multiple doc string results at once.
Meant as a value for `eldoc-documentation-function'."
(let ((res 0))
- (run-hook-wrapped 'eldoc-documentation-functions
- (lambda (f)
- (let ((str (funcall f eldoc--callback)))
- (if (stringp str) (funcall eldoc--callback str)
- (when str (setq res (1+ res))))
- nil)))
+ (run-hook-wrapped
+ 'eldoc-documentation-functions
+ (lambda (f)
+ (let ((x (funcall f)))
+ (cond ((stringp x) (funcall eldoc--callback x))
+ ((eldoc-future-p x)
+ (eldoc-future-set-callback x eldoc--callback)
+ (setq res (1+ res))))
+ nil)))
;; play ball with `eldoc-print-current-symbol-info'
(if (plusp res) (1- res) "")))
--
2.20.1
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 17:39:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 13:39:45 2020
Received: from localhost ([127.0.0.1]:46319 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jddYG-00009E-J3
for submit <at> debbugs.gnu.org; Tue, 26 May 2020 13:39:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12584)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jddYF-00008z-1e
for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 13:39:43 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 333EA10093D;
Tue, 26 May 2020 13:39:37 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9DE7410083A;
Tue, 26 May 2020 13:39:35 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1590514775;
bh=p6zB6oKprJhduHuautFivhvJfVzI5seNS0GCne0f02M=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=USclucUES8WnHdnRR9vnyxhVRPQf/gvdxKbvraYnsDY8MoIuhfJn0fEoCZrIbI1fm
N5/keIf5ApZSzcIlO9ALcUUuvGRbz2FhmQbnG7ZBLCuLI8DvQ7Y+ExDFcLUHgncjQ8
6QHkLysqf90NY66P+6esvd02Ib6R2nLlJKTmtnFr8ehHxSjpmxM5bjA4/aFxk9k5V2
vflUOfy/yH5ouwpo3kNyQgB6T52/3iUmIlEnxrPXTyB0reM/dWVAJhHnRc/kEj0KUI
wALwj/htktWBDsW6x/wvGQWJtpFY1XvhhL5HM9xBOKm1eMVlgORJ2aHVJ51cwbshHG
P9q4gHHzstsnA==
Received: from milanesa (unknown [216.154.27.250])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 50EE91207D6;
Tue, 26 May 2020 13:39:35 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwv1rn64n38.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
<jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
Date: Tue, 26 May 2020 13:39:34 -0400
In-Reply-To: <877dwyr7b9.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Tue, 26
May 2020 17:26:34 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.086 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org,
andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> 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?
Deal, at the condition that the code comes before I write the docstrings ;-)
[ I like this deal: it's always better for someone else to write the
docstrings, so at least 2 persons need to agree on what they think the
code does (assuming the author of the code checks the resulting docstrings). ]
> 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.
I'm willing to tweak my vocabulary.
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:57:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 12:57:15 2020 Received: from localhost ([127.0.0.1]:46302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jdct9-0007bs-AB for submit <at> debbugs.gnu.org; Tue, 26 May 2020 12:57:15 -0400 Received: from mail-il1-f174.google.com ([209.85.166.174]:38824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jdct7-0007be-PP for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 12:57:14 -0400 Received: by mail-il1-f174.google.com with SMTP id q18so33207ilm.5 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 09:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ofp2oyKW8Zd+/QfNc+lJxDSt3eLPlfJ09m8Mgqyl/Tk=; b=bCUL8juBO5fgE0Ci4WJU6QGd7PpZlyy2v8u8tgEcyYhDxFse4eNJewsESR9Mu94Q/1 XWglMkIdWVgmeUY91UhN9igCaFUiFd9mazmwEU/yxj0Z/KHrMUqQ4TspBDiC4E2aC6Yo I8Sm8QJbX+u+4m9PMCrio8TLD1zAt+Q0b4gq5NybteCHF4wWK/8Qt8ZfHsRzrcKgDC5t 0U3C+GAm4psC3enWX7bBl7Xu4+6QCNSbMlGDevHdhim/NwSYdMxEQTnaSDlpfFtRyWxw zmlsRFM0XheukB3LH/CkbE01KN844n3YOXDzu/LLjxUzm3ycWrcG9IQMD96GHABm2QTt acRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ofp2oyKW8Zd+/QfNc+lJxDSt3eLPlfJ09m8Mgqyl/Tk=; b=q8pV4hRgrqA7s3hJ1152jH4UHUXlQj2ds7/6OpktmmboD7+xFC32qP7QWqX71SQ+wC MbxCxc1sLdKlNnvi1mdc3vqpULH7AMTRliqcnTst0btW4V9zK56wrp7PTo0aNP0FPXqG m5gFVHLrCeKV9TevbHj3jeWkVCAS0acgDJmdJPil7pmX3aqQQLpavnrEJ5aRWgdfQsM1 Re6VO3BKJXLdtTyqnKlI12NSw0R80FNOFESMuqxuz/DNy1c6talwX4RZds85vgb/SxHv 9VpXmzoGQZ9ABl1KMVP7yYp03ja6D/zcCPUB3cllT3phxpbGV4KcF7YJLNQEVZlc24mF Z/Pg== X-Gm-Message-State: AOAM531qa82XycN/WcdcURh4Xtmw8b3OZEz8MjwJ9DeKiEVjsNaumsZR sMemiUXWSoajkaqspGiBZDFv7aJ0Cgv1w3a22u0= X-Google-Smtp-Source: ABdhPJydgR/UtyU2dkfu/Lz7ObzMIYGroCU9OVnq3qlECKpxHlHpzdwg79nbaBNc6WiUmai03nNoC4uGqkL4npdwBX8= X-Received: by 2002:a92:485d:: with SMTP id v90mr1974528ila.125.1590512228093; Tue, 26 May 2020 09:57:08 -0700 (PDT) MIME-Version: 1.0 References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <563f298a-a0cb-044d-2619-068e8d30f119@HIDDEN> In-Reply-To: <563f298a-a0cb-044d-2619-068e8d30f119@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 26 May 2020 17:56:56 +0100 Message-ID: <CALDnm5224yxMwJed-qwjzV0+Q7A-P437VS=kf-jJZFmc7uruxQ@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Tue, May 26, 2020 at 2:32 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > On 26.05.2020 05:38, Stefan Monnier wrote: > >> Here's a modified approach that doesn't use a global var and should ma= ke it > >> easier to transition to using futures. > > I think at this stage, we should either start using futures or we shoul= d > > forget about ever using them. > We should certainly do it before Emacs 28 is released (so we won't have > to support whatever ad-hoc option is currently being proposed). Agree. By my estimate we have ~2 years to go, tho. And ad-hoc is a value judgement that you could apply to every part of Emacs could be improved (then someone else might call _that_ ad-hoc). Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:26:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 12:26:44 2020 Received: from localhost ([127.0.0.1]:46271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jdcPc-0006td-Hq for submit <at> debbugs.gnu.org; Tue, 26 May 2020 12:26:44 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:50455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jdcPa-0006tQ-7M for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 12:26:42 -0400 Received: by mail-wm1-f41.google.com with SMTP id v19so156919wmj.0 for <41531 <at> 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) 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) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN> <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN> <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> Date: Tue, 26 May 2020 17:26:34 +0100 In-Reply-To: <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Tue, 26 May 2020 11:56:12 -0400") Message-ID: <877dwyr7b9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) [ 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 <monnier@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:03:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 12:03:58 2020
Received: from localhost ([127.0.0.1]:46241 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdc3Z-0006LT-Lh
for submit <at> debbugs.gnu.org; Tue, 26 May 2020 12:03:58 -0400
Received: from mail-wm1-f66.google.com ([209.85.128.66]:34509)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jdc3X-0006LD-4Q
for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 12:03:56 -0400
Received: by mail-wm1-f66.google.com with SMTP id u26so308556wmn.1
for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 09:03:55 -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=cI9f1J+GfuIjdJGbEjW+fz6xOAvD28VIvKEEWidEceI=;
b=B0llQ/l4s9l/UAERZAMb1s6XeQvZkcOUktjlecX5wK8zGmigEbKr2FEGo364EeRqD4
VbUT4yc3lUK9wd9H2fNJmdxZcyPSud23VQNDxkkR1Ee7L383Vxe9V4mXxe1EygUwkDHY
N2fZDxCpzN6eLU9NGts+oOZqdP9ybcuPJIeQWWXqXRr60qEIImYaVk698ny2kinoVyzJ
0HafZQHT4MXcs6oLbcfE/1UhZR01zmJc4ZyI2Sj84Jb8my98VBYTpepdd3T1oPWffncM
oxfBVM4jq6Nn983z8PYAfTbaPrlM0ZivlJcB7JCcSetINinogNKaerk4J8C1Peefb8ch
j9RQ==
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=cI9f1J+GfuIjdJGbEjW+fz6xOAvD28VIvKEEWidEceI=;
b=JpPBnX2YJvPviUVntujWE3J72COhoZoaTBpksz8mrjlzY6OoJ/cR341ABFVGWg6fDj
SkndG/VqOHuo555fKnFsaBVEH4nM9lEeUq53NspiWemld9da3Pvia0HpGlXOA8oR9uyU
GeYErK31GHpBjl1CST/uI+Fc7SF5EpOTpyllh7hMbApA7wqE9wyC8ga3zdeKJpmjndxL
rXBBPn9hU3IBS5OqUGv4OxaQxzISY745gJh9JPiMVIXmzHMQGB/5V7+izf1jROPIwtAG
ewpY3UNx1wnnCQzQjLqN1L4p2iLZ4KuTTFB77pI5qXk1Fj/xnvhRofigcb34u4lBnToH
WvPg==
X-Gm-Message-State: AOAM532KW+WUGIpot+bhpWo1saw3Hs8hi753Z9cAspBKn58uuA7a0E13
WDW+3BCzrLz7y3Zkt1D8+Ds=
X-Google-Smtp-Source: ABdhPJzQgEEmr1vJOAI+uQVRfXDn9e2MOeR8YghOaLiN6CDsq41ltdzyY+LjaMmhbDh40vE3tvDrwA==
X-Received: by 2002:a05:600c:34c:: with SMTP id
u12mr2039218wmd.4.1590509029091;
Tue, 26 May 2020 09:03:49 -0700 (PDT)
Received: from krug ([89.180.149.243])
by smtp.gmail.com with ESMTPSA id p10sm266989wra.78.2020.05.26.09.03.47
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 26 May 2020 09:03:48 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<87k10zsd85.fsf@HIDDEN>
<384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN>
Date: Tue, 26 May 2020 17:03:46 +0100
In-Reply-To: <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> (Dmitry Gutov's
message of "Tue, 26 May 2020 16:57:13 +0300")
Message-ID: <87ftbmr8d9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> writes:
> On 26.05.2020 04:21, Jo=C3=A3o T=C3=A1vora wrote:
>> Dmitry Gutov <dgutov@HIDDEN> writes:
> They also use *special* variables? Flymake's API looks fairly clean
> (you call back to REPORTER-FN, that's very reasonable), but I haven't
> looked under the covers yet.
REPORTER-FN, is just another name for CALLBACK. Flymake doesn't need
these special variables because its API doesn't go through an old,
argless shim like eldoc-documentation-function, singular. If it did, it
would need a special variable, which is not such a ghoulish thing
either.
>> 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"
>
> To clarify, you actually included two proposals (behavior with patch
> 1, and with both patch 1 and patch 2 applied). The first one is the
> one I really didn't like. The second one is better, API-wise, but will=20
> conflict with the futures-based approach.
It's not a conflict at all. When you do the futures-based approach
you're going to rewrite the docstring to augment the API. You do the
same here: just add this to the docstring:
"If you prefer, ignore CALBACK and return a `future-future' object from
this function".
How is that different from:
"If you prefer, instead of returning a (:ASYNC . FUNCTION) cons,
return a `future-future' object from this function""
???
>> I'll leave that for later. Specifically, eldoc--handle-multiline has to
>> do quite a bit more handling (to satisfy Andrey's expectations).
> I'm not so such it's independent. The complexity of implementing that
> would certainly vary.
It is quite independent. Just look at the last patch I sent Stefan.
There's only one call to eldoc--handle-multiline (in fact we could ditch
it entirely).
> BTW, maybe eldoc-message should handle this after all? Since it's the
> last link in the chain. Or even do that in the default value of=20
> eldoc-message-function (create a wrapper for minibuffer-message).
Doesn't work well becasue eldoc-message is called by both the produced
_and_ the backend, as I showed you earlier. And it certainly doesn't
work with eldoc-documentation-compose.
>> Replying to parts from the other discussion in the Github tracker now.
>>=20
>>> OK, another question: if the result still /valid/?
>> ^^ Assuming you mean "is".
>> Well, if the client discovers the result to be invalid, ...
>
> So the client will have to save and then compare the current buffer,
> the value of point and buffer-chars-modification-tick now?
Ah, _that_ validity. No, no, never do that. The client should have no
idea of it. In the framework you either make the callback a noop, or
you set it aborted for the client to save some work. Or both.
>>> 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.
>
> Futures are not particularly more complex to use.
Sure, but they are _more_ complex. And you're mixing up two things:
futures _aren't_ the only way -- or even a particularly easy way -- to
signal to the clients that thety can give up their efforts. All the
client needs to have is access to an object that's shared between it and
the framework. That object _needn't_ be a first-class CLOS object or
struct. It can be a function.
>>> 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.
>
> It can (barring any complex abstractions). It created the process,
> after all.
Not really, it asked a client to solve a problem, doesn't know how the
client if the client is doing by async process or cointoss.
>> 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.
>
> That would be none of ElDoc's business, though. But the implementation
> will get to be as complex as it needs.
_That's_ why an abort switch whose contract is "kill this immediately"
is a bad idea. An abort switch whose contract is "just letting you know
I don't need this anymore" is better. But again, in eldoc, not so
useful. And again, nothing to do with futures here.
>> 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:
>
> The one thing I want to avoid doing is changing the callsig of every
> documentation function, and then changing them back when we switch to=20
> futures.
So _don't_ change the "callsig". If you implement futures you _are_
going to change the protocol anyway, i.e. write new stuff in the
docstring.
>> 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.
>
> Um, I'm pretty sure we guarantee a fair amount of stability.
That's not what Stefan said here:
https://github.com/joaotavora/eglot/pull/459#issuecomment-633634034
And that's not what the Dmitry from 2016 wrote in xref.el
+;; NOTE: The xref API is still experimental and can change in major,
+;; backward-incompatible ways. Everyone is encouraged to try it, and
+;; report to us any problems or use cases we hadn't anticiated, by
+;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
That has been sitting there for almost three Emacs major versions (in
fact you added it after the initial 25 release). All I'm asking is for
a little such flexibility with eldoc.
>> 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.
>
> Kill the arg in all built-in functions, as well as in external
> consumers?
Yes, if we discover there aren't so many. Currently there are 5 users
in Emacs proper, 0 in GNU ELPA and quite sure 0 elsewhere in the world.
So 0 external consumers. Do you really think if I push my patch there
will be hordes of eldoc-documentation-functions users out there using
this horrible futureless API that I'm proposing? There won't, and I'm
happy to add a big disclaimer to the top of the eldoc.el file.
But if you really think we wouldn't be able to bring ourselves to kill
the arg, then just reintroduce eldoc-documentation-callback, and kill
_that_ later on. Or just don't kill the arg, period.
It just looks like you're holding this problem hostage to introducing
some kind of rushed futures solution. I don't agree with either of
these things. I think this particular problem shouldn't be held hostage
to rearchitecting async in Emacs, laudable and useful a goal as that
might be. And I think a futures library should be well thought out: I'd
like to discuss this in emacs-devel, at least get some opinions on
Christopher Wellon's solution, which seems very elegant.
In the meantime, I have a working patch that follows current coding
practice, solves this problem and in no way prevents or interferes with
future work.
Anyway, see the patch I sent to Stefan.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 15:56:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 11:56:28 2020
Received: from localhost ([127.0.0.1]:46237 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdbwJ-00069m-Le
for submit <at> debbugs.gnu.org; Tue, 26 May 2020 11:56:28 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13073)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jdbwI-00069Q-Az
for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 11:56:26 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D459344095C;
Tue, 26 May 2020 11:56:19 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F2A6D440947;
Tue, 26 May 2020 11:56:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1590508573;
bh=tjT3VvlwmGlj8Sh6s0htvR9NsecfKOfIJZoasKN3nVo=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=CeLv/2WgzyOp8ABYIzkROZgf1RRwBNINnHv5HP27lgbtMKozOtRsZ7JwYqZBWytAJ
1ad8TmFuUEqGxZ83SHtVbOtPjixwRqSNcO0dTm913qY/M2ny7K6xd6go0POOXB3s0W
0lPrqk/Nux28RmYyCHB5FC6PM4Gk47z9l2Y6/wKm0PQQ0ht3gecSNK/+8dqopbFFfX
qOdYMoT+0telLfpMVXUbAtzVhLREANn7VA/NEo+H1EbfwvA4MO7OIXkrob3SIurSKe
fZfsMeBlra8p70v4WSCBny3WybteNZa/44tb5ZD1cL41HxUt0f5dewvj0i8T3ouA/V
u8EG3I1jahqVQ==
Received: from milanesa (unknown [216.154.27.250])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6D7ED120388;
Tue, 26 May 2020 11:56:13 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
Date: Tue, 26 May 2020 11:56:12 -0400
In-Reply-To: <87pnaqrae9.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Tue, 26
May 2020 16:19:58 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.097 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> 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).
> 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.
> 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.
> 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.
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 15:20:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 11:20:25 2020
Received: from localhost ([127.0.0.1]:46112 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdbNC-000372-9u
for submit <at> debbugs.gnu.org; Tue, 26 May 2020 11:20:25 -0400
Received: from mail-wr1-f54.google.com ([209.85.221.54]:46551)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jdbN9-00036E-2f
for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 11:20:09 -0400
Received: by mail-wr1-f54.google.com with SMTP id x6so7160918wrm.13
for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 08:20:07 -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;
bh=g2a6+wAc582ZwT22C/XySWFfWQZiYYypJZAtnJ6rs3w=;
b=BlXhZx5gWj3DdIi5TMSH3h3WTOn0JVmRz4rmySZpD2GsY1SMohDYsz2ACRsZoyzdil
+GMOWs5/sdmGE9PzJe9hYXPXAcY7lii2HWI54RloMgzgLpxZPFBlWE1FmzPYcvrYPPTg
HZ00De0LKK0vNG4Dr1ZNBpyY9S5MUAIFeqirQrosfha9hxpNPhTesDHlOJrUykh9dmPP
GVFyYDwZIJvnGAYOuWkW7kKttaeQYhsVVodjw/bx1GU8S3URsVSfjUwLh1lBAMzP/ris
xH+5OYcwGVxKKnmtYXMQxed5oVglldpwHIKEu4S0NBx+RieUozCIT5xrAXf4PfYVHzV+
kTUw==
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;
bh=g2a6+wAc582ZwT22C/XySWFfWQZiYYypJZAtnJ6rs3w=;
b=P0SPDiN4F4koodadboMzAlt9r4zle9dY3I67/GAmozCg7DkdtBu4tPejsjSb4I9VOd
8WFymY8inPGeUQjBzKlL6/Fhj2U8u2XIas4y1CVAkmapigns+Z/TMmE0M7rRtC4z5Hvn
DsCxdGoeAYk7medG2YZnlbGyT74nH25ns9CxeSA2L4LOwSooLQaMDxPz4cCPX+mIMkFj
PtukhNbUVM8kFwASt1i45FGKmMsWwAn5DcaENX37OaaWsaWAMI71t+X9DN1A2/SbT4vV
IabwWxIepMAunjcjY83cWtLksJEskdBnsZa9lE3h+AznjUsxpzjqaIWi5cwRzBbHyprw
4A1A==
X-Gm-Message-State: AOAM532lJDFL/LINs+8g5V5hLHK/LaLBdLpnqg3LeNa3FB6hmiJV1J+J
ch9vt7VhZKjDGQXD/YF0fBI=
X-Google-Smtp-Source: ABdhPJzUKF/j7Cz0Sfpe4V0NSE0JGpq2wrin2k/8K7DHBLdquQQPUhTv84F6JQ2azxn4kNZuinir9g==
X-Received: by 2002:adf:e5c8:: with SMTP id a8mr19575622wrn.335.1590506401280;
Tue, 26 May 2020 08:20:01 -0700 (PDT)
Received: from krug ([89.180.149.243])
by smtp.gmail.com with ESMTPSA id k13sm20992843wmj.40.2020.05.26.08.19.59
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 26 May 2020 08:20:00 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
<jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
Date: Tue, 26 May 2020 16:19:58 +0100
In-Reply-To: <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
of "Tue, 26 May 2020 10:53:38 -0400")
Message-ID: <87pnaqrae9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Stefan Monnier <monnier@HIDDEN> writes:
>> But really: now we have deadlock too? I just want to solve this
>> problem: please let's commit something, and move on to the next bug.
>
> Can you use the sample `eldoc-future-*` code I sent earlier?
>
> Stefan
It's not complete, is it? And how to I use it to solve the
eldoc-documentation-compose problem? 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?
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.
Jo=C3=A3o
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=0001-eldoc-async-v3.patch
From 0227a048cc7f88c5e4d773eac2ec8366056f3a6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 16:39:40 +0100
Subject: [PATCH] Better handle asynchronously produced eldoc docstrings
No longer do clients of eldoc need to call eldoc-message (an internal
function) directly. They may return any non-nil, non-string value and
call a callback afterwards. This enables eldoc.el to exert control
over how (and crucially also when) to display the docstrings to the
user.
* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions):
Overhaul docstring.
(eldoc-documentation-compose, eldoc-documentation-default): Handle
non-nil, non-string values of elements of
eldoc-documentation-functions.
(eldoc-print-current-symbol-info): Redesign.
(eldoc--handle-multiline): New helper.
(eldoc--callback): New internal special var.
(Version): Bump to 1.1.0.
* lisp/hexl.el (hexl-print-current-point-info): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/cfengine.el (cfengine3-documentation-function):
Adjust to new eldoc-documentation-functions protocol.
* lisp/progmodes/elisp-mode.el
(elisp-eldoc-documentation-function): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/octave.el (octave-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/python.el (python-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
---
lisp/emacs-lisp/eldoc.el | 101 ++++++++++++++++++++++++++---------
lisp/hexl.el | 2 +-
lisp/progmodes/cfengine.el | 2 +-
lisp/progmodes/elisp-mode.el | 6 ++-
lisp/progmodes/octave.el | 4 +-
lisp/progmodes/python.el | 2 +-
6 files changed, 84 insertions(+), 33 deletions(-)
diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..dcd28fb082 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
;; Author: Noah Friedman <friedman@HIDDEN>
;; Keywords: extensions
;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
;; Package-Requires: ((emacs "26.3"))
;; This is a GNU ELPA :core package. Avoid functionality that is not
@@ -338,12 +338,24 @@ eldoc-display-message-no-interference-p
(defvar eldoc-documentation-functions nil
- "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point. It should return nil if there's no doc
-appropriate for the context. Typically doc is returned if point
-is on a function-like name or in its arg list.
+ "Hook of functions that produce doc strings.
+Each hook function should accept at least one argument CALLBACK
+and decide whether to display a doc short string about the
+context around point. If the decision and the doc string can be
+produced quickly, the hook function can ignore CALLBACK and
+immediately return the doc string, or nil if there's no doc
+appropriate for the context. Otherwise, if its computation is
+expensive or can't be performed directly, the hook function
+should arrange for CALLBACK to be asynchronously called at a
+later time, passing it either nil or the desired doc string. The
+hook function should then return a non-nil, non-string value.
+
+Note that this hook is only in effect if the value of
+`eldoc-documentation-function' (notice the singular) is bound to
+one of its pre-set values.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
Major modes should modify this hook locally, for example:
(add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,30 +363,30 @@ eldoc-documentation-functions
taken into account if the major mode specific function does not
return any documentation.")
+(defun eldoc--handle-multiline (res)
+ "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+ (if eldoc-echo-area-use-multiline-p res
+ (truncate-string-to-width
+ res (1- (window-width (minibuffer-window))))))
+
(defun eldoc-documentation-default ()
"Show first doc string for item at point.
Default value for `eldoc-documentation-function'."
- (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
- (when res
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (run-hook-with-args-until-success 'eldoc-documentation-functions
+ eldoc--callback))
(defun eldoc-documentation-compose ()
"Show multiple doc string results at once.
Meant as a value for `eldoc-documentation-function'."
- (let (res)
- (run-hook-wrapped
- 'eldoc-documentation-functions
- (lambda (f)
- (let ((str (funcall f)))
- (when str (push str res))
- nil)))
- (when res
- (setq res (mapconcat #'identity (nreverse res) ", "))
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (let ((res 0))
+ (run-hook-wrapped 'eldoc-documentation-functions
+ (lambda (f)
+ (let ((str (funcall f eldoc--callback)))
+ (if (stringp str) (funcall eldoc--callback str)
+ (setq res (1+ res)))
+ nil)))
+ ;; play ball with `eldoc-print-current-symbol-info'
+ (if (plusp res) (1- res) "")))
(defcustom eldoc-documentation-function #'eldoc-documentation-default
"Function to call to return doc string.
@@ -408,6 +420,11 @@ eldoc--supported-p
;; there's some eldoc support in the current buffer.
(local-variable-p 'eldoc-documentation-function))))
+;; this variable should be unbound, but that confuses
+;; `describe-symbol' for some reason.
+(defvar eldoc--callback nil
+ "Dynamically bound. Passed to `eldoc-documentation-functions'.")
+
(defun eldoc-print-current-symbol-info ()
"Print the text produced by `eldoc-documentation-function'."
;; This is run from post-command-hook or some idle timer thing,
@@ -417,11 +434,43 @@ eldoc-print-current-symbol-info
;; Erase the last message if we won't display a new one.
(when eldoc-last-message
(eldoc-message nil))
- (let ((non-essential t))
+ (let ((non-essential t)
+ (buffer (current-buffer)))
;; Only keep looking for the info as long as the user hasn't
;; requested our attention. This also locally disables inhibit-quit.
(while-no-input
- (eldoc-message (funcall eldoc-documentation-function)))))))
+ (let* (;; `wanted' and `received' keep track of how many
+ ;; docstrings we expect from the clients. negative
+ ;; `wanted' means store docstring for later but don't
+ ;; message yet; likewise for a positive value, but we
+ ;; decrease it by one. Any other value (including 0)
+ ;; means the next time the callback is called we're
+ ;; composing and outputting whatever we got.
+ (wanted -1) (received '())
+ (eldoc--callback
+ (lambda (string)
+ (with-current-buffer buffer
+ (cond ((and (numberp wanted) (not (zerop wanted)))
+ (if (plusp wanted)
+ (setq wanted (1- wanted))) ; decf where art thou?
+ (push string received))
+ (wanted
+ (unless (string= string "") (push string received))
+ (setq wanted nil)
+ (eldoc-message
+ (eldoc--handle-multiline
+ (mapconcat #'identity (nreverse received) ", "))))
+ (t
+ ;; For now, silently swallow anything the
+ ;; client unexpectedly gives us
+ )))))
+ (res (funcall eldoc-documentation-function)))
+ (cond (;; we got a string, we should output immediately
+ (stringp res) (setq wanted t) (funcall eldoc--callback res))
+ (;; got something else, trust eldoc--callback will be called
+ res (setq wanted res))
+ (;; got nil, clear the echo area
+ t (eldoc-message nil)))))))))
;; If the entire line cannot fit in the echo area, the symbol name may be
;; truncated or eliminated entirely from the output to make room for the
diff --git a/lisp/hexl.el b/lisp/hexl.el
index cf7118f208..38eca77e26 100644
--- a/lisp/hexl.el
+++ b/lisp/hexl.el
@@ -515,7 +515,7 @@ hexl-current-address
(message "Current address is %d/0x%08x" hexl-address hexl-address))
hexl-address))
-(defun hexl-print-current-point-info ()
+(defun hexl-print-current-point-info (&rest _ignored)
"Return current hexl-address in string.
This function is intended to be used as eldoc callback."
(let ((addr (hexl-current-address)))
diff --git a/lisp/progmodes/cfengine.el b/lisp/progmodes/cfengine.el
index f25b3cb9e2..9a6d81ce06 100644
--- a/lisp/progmodes/cfengine.el
+++ b/lisp/progmodes/cfengine.el
@@ -1294,7 +1294,7 @@ cfengine3-make-syntax-cache
'symbols))
syntax)))
-(defun cfengine3-documentation-function ()
+(defun cfengine3-documentation-function (&rest _ignored)
"Document CFengine 3 functions around point.
Intended as the value of `eldoc-documentation-function', which see.
Use it by enabling `eldoc-mode'."
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index d37eb8c152..d7865a7319 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1402,8 +1402,10 @@ elisp--eldoc-last-data
or argument string for functions.
2 - `function' if function args, `variable' if variable documentation.")
-(defun elisp-eldoc-documentation-function ()
- "`eldoc-documentation-function' (which see) for Emacs Lisp."
+(defun elisp-eldoc-documentation-function (_ignored &rest _also-ignored)
+ "Contextual documentation function for Emacs Lisp.
+Intended to be placed in `eldoc-documentation-functions' (which
+see)."
(let ((current-symbol (elisp--current-symbol))
(current-fnsym (elisp--fnsym-in-current-sexp)))
(cond ((null current-fnsym)
diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index 352c1810d1..2cf305c404 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -1639,8 +1639,8 @@ octave-eldoc-function-signatures
(nreverse result)))))
(cdr octave-eldoc-cache))
-(defun octave-eldoc-function ()
- "A function for `eldoc-documentation-function' (which see)."
+(defun octave-eldoc-function (&rest _ignored)
+ "A function for `eldoc-documentation-functions' (which see)."
(when (inferior-octave-process-live-p)
(let* ((ppss (syntax-ppss))
(paren-pos (cadr ppss))
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 1ca9f01963..404a67ba9f 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -4571,7 +4571,7 @@ python-eldoc-function-timeout-permanent
:type 'boolean
:version "25.1")
-(defun python-eldoc-function ()
+(defun python-eldoc-function (&rest _ignored)
"`eldoc-documentation-function' for Python.
For this to work as best as possible you should call
`python-shell-send-buffer' from time to time so context in
--
2.20.1
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 14:53:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 10:53:49 2020
Received: from localhost ([127.0.0.1]:46070 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdaxh-0002TV-5i
for submit <at> debbugs.gnu.org; Tue, 26 May 2020 10:53:49 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39073)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jdaxg-0002TJ-EM
for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 10:53:48 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E44641008C8;
Tue, 26 May 2020 10:53:42 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5DB34100419;
Tue, 26 May 2020 10:53:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1590504821;
bh=yVMSWbimjhFivPQURnXogzG4H4cbhGPSW34L9PqFU6E=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=CKsf0RELl1wEHYov0YeqOL5R2QPZFWJHgdqbe2mEBqPFTG4TdO66sfzfUjpnlf7pS
W9Yvt8m7Q3h/KARDxjuJPr5aOoDLPLThWyvMbyty2TAT8hj07Nn2ic19ZNzwjkKOBd
rpOEPi1cjZ15YZ5rTe6SRCLIVjfOIT/38yFSt8ZFjbJ7cqhczeI5X0g/lhQviAqULw
EqdO4F8nJS3BxctK5GaedvLX24PifWUTwy7pOA3kTAUpzfjv6ik69wtxlzw8dPfSzt
pxgtx+bSnbKZdPDQ2Mku/n/ZiZoAjVNMhgBarFSpebcDXK+2NGhvRXRDhdLP0x0Y2a
6jVSZSJWaBKYg==
Received: from milanesa (unknown [216.154.27.250])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E46401204BD;
Tue, 26 May 2020 10:53:40 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
<jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
Date: Tue, 26 May 2020 10:53:38 -0400
In-Reply-To: <87blmbrlda.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Tue, 26
May 2020 12:22:57 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.088 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> But really: now we have deadlock too? I just want to solve this
> problem: please let's commit something, and move on to the next bug.
Can you use the sample `eldoc-future-*` code I sent earlier?
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 26 May 2020 13:57:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 09:57:24 2020 Received: from localhost ([127.0.0.1]:46014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jda55-00017p-FU for submit <at> debbugs.gnu.org; Tue, 26 May 2020 09:57:23 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:37588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jda53-00017a-98 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 09:57:22 -0400 Received: by mail-wr1-f42.google.com with SMTP id x13so5845015wrv.4 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 06:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EybqiaDOwRdFbRmxeL7fOULWe099yWtPh4HpMgOSU5s=; b=Jv/7hSkBiji4dtzzBpsFfglD+CE9nLg36c8rbvZurcVHSvJ/Ff7NdnAkcU/dae5Zy8 jkYOhlpHbuenwK5Mp7C+/Y3Xoj7/dhrH/q8q4PzKQ617tI9wsYEY9m4CgytZCjTzJ7SO 93LDj6d0ZT3BVc75TuheH+gA0RPm6Mu/DXB9/H0CRC5piitfsl1Ym//moZNOWSzB1r2j eefGK88+hjqp++87fuNOoCkcfaGQadFVTiwqW/Bvl8oEeQBGP0qaWME707F7gdfUWQ45 J6MRJNMTn5q1AkB8DQTsPJbtMwNBKjkYX2fCm+V9QD41424smvU7pENB4xoLBGPZtzrf FCsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EybqiaDOwRdFbRmxeL7fOULWe099yWtPh4HpMgOSU5s=; b=N8U7zz8gxXvZ1FwRuRsg9NB5Mipk8Y5VoZOq3+jPV8Xk3RdLXwqdaU3LZJEsKsWjDY 3BS+nWRRWlclGSin/ala9bEAlHU0Pqivqon2kzr9yOQUny66lFsIXWeQjJ8HgzRJfCr9 4bXwO3JCFrizerqKxZ+F8adjW804zl/rpqFELLjLR7YCy5zXwRK03SXxxxsdj7xDHikF 2+NE7EwIwB0E0ErWm76xo15LprWPJzOY5NnkEo4BejMj9fMKz7pYYy9deTpMqD+CUZcT oXB34cEA8Xv6/ZpP8fQgS0pyh/WAdEVKwb2lLGO/MVvRV2kcISV4NknC0lSef/uhh7oj oYsQ== X-Gm-Message-State: AOAM53012N/1OLkz+e2vAC3cEzMxK6/qgZmfMS/q3YjVTVGVS5Ei73+J itFjafl0iSEj1pnMX2Hn520= X-Google-Smtp-Source: ABdhPJxhtJ1qsbGvCEuos2NEsO/bHWQOzPNs0rpPF9EUEoQ7KvniqrzaVFm9iUTt6RrprvSU9Cadbg== X-Received: by 2002:a05:6000:11ca:: with SMTP id i10mr20825580wrx.10.1590501435159; Tue, 26 May 2020 06:57:15 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id o20sm9571670wra.29.2020.05.26.06.57.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 06:57:14 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> Date: Tue, 26 May 2020 16:57:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87k10zsd85.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 26.05.2020 04:21, João Távora wrote: > Dmitry Gutov <dgutov@HIDDEN> writes: > >> On 25.05.2020 20:04, João Távora 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. It's a simple stand-in, easy to replace. > I prefer my > version, which matches what flymake.el, url.el, jsonrpc.el, sly.el and > others do. They also use *special* variables? Flymake's API looks fairly clean (you call back to REPORTER-FN, that's very reasonable), but I haven't looked under the covers yet. >> If you like, we could simplify the returned objects to be just FETCHER >> (as documented in the patch) rather than (:async . FETCHER). But the >> 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. I think it's more explicit, and once you understand it, it clicks. But that choice is not important to me. > 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" To clarify, you actually included two proposals (behavior with patch 1, and with both patch 1 and patch 2 applied). The first one is the one I really didn't like. The second one is better, API-wise, but will conflict with the futures-based approach. >> There also exist a possible modification of this patch with a bit of >> functional programming where both calls to eldoc--handle-multiline >> 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). I'm not so such it's independent. The complexity of implementing that would certainly vary. BTW, maybe eldoc-message should handle this after all? Since it's the last link in the chain. Or even do that in the default value of eldoc-message-function (create a wrapper for minibuffer-message). > 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, ... So the client will have to save and then compare the current buffer, the value of point and buffer-chars-modification-tick now? >> 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. Futures are not particularly more complex to use. >> 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. It can (barring any complex abstractions). It created the process, after all. > 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. That would be none of ElDoc's business, though. But the implementation will get to be as complex as it needs. > 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: The one thing I want to avoid doing is changing the callsig of every documentation function, and then changing them back when we switch to futures. > 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. Um, I'm pretty sure we guarantee a fair amount of stability. > 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. Kill the arg in all built-in functions, as well as in external consumers?
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 26 May 2020 13:32:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 09:32:39 2020 Received: from localhost ([127.0.0.1]:44421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jdZh8-00009c-UJ for submit <at> debbugs.gnu.org; Tue, 26 May 2020 09:32:39 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:32938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1jdZh7-00009P-ES for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 09:32:38 -0400 Received: by mail-wr1-f41.google.com with SMTP id l11so20467610wru.0 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 06:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UPfhAfS7kdMLfVcbyYc8ssasrrGiELu2mWteZ5nypYw=; b=dylSPGqLbiLLYfxtzap47N3AlNih4VLBwO+MJ/TGt/IXmP8l1FUdjy9odAgjYiMTck cs1i++dgvAbGBz/3yllXRgvbpRxvy9Bl9pzmQqz6b8Ngk6dFFHaASw2EKApV+eU5pzJQ hgZKoniCNTabsjcPVlRj5DMMEg7qKLtJOXERE0KqKlHUT2hU8fIcaqJPwZ6rJFVt6JE1 GJvnyW8AEwr2Qhad5ATda390d0gkm0b43wt5gKgr7+4d5MmpI4hEWq/fEjO8GJ6QWBDi Hk06xV7jOMcGE5l1c4GkR6ly8Z5w40mfMM2qB0iVTNy2eGHABNNDVRHoq/m2ykllucFj 3xkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UPfhAfS7kdMLfVcbyYc8ssasrrGiELu2mWteZ5nypYw=; b=jywV/1+TmfoukT5S8RHffrsdSUwMgF35C9LsB1RTEXPBB5Et9KQlfHoMt898f/6cXQ Dt8j35QxbfTUpmk62Cep/vnx2PjZqOUYEa1MalDrrSCqwUQbwNvjoqrW5m/E9/Fu3t+D AjaEYKTlmTf5FKFNR+FQPq5AGOYH9a2ZlbN6wpVNOxKsOWW88/s6PWVAF6+3FDnRziT8 Audt7U2Kx2uB5Kbxc/HTbF04qKLWXfyv7JxR8+BopKD1APijaMQ3fyDUfcc1O8gednmL Y0thqV/y7AS/2jqdopt0dR7ww5fljA9AzoGK+sWxsiThYFd84xxispHUNrdzT0QktYol JNCg== X-Gm-Message-State: AOAM531bAjpBdiEIOkartLYOrqabP7Le23VOX51L/vdfWbxadrYw5yy3 J0mcejnTtjzQyF6j4pinb/k= X-Google-Smtp-Source: ABdhPJygi00v1iVC99ZGPNnX2w9RzJgklkRhUPFSomEFslqJiemHyn6PL+dZIhA1sa+lDbISTVNX8A== X-Received: by 2002:adf:9545:: with SMTP id 63mr18545049wrs.303.1590499951479; Tue, 26 May 2020 06:32:31 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a14sm3037074wrv.20.2020.05.26.06.32.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 06:32:30 -0700 (PDT) Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends To: Stefan Monnier <monnier@HIDDEN> References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <563f298a-a0cb-044d-2619-068e8d30f119@HIDDEN> Date: Tue, 26 May 2020 16:32:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <jwv367nqv52.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 26.05.2020 05:38, Stefan Monnier wrote: >> Here's a modified approach that doesn't use a global var and should make it >> easier to transition to using futures. > > I think at this stage, we should either start using futures or we should > forget about ever using them. We should certainly do it before Emacs 28 is released (so we won't have to support whatever ad-hoc option is currently being proposed). I just don't have the time to work on futures right now. If this bug can wait until this weekend, at least, we can reconvene after.
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.Received: (at 41531) by debbugs.gnu.org; 26 May 2020 11:23:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 26 07:23:07 2020 Received: from localhost ([127.0.0.1]:44262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1jdXfn-0003M5-9w for submit <at> debbugs.gnu.org; Tue, 26 May 2020 07:23:07 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:54047) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1jdXfl-0003LH-8S for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 07:23:05 -0400 Received: by mail-wm1-f45.google.com with SMTP id l26so2758938wme.3 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 04:23:05 -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=W3TMvTnBp0vPiqvcpfuun0JUeRi3RYi9OL1IR0CHXb8=; b=K0O0XnoJlcrVlqoRij2a8WTqMntphDVW3Boz/RknHOfBMTeLEBAFNPTsHTbHnV6sNo FflhtUdhOQb5U1ePfrY/NogWS1yn0iJqnJRA0enXg61GjK50cqAioZfL2z3vnN5iH6SP ehr+IV7FgWhKMxOOz9axg//33P5pOn9smViBI0EPfSI3zsZEBUpN18rF15HkGQcn1mMQ j/2ENk1qbkqOthjuKDJKf3cxLyYSy8EZnIsxXodIrkSRlCKta8FrPX8X8fht8UTUg5UZ bq+lQ7gfqaxpVHTQcLnpWJnv78tQ57hvkw3dAGSCcupnNgtZOsYJFi3cAPxp0WUJermC f3aQ== 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=W3TMvTnBp0vPiqvcpfuun0JUeRi3RYi9OL1IR0CHXb8=; b=gX19a5onF/eokUWP1wCxxnl1TFlv+aOT1g2mLWBxnhv4c5waKy6tpOqJXTXzkAYAu9 Y7uLc2ziwOJWUGE0lllmgDGUEtNyT2/zmvHHer22fDH6lq86uubxS8Q2wPTRhGHgGdqM wEExJKuk8p75qVxcZ8gsExalRQ3hmKVmT8X5JXF7mpxOAaFnhEBo5ctk2lhTt6o2CGyT z5C6vx7Btgwgs0ozSse5Acf8kLNnnpI4FP1KhazoP/TTKjvX9BjmJGS6OdwlqjVwBE9I qZNq0b8nNl2yHFPMjpm/HQZ4Ts0RJkvxhLyfdjzmUnWzmZGeHQOgSgASWjv3sjHgQX29 yTMw== X-Gm-Message-State: AOAM532VOoezfOIREq/DX7dN28QvvBT64swietcJWTltuNKJW77RuIWS zZGHkUvCXZoDzNBs/ueKlXU= X-Google-Smtp-Source: ABdhPJxTy1pS6oOUB7AJ0LADaW0AA9nzEtdGo5o95ELPvvMNWMdz1vuYO3DjtTw18dFx7anYJo62zQ== X-Received: by 2002:a1c:117:: with SMTP id 23mr1027711wmb.90.1590492179406; Tue, 26 May 2020 04:22:59 -0700 (PDT) Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id r4sm844621wro.32.2020.05.26.04.22.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 04:22:58 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends References: <875zckuet9.fsf@HIDDEN> <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <jwv367nqv52.fsf-monnier+emacs@HIDDEN> Date: Tue, 26 May 2020 12:22:57 +0100 In-Reply-To: <jwv367nqv52.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Mon, 25 May 2020 22:38:35 -0400") Message-ID: <87blmbrlda.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41531 Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: >> Here's a modified approach that doesn't use a global var and should make= it >> easier to transition to using futures. > I think at this stage, we should either start using futures or we should > forget about ever using them. <DRAMATIC MUSIC PLAYS> But really: now we have deadlock too? I just want to solve this problem: please let's commit something, and move on to the next bug. It can be functions that return functions that receive functions with the airplane. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 02:38:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 25 22:38:45 2020
Received: from localhost ([127.0.0.1]:43139 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdPUK-0002ro-Ox
for submit <at> debbugs.gnu.org; Mon, 25 May 2020 22:38:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19369)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1jdPUJ-0002ra-Jj
for 41531 <at> debbugs.gnu.org; Mon, 25 May 2020 22:38:43 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C34D8440900;
Mon, 25 May 2020 22:38:37 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 93FB0440489;
Mon, 25 May 2020 22:38:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1590460716;
bh=BX5kSxsHSUDGHi8VaPxEXa6QVuTt7cLS7ESsnxnYATo=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=oFkQxzIusNZmJpKE7H9ODqM/sNwzGDCifg53gTgd/rA8tmQQW64Ay5zktDey+BBJy
MnuX7npY9+3ImI1HmFVLbDk+VztVps5IQDMDHIf+KJrguQTSXKAFe3XGTGpwWvrd5H
jbtAB/vb/z3wE4wLgNuRtP0BiIAijucbhVVUTVD+yKQnPJ2elxzhRtU8aIySS8Y3sq
9j4ipj/RByCXCKzsbzO+WGqcniRKgmRN2k8TH+95E97oW3itUSTnK+iYWtHJSybj3d
DeNoij2sc4oXaeq/1QhNR0vylMnXu4z0v3Uxef0CX1ub/770iO6aVAhs4kANdJmhpX
2J97uBYOxP7Xg==
Received: from milanesa (unknown [216.154.27.250])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4FA73120281;
Mon, 25 May 2020 22:38:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Message-ID: <jwv367nqv52.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
Date: Mon, 25 May 2020 22:38:35 -0400
In-Reply-To: <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> (Dmitry Gutov's
message of "Tue, 26 May 2020 02:52:58 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.098 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Here's a modified approach that doesn't use a global var and should make it
> easier to transition to using futures.
I think at this stage, we should either start using futures or we should
forget about ever using them.
Stefan
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 01:21:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 25 21:21:26 2020
Received: from localhost ([127.0.0.1]:42839 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdOHV-0000pk-LJ
for submit <at> debbugs.gnu.org; Mon, 25 May 2020 21:21:26 -0400
Received: from mail-wr1-f48.google.com ([209.85.221.48]:35411)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jdOHU-0000pX-1I
for 41531 <at> debbugs.gnu.org; Mon, 25 May 2020 21:21:24 -0400
Received: by mail-wr1-f48.google.com with SMTP id x14so13399513wrp.2
for <41531 <at> 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)
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)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
References: <875zckuet9.fsf@HIDDEN>
<4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
Date: Tue, 26 May 2020 02:21:14 +0100
In-Reply-To: <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> (Dmitry Gutov's
message of "Tue, 26 May 2020 02:52:58 +0300")
Message-ID: <87k10zsd85.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 41531
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at 41531) by debbugs.gnu.org; 25 May 2020 23:53:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 25 19:53:21 2020
Received: from localhost ([127.0.0.1]:42814 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdMu5-0007DV-Ly
for submit <at> debbugs.gnu.org; Mon, 25 May 2020 19:53:21 -0400
Received: from mail-wm1-f44.google.com ([209.85.128.44]:55515)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1jdMu3-0007D8-R8
for 41531 <at> debbugs.gnu.org; Mon, 25 May 2020 19:53:08 -0400
Received: by mail-wm1-f44.google.com with SMTP id c71so1474084wmd.5
for <41531 <at> debbugs.gnu.org>; Mon, 25 May 2020 16:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-language;
bh=uY7i8LZ608OAGt0/V8UNJ/NV0/inMYqlVYcTGmho2Uw=;
b=nPRtAAGEHbMPgY039745srawVQ6BEeqfYmmQ8InOljYMn3ILtryqTRUojsslspg8I9
noxRJXBY86lv+/rX/yA2FZ0Sfu4hFQ9XjoMfz1fH+WBPWm1XwZOEwL7bXF0vTXWe3tYX
H3/UPA7LvWa1Aj0iM6dQqYbU1G7tcxvxzlGIXfa0Pcflz2E5XVlKRsKzKCdeeLJXq1X9
vciggJW3pwOl1KcLMcqCTi+jypJp8WHSeqimxvjnlVcHRbUzmkBOKN+YyKqmYMg65sc1
TKs5loP84CN6toKtvkTWcSuSEdv47U1YDICM0VRyz2iJQha+YNrQhvt2Ca+GZQd3Xzgs
ARvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
:date:user-agent:mime-version:in-reply-to:content-language;
bh=uY7i8LZ608OAGt0/V8UNJ/NV0/inMYqlVYcTGmho2Uw=;
b=IBKCYB8wNp5QbakOfJbMISujaNrIff2PHH+WZEff5+RdV16Pb8sT3XuARcQIdRYG2x
Eio9xPuiLgVGSLJtkpeMElVs4qvn9iaypA2+W5lRbJLBNlYpsYEVZY+01Yym0fO5fJRc
LM5UdbnoG8OKyWxOd+SueJGGk/I7S74daEQYhfF/EYd7FYPcPVpVXFQeJQ2yZSecVp3g
p1Rb0TYDeveelKbzjEjNQ7sQtCuYASx85iNbUhr4Xfi2kuZ+SeGuPr5tttpUsLdPm5Rh
n1aQk2M59bZEkN+IikJW53cMuyXxxI8kwg8D5qesns+Ki/txceWHLlmeK+xQqQPh/FGW
+Iqg==
X-Gm-Message-State: AOAM5324rQheL3JaWogNg/CdgEsETd2R8hwQ5+I4muWlPFnO/0hrWFTT
3HTDCFF/vZvOu0rcynIdyH4=
X-Google-Smtp-Source: ABdhPJzqrFln9wf4mjYg2IkC7bjMj9m2sIe8l8vLvwJGc1ZqcAkYo0sA6o6bX6tkbMdhiZEuIDSDiA==
X-Received: by 2002:a1c:7c0b:: with SMTP id x11mr28293442wmc.149.1590450780988;
Mon, 25 May 2020 16:53:00 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
by smtp.googlemail.com with ESMTPSA id n19sm4633907wmi.33.2020.05.25.16.52.59
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 25 May 2020 16:53:00 -0700 (PDT)
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
41531 <at> debbugs.gnu.org
References: <875zckuet9.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
Date: Tue, 26 May 2020 02:52:58 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <875zckuet9.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------F14F2C2007861A590D9DCEA9"
Content-Language: en-US
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 41531
Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)
This is a multi-part message in MIME format.
--------------F14F2C2007861A590D9DCEA9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 25.05.2020 20:04, João Távora wrote:
> Hi Stefan, Dmitry, Andrii and maintainers,
>
> Moving the discussion that started in
> https://github.com/joaotavora/eglot/pull/459 to the bug tracker, and
> attaching the two patches that contain what I think is a decent
> short-term solution to the eldoc/async problems.
Here's a modified approach that doesn't use a global var and should make
it easier to transition to using futures.
Patch attached. Example of usage:
(add-hook 'eldoc-documentation-functions
#'test-eldoc-async 0 t)
(defun test-eldoc-async ()
(cons :async
(lambda (cb)
(funcall cb "doc here!"))))
If you like, we could simplify the returned objects to be just FETCHER
(as documented in the patch) rather than (:async . FETCHER). But the
latter seems more explicit.
There also exist a possible modification of this patch with a bit of
functional programming where both calls to eldoc--handle-multiline
happen from inside of eldoc-documentation-default's definition.
--------------F14F2C2007861A590D9DCEA9
Content-Type: text/x-patch; charset=UTF-8;
name="eldoc-async-with-lexical-callback.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="eldoc-async-with-lexical-callback.diff"
diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..8909e8d431 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
;; Author: Noah Friedman <friedman@HIDDEN>
;; Keywords: extensions
;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
;; Package-Requires: ((emacs "26.3"))
;; This is a GNU ELPA :core package. Avoid functionality that is not
@@ -338,12 +338,26 @@ eldoc-display-message-no-interference-p
(defvar eldoc-documentation-functions nil
- "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point. It should return nil if there's no doc
-appropriate for the context. Typically doc is returned if point
-is on a function-like name or in its arg list.
+ "Hook of functions that produce doc strings.
+Each hook function should accept no arguments and decide whether
+to display a doc short string about the context around point.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
+
+If the decision and the doc string can be produced quickly, the
+hook function should immediately return the doc string, or nil if
+there's no doc appropriate for the context. Otherwise, if its
+computation is expensive or can't be performed directly, the
+function can instead return a cons (:async . FETCHER) where where
+FETCHER is a function of one argument, CALLBACK. When the result
+arrives, FETCHER must call CALLBACK and pass it the doc string to
+be displayed.
+
+A current limitation of the asynchronous case is that it is only
+guaranteed to work correctly if the value of
+`eldoc-documentation-function' (notice the singular) is
+`eldoc-documentation-default'.
Major modes should modify this hook locally, for example:
(add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,14 +365,18 @@ eldoc-documentation-functions
taken into account if the major mode specific function does not
return any documentation.")
+(defun eldoc--handle-multiline (res)
+ "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+ (if eldoc-echo-area-use-multiline-p res
+ (truncate-string-to-width
+ res (1- (window-width (minibuffer-window))))))
+
(defun eldoc-documentation-default ()
"Show first doc string for item at point.
Default value for `eldoc-documentation-function'."
(let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
- (when res
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (cond ((stringp res) (eldoc--handle-multiline res))
+ (t res))))
(defun eldoc-documentation-compose ()
"Show multiple doc string results at once.
@@ -368,13 +386,11 @@ eldoc-documentation-compose
'eldoc-documentation-functions
(lambda (f)
(let ((str (funcall f)))
- (when str (push str res))
+ (when (stringp str) (push str res))
nil)))
(when res
(setq res (mapconcat #'identity (nreverse res) ", "))
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (eldoc--handle-multiline res))))
(defcustom eldoc-documentation-function #'eldoc-documentation-default
"Function to call to return doc string.
@@ -417,11 +433,30 @@ eldoc-print-current-symbol-info
;; Erase the last message if we won't display a new one.
(when eldoc-last-message
(eldoc-message nil))
- (let ((non-essential t))
+ (let ((non-essential t)
+ (buffer (current-buffer)))
;; Only keep looking for the info as long as the user hasn't
;; requested our attention. This also locally disables inhibit-quit.
(while-no-input
- (eldoc-message (funcall eldoc-documentation-function)))))))
+ (let*
+ ((waiting-for-callback t)
+ (callback
+ (lambda (string)
+ (with-current-buffer buffer
+ ;; JT@2020-05-25: Currently, we expect one single
+ ;; docstring from the client, we silently swallow
+ ;; anything the client unexpectedly gives us,
+ ;; including updates. This could change.
+ (when waiting-for-callback
+ (setq waiting-for-callback nil)
+ (eldoc-message (eldoc--handle-multiline string))))))
+ (res
+ (funcall eldoc-documentation-function)))
+ (cond ((stringp res) (eldoc-message res))
+ ((and (consp res)
+ (eq (car res) :async))
+ (funcall (cdr res) callback))
+ (t (eldoc-message nil)))))))))
;; If the entire line cannot fit in the echo area, the symbol name may be
;; truncated or eliminated entirely from the output to make room for the
--------------F14F2C2007861A590D9DCEA9--
bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 25 May 2020 17:04:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 25 13:04:20 2020
Received: from localhost ([127.0.0.1]:42372 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1jdGWR-0003Sq-Dc
for submit <at> debbugs.gnu.org; Mon, 25 May 2020 13:04:20 -0400
Received: from lists.gnu.org ([209.51.188.17]:52426)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1jdGWP-0003Si-Hn
for submit <at> debbugs.gnu.org; Mon, 25 May 2020 13:04:18 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:37890)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <joaotavora@HIDDEN>)
id 1jdGWI-0005AE-J9
for bug-gnu-emacs@HIDDEN; Mon, 25 May 2020 13:04:17 -0400
Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:39426)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <joaotavora@HIDDEN>)
id 1jdGWG-00054i-6Y
for bug-gnu-emacs@HIDDEN; Mon, 25 May 2020 13:04:10 -0400
Received: by mail-wm1-x32c.google.com with SMTP id y5so593484wmj.4
for <bug-gnu-emacs@HIDDEN>; Mon, 25 May 2020 10:04:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:date:message-id:mime-version;
bh=f0d/Jf19r2JndToBxQ/yBvzr0gXmEWzs0LKNcm6ssos=;
b=rfMGkpdKseHquoZBd4MErL9Yu47yn0ehTT/xewGKQDNXnZ+AdCFu+6ZxVOZiehBNjy
/PcQ5zL0gwaZsVBcAYuMgAPujTy0XW2WQlJcQvi5B4GQYbOiUi7uGSMZsFI9BNMQqwsp
+2aaWwnhJtT+zDRKkDnK/VZEaZb+QZBj8F2cbRryClv7EK+UFkD+6Rw4lvFF3K+yEn2t
UKbYGeY5m7YeFprmjL3CuTgj5S1pZ3GEP6zxd723AM/t8SJXn5nmvMQZSD6fjnW13ztA
6rsu4I0AdPadjd9V/nxQTh3wwSlOXTMVazn5k5W8ZyV0+K6PVHJC9m7WVzYf6z3fp4HR
Q0CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:date:message-id:mime-version;
bh=f0d/Jf19r2JndToBxQ/yBvzr0gXmEWzs0LKNcm6ssos=;
b=ZHHLasaKklcRsdT4x8PoaX3LDM1JjpxVGyC1sqSc6k3dSznlbL+896Mt51Ddqgppta
VUx02W65ZMQbyOohgxz+tx2jS1xrMbbiuKHZrEfsnWFhkdGAXy1H7u1mgycpP6eJUjRT
F7qxlPzbwOLLCjxxTqV+eBwCC/JBhuWD4m1bNabh97DRFMoKThYN79pMsaII7sTGQ49N
2LNemFDEFLE4SHnCBR31rzXyVOdAC+QCncJZqgou5XHn0Y1HaRrsn953/0Xv74ZRBIER
VLzLBAMN/CvVpq+zH8GER4hxAgnDYxSRxv0vZREdfzo8imSeQlmvx6k2NVE4o/2os2c6
FmQA==
X-Gm-Message-State: AOAM531uTTlo5qJNgpHfvCxjBnQyLpfXW4xuin2j4ci2zkSvljlBJ9RA
UOFJnpik0yjq48ImiN2tNsh9c4P04pE=
X-Google-Smtp-Source: ABdhPJwzmg4B362VxvdPJschxlR+0nugCgLU5PJM8zZnkdFqCrZ+waajI2mdBWD4h7TpKwsZLP3ZNQ==
X-Received: by 2002:a7b:c253:: with SMTP id b19mr27188660wmj.110.1590426245575;
Mon, 25 May 2020 10:04:05 -0700 (PDT)
Received: from krug ([89.180.145.189])
by smtp.gmail.com with ESMTPSA id y25sm1175544wmi.2.2020.05.25.10.04.03
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 25 May 2020 10:04:04 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 27.0.91; Better handle asynchronous eldoc backends
X-Debbugs-CC: Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov
<dgutov@HIDDEN>, andreyk.mad@HIDDEN
Date: Mon, 25 May 2020 18:04:02 +0100
Message-ID: <875zckuet9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::32c;
envelope-from=joaotavora@HIDDEN; helo=mail-wm1-x32c.google.com
X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache.
That's all we know.
X-Spam_score_int: -10
X-Spam_score: -1.1
X-Spam_bar: -
X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001,
URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Stefan, Dmitry, Andrii and maintainers,
Moving the discussion that started in
https://github.com/joaotavora/eglot/pull/459 to the bug tracker, and
attaching the two patches that contain what I think is a decent
short-term solution to the eldoc/async problems.
It makes eldoc-diagnostic-functions have a very similar interface to
flymake-diagnostic-functions. Flymake's handling of the multiple
backends and async is more sophisticated, and we could extend eldoc to
try similarly heroic stuff, if we do find there's a demand for it.
The main thing you probably want to read if
`eldoc-documentation-functions`'s new docstring.
This was tested summarily with Eglot, by the way, and seems to work OK.
Enjoy!
Jo=C3=A3o
PS: How do I mark that the bug report contains a patch in the mail
message itself?
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=0001-Better-handle-asynchronously-produced-eldoc-docstrin.patch
From 9ca84e5482b2e7ef40f80679ec508afb008293ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 16:39:40 +0100
Subject: [PATCH 1/2] Better handle asynchronously produced eldoc docstrings
No longer do clients of eldoc need to call eldoc-message (an internal
function) directly. They may return any non-nil, non-string value and
call a callback afterwards. This enables eldoc.el to exert control
over how (and crucially also when) to display the docstrings to the
user.
* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions):
Overhaul docstring.
(eldoc-documentation-compose, eldoc-documentation-default): Handle
non-nil, non-string values of elements of
eldoc-documentation-functions. Use eldoc--handle-multiline.
(eldoc-print-current-symbol-info): Honour non-nil, non-string
values returned by eldoc-documentation-callback.
(eldoc--handle-multiline): New helper.
(Version): Bump to 1.1.0.
---
lisp/emacs-lisp/eldoc.el | 73 ++++++++++++++++++++++++++++++----------
1 file changed, 56 insertions(+), 17 deletions(-)
diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..f5dcdb4ea0 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
;; Author: Noah Friedman <friedman@HIDDEN>
;; Keywords: extensions
;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
;; Package-Requires: ((emacs "26.3"))
;; This is a GNU ELPA :core package. Avoid functionality that is not
@@ -338,12 +338,26 @@ eldoc-display-message-no-interference-p
(defvar eldoc-documentation-functions nil
- "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point. It should return nil if there's no doc
-appropriate for the context. Typically doc is returned if point
-is on a function-like name or in its arg list.
+ "Hook of functions that produce doc strings.
+Each hook function should accept no arguments and decide whether
+to display a doc short string about the context around point. If
+the decision and the doc string can be produced quickly, the hook
+function should immediately return the doc string, or nil if
+there's no doc appropriate for the context. Otherwise, if its
+computation is expensive or can't be performed directly, the hook
+function should save the value bound to
+`eldoc-documentation-callback', and arrange for that callback
+function to be asynchronously called at a later time, passing it
+either nil or the desired doc string. The hook function should
+then return a non-nil, non-string value.
+
+A current limitation of the asynchronous case is that it is only
+guaranteed to work correctly if the value of
+`eldoc-documentation-function' (notice the singular) is
+`eldoc-documentation-default'.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
Major modes should modify this hook locally, for example:
(add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,14 +365,18 @@ eldoc-documentation-functions
taken into account if the major mode specific function does not
return any documentation.")
+(defun eldoc--handle-multiline (res)
+ "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+ (if eldoc-echo-area-use-multiline-p res
+ (truncate-string-to-width
+ res (1- (window-width (minibuffer-window))))))
+
(defun eldoc-documentation-default ()
"Show first doc string for item at point.
Default value for `eldoc-documentation-function'."
(let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
- (when res
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (cond ((stringp res) (eldoc--handle-multiline res))
+ (t res))))
(defun eldoc-documentation-compose ()
"Show multiple doc string results at once.
@@ -368,13 +386,11 @@ eldoc-documentation-compose
'eldoc-documentation-functions
(lambda (f)
(let ((str (funcall f)))
- (when str (push str res))
+ (when (stringp str) (push str res))
nil)))
(when res
(setq res (mapconcat #'identity (nreverse res) ", "))
- (if eldoc-echo-area-use-multiline-p res
- (truncate-string-to-width
- res (1- (window-width (minibuffer-window))))))))
+ (eldoc--handle-multiline res))))
(defcustom eldoc-documentation-function #'eldoc-documentation-default
"Function to call to return doc string.
@@ -408,6 +424,12 @@ eldoc--supported-p
;; there's some eldoc support in the current buffer.
(local-variable-p 'eldoc-documentation-function))))
+;; this variable should be unbound, but that confuses
+;; `describe-symbol' for some reason.
+(defvar eldoc-documentation-callback nil
+ "Dynamically bound. Accessible to `eldoc-documentation-functions'.
+See that function for details.")
+
(defun eldoc-print-current-symbol-info ()
"Print the text produced by `eldoc-documentation-function'."
;; This is run from post-command-hook or some idle timer thing,
@@ -417,11 +439,28 @@ eldoc-print-current-symbol-info
;; Erase the last message if we won't display a new one.
(when eldoc-last-message
(eldoc-message nil))
- (let ((non-essential t))
+ (let ((non-essential t)
+ (buffer (current-buffer)))
;; Only keep looking for the info as long as the user hasn't
;; requested our attention. This also locally disables inhibit-quit.
(while-no-input
- (eldoc-message (funcall eldoc-documentation-function)))))))
+ (let*
+ ((waiting-for-callback nil)
+ (eldoc-documentation-callback
+ (lambda (string)
+ (with-current-buffer buffer
+ ;; JT@2020-05-25: Currently, we expect one single
+ ;; docstring from the client, we silently swallow
+ ;; anything the client unexpectedly gives us,
+ ;; including updates. This could change.
+ (when waiting-for-callback
+ (eldoc-message (eldoc--handle-multiline string))
+ (setq waiting-for-callback nil)))))
+ (res
+ (funcall eldoc-documentation-function)))
+ (cond ((stringp res) (eldoc-message res))
+ (res (setq waiting-for-callback t))
+ (t (eldoc-message nil)))))))))
;; If the entire line cannot fit in the echo area, the symbol name may be
;; truncated or eliminated entirely from the output to make room for the
--
2.20.1
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=0002-Adjust-eldoc-documentation-functions-protocol-for-be.patch
From a6ba9972ee0e3305c7b41fd380a88dd18a6626a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 17:38:23 +0100
Subject: [PATCH 2/2] Adjust eldoc-documentation-functions protocol for better
async
Instead of exposing a eldoc-documentation-callback variable to
clients, just pass it the callback as the first argument.
* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions): Rewrite docstring.
(eldoc-documentation-default, eldoc-documentation-compose): Use
internal eldoc--callback.
(eldoc-documentation-callback).
(eldoc---callback): Rename from eldoc-documentation-callback.
(eldoc-print-current-symbol-info): Bind eldoc--callback.
* lisp/hexl.el (hexl-print-current-point-info): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/cfengine.el (cfengine3-documentation-function):
Adjust to new eldoc-documentation-functions protocol.
* lisp/progmodes/elisp-mode.el
(elisp-eldoc-documentation-function): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/octave.el (octave-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
* lisp/progmodes/python.el (python-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
---
lisp/emacs-lisp/eldoc.el | 45 ++++++++++++++++++------------------
lisp/hexl.el | 2 +-
lisp/progmodes/cfengine.el | 2 +-
lisp/progmodes/elisp-mode.el | 6 +++--
lisp/progmodes/octave.el | 4 ++--
lisp/progmodes/python.el | 2 +-
6 files changed, 32 insertions(+), 29 deletions(-)
diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index f5dcdb4ea0..a4e1e460ac 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -339,22 +339,22 @@ eldoc-display-message-no-interference-p
(defvar eldoc-documentation-functions nil
"Hook of functions that produce doc strings.
-Each hook function should accept no arguments and decide whether
-to display a doc short string about the context around point. If
-the decision and the doc string can be produced quickly, the hook
-function should immediately return the doc string, or nil if
-there's no doc appropriate for the context. Otherwise, if its
-computation is expensive or can't be performed directly, the hook
-function should save the value bound to
-`eldoc-documentation-callback', and arrange for that callback
-function to be asynchronously called at a later time, passing it
-either nil or the desired doc string. The hook function should
-then return a non-nil, non-string value.
-
-A current limitation of the asynchronous case is that it is only
-guaranteed to work correctly if the value of
-`eldoc-documentation-function' (notice the singular) is
-`eldoc-documentation-default'.
+Each hook function should accept at least one argument CALLBACK
+and decide whether to display a doc short string about the
+context around point. If the decision and the doc string can be
+produced quickly, the hook function can ignore CALLBACK and
+immediately return the doc string, or nil if there's no doc
+appropriate for the context. Otherwise, if its computation is
+expensive or can't be performed directly, the hook function
+should arrange for CALLBACK to be asynchronously called at a
+later time, passing it either nil or the desired doc string. The
+hook function should then return a non-nil, non-string value.
+
+Note that this hook is only in effect if the value of
+`eldoc-documentation-function' (notice the singular) is bound to
+one of its pre-set values. Furthermore, the asynchronous
+mechanism described above is only guaranteed to work correctly if
+that value is `eldoc-documentation-default'.
Typically doc is returned if point is on a function-like name or
in its arg list.
@@ -374,7 +374,9 @@ eldoc--handle-multiline
(defun eldoc-documentation-default ()
"Show first doc string for item at point.
Default value for `eldoc-documentation-function'."
- (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
+ (let ((res (run-hook-with-args-until-success
+ 'eldoc-documentation-functions
+ eldoc--callback)))
(cond ((stringp res) (eldoc--handle-multiline res))
(t res))))
@@ -385,7 +387,7 @@ eldoc-documentation-compose
(run-hook-wrapped
'eldoc-documentation-functions
(lambda (f)
- (let ((str (funcall f)))
+ (let ((str (funcall f eldoc--callback)))
(when (stringp str) (push str res))
nil)))
(when res
@@ -426,9 +428,8 @@ eldoc--supported-p
;; this variable should be unbound, but that confuses
;; `describe-symbol' for some reason.
-(defvar eldoc-documentation-callback nil
- "Dynamically bound. Accessible to `eldoc-documentation-functions'.
-See that function for details.")
+(defvar eldoc---callback nil
+ "Dynamically bound. Passed to `eldoc-documentation-functions'.")
(defun eldoc-print-current-symbol-info ()
"Print the text produced by `eldoc-documentation-function'."
@@ -446,7 +447,7 @@ eldoc-print-current-symbol-info
(while-no-input
(let*
((waiting-for-callback nil)
- (eldoc-documentation-callback
+ (eldoc--callback
(lambda (string)
(with-current-buffer buffer
;; JT@2020-05-25: Currently, we expect one single
diff --git a/lisp/hexl.el b/lisp/hexl.el
index cf7118f208..38eca77e26 100644
--- a/lisp/hexl.el
+++ b/lisp/hexl.el
@@ -515,7 +515,7 @@ hexl-current-address
(message "Current address is %d/0x%08x" hexl-address hexl-address))
hexl-address))
-(defun hexl-print-current-point-info ()
+(defun hexl-print-current-point-info (&rest _ignored)
"Return current hexl-address in string.
This function is intended to be used as eldoc callback."
(let ((addr (hexl-current-address)))
diff --git a/lisp/progmodes/cfengine.el b/lisp/progmodes/cfengine.el
index f25b3cb9e2..9a6d81ce06 100644
--- a/lisp/progmodes/cfengine.el
+++ b/lisp/progmodes/cfengine.el
@@ -1294,7 +1294,7 @@ cfengine3-make-syntax-cache
'symbols))
syntax)))
-(defun cfengine3-documentation-function ()
+(defun cfengine3-documentation-function (&rest _ignored)
"Document CFengine 3 functions around point.
Intended as the value of `eldoc-documentation-function', which see.
Use it by enabling `eldoc-mode'."
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index d37eb8c152..d7865a7319 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1402,8 +1402,10 @@ elisp--eldoc-last-data
or argument string for functions.
2 - `function' if function args, `variable' if variable documentation.")
-(defun elisp-eldoc-documentation-function ()
- "`eldoc-documentation-function' (which see) for Emacs Lisp."
+(defun elisp-eldoc-documentation-function (_ignored &rest _also-ignored)
+ "Contextual documentation function for Emacs Lisp.
+Intended to be placed in `eldoc-documentation-functions' (which
+see)."
(let ((current-symbol (elisp--current-symbol))
(current-fnsym (elisp--fnsym-in-current-sexp)))
(cond ((null current-fnsym)
diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index 352c1810d1..2cf305c404 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -1639,8 +1639,8 @@ octave-eldoc-function-signatures
(nreverse result)))))
(cdr octave-eldoc-cache))
-(defun octave-eldoc-function ()
- "A function for `eldoc-documentation-function' (which see)."
+(defun octave-eldoc-function (&rest _ignored)
+ "A function for `eldoc-documentation-functions' (which see)."
(when (inferior-octave-process-live-p)
(let* ((ppss (syntax-ppss))
(paren-pos (cadr ppss))
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 1ca9f01963..404a67ba9f 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -4571,7 +4571,7 @@ python-eldoc-function-timeout-permanent
:type 'boolean
:version "25.1")
-(defun python-eldoc-function ()
+(defun python-eldoc-function (&rest _ignored)
"`eldoc-documentation-function' for Python.
For this to work as best as possible you should call
`python-shell-send-buffer' from time to time so context in
--
2.20.1
--=-=-=--
João Távora <joaotavora@HIDDEN>:monnier@HIDDEN, dgutov@HIDDEN, andreyk.mad@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.monnier@HIDDEN, dgutov@HIDDEN, andreyk.mad@HIDDEN, bug-gnu-emacs@HIDDEN:bug#41531; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.