From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Improvement proposals for `completing-read' Date: Mon, 12 Apr 2021 03:32:14 +0300 Message-ID: <000385dc-a234-ade9-584b-c4f515d7b01f@yandex.ru> References: <09b67fc5-f8fd-c48a-8b0b-ad47c88761f1@yandex.ru> <292a9f63-5a41-7b32-66f2-67d06f138a09@yandex.ru> <7d03e917-6a61-23b3-e735-a8e43c3fb65f@daniel-mendler.de> <01ffe85f-6bdb-39a5-b20a-e3c60bea3e2e@yandex.ru> <759ed5ae-8d58-e73b-244b-08bd86aafb2d@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33497"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 To: Daniel Mendler , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 12 02:33:12 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lVkVs-0008dz-3p for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 02:33:12 +0200 Original-Received: from localhost ([::1]:54088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVkVr-0000Rx-4v for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 20:33:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVkV5-0008Dd-JV for emacs-devel@gnu.org; Sun, 11 Apr 2021 20:32:24 -0400 Original-Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:37673) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lVkV2-0007pI-PA for emacs-devel@gnu.org; Sun, 11 Apr 2021 20:32:22 -0400 Original-Received: by mail-wm1-x336.google.com with SMTP id g66-20020a1c39450000b0290125d187ba22so5388458wma.2 for ; Sun, 11 Apr 2021 17:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ldQSSLepHIfCy10UWOKHi/sFj/B7mJ124FHXuet73Rg=; b=OCoqgK1Ku0LsYfmen4TU4dsIU23Dy7qcUkDT7P3NOagwVO6ViKN+cd3iHUnT/LI++k I+s3R7G6mbEUewTV2ZRlmho6R6CzCqYEqX3VNg/LJoepzD8VWzvDmKJagSIIGiNosJeH kcw1MRjOy/QxRUxsjuLC7pT7LzahkNQcCYbdZS0uyhdWFgKTVTVDcVlAeqgBjbqY5u4k ATI7sucOQ0azMqtvM22vWAm4J0mIIOSio/ODxSaMvIAw4G8BC7dFUr46/Ej5KVIIUBZz VIJ2R7xa/9h2RSFRZa/pJbuB/Yqz1MVAhhwa51nPP5f9vgfqLtOGUAZQ8p1n331LE25W lQmw== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ldQSSLepHIfCy10UWOKHi/sFj/B7mJ124FHXuet73Rg=; b=I6lRa5MNKm/jycnPN8fV9T9KvzTsP3rKd4ODLaHxtMHcpTrKUJ5L+T1D9wiFNPX/8I 8j5NzBd3O2aXSU9AEgc6msssRV+5KS6Y6oQAdvoJMbjD/liK2BgTMDAUKafw5Bcarnz8 IZGucSXwVYHooWMcIqlcolSiCJod3b4xr2jSKBXyoc2x1QZeYdfB9kKrQ4iUi+3Iz4Zz Fj2Bb+PkToDDUtD7oiIOPGYg1XVKbl/ba+ZO3BCT6aZ1N0ftF0+Vcf7ArUOjzNh4KNCC 9P4L/MjE9w/r0AvZiFUuRimQZYKY4J8HIcHmeeXaSKQA7A0M0n16Gb2Bc7yaIlkEIVG5 +XMw== X-Gm-Message-State: AOAM531PfGJ5i9GsXv+nmo6VhiFkgHy2XYw65C2PbAoqslJtyzX8KaaM o5QgV6vx1RYRE8FPnEbrWXLbK5BtEsU= X-Google-Smtp-Source: ABdhPJwVJARoycQJWsf0zid3tXcpnzD1VzmiQSpvGs1mkhJGn5mOvS3frkGDvsiUpq/bU1rZbMG6zQ== X-Received: by 2002:a7b:c20c:: with SMTP id x12mr9857569wmi.51.1618187537380; Sun, 11 Apr 2021 17:32:17 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l8sm1256206wme.18.2021.04.11.17.32.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Apr 2021 17:32:16 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=raaahh@gmail.com; helo=mail-wm1-x336.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267936 Archived-At: On 11.04.2021 16:08, Daniel Mendler wrote: > Yes, I think we are mostly on the same page. If you look at my Consult > async pipelines there are functions which do debouncing/waiting etc. > > 1. sink      ^ > 2. wait      | candidates, refresh, flush requests etc > 3. debounce  | > 4. source    | > > The incoming candidates are sent from the source (a process or web query > source) to the sink and then the sink also performs the refreshing by > talking directly to the UI. Then the UI can also make its own decisions > what to do with the refreshing requests. Sounds good. >> Sounds like you have what is needed to propose an "async" extension to >> the standard completion tables API? > > Yes, one could consider it as that. But maybe it it is sufficient to > only provide a general refresh hook which I proposed initially. This way > the core API would stay simple and everything could be implemented on > top without constraining everything directly. I'm not sure if that would work for code completion. Aside from tracking which value belongs to which frontend, and the associated bugs with hooks you mentioned, how to you invalidate the results? For instance, there is a request, it has been made a while ago, and the context has changed (the buffer has changed, position has changed, etc). The request has taken a long time but finally the response has arrived. How do you reliably ignore it? Or, ideally, are able abort it (if it's a one-time external process, perhaps killing the search process)? If the result is some kind of "future" value, the handler code can either change some variable in the lexical scope once its execution reaches the point of "we don't need that computation anymore", or could even call some generic method like future-abort. How does the general refresh hook solve these problems?