From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: Improvement proposals for `completing-read' Date: Sun, 11 Apr 2021 15:08:19 +0200 Message-ID: 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: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5281"; mail-complaints-to="usenet@ciao.gmane.io" To: Dmitry Gutov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 11 15:09:37 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 1lVZqL-0001Io-Dt for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 15:09:37 +0200 Original-Received: from localhost ([::1]:41384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVZqK-000261-Fo for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 09:09:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57002) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVZpW-0001fV-DE for emacs-devel@gnu.org; Sun, 11 Apr 2021 09:08:46 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:49173 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVZpQ-00015m-0p for emacs-devel@gnu.org; Sun, 11 Apr 2021 09:08:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=L/C/D3uoW+SIlguGr0+H1cYA8xoI2d3v9CxgXCLaFgU=; b=x4n2U59yQYk6e+7KSxmbxomLxy rX0wI/+IZR7Vt1XRaoRZ9chO18SkZniL77YVeBC+8KhWpjYtaC/KTO0Xm2feI/rsBEfggqEJWc8ve DFPFohOgXu2tLaEpHuPHALGvJK1whifTyHhsplE7Y9gatER1szGumrWy+x2D+Zn8It3w=; In-Reply-To: <759ed5ae-8d58-e73b-244b-08bd86aafb2d@yandex.ru> Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:267872 Archived-At: On 4/11/21 2:51 AM, Dmitry Gutov wrote:>>> I would probably say that a UI should itself know better when to >>> refresh or not, but I'm guessing you have good counter-examples. >> >> One could update the UI using some timer if an async source is used >> (polling). However since I am setting this on top of the >> `completing-read' infrastructure I felt it to be better to do it the >> other way round, since the table is only queried when the user enters >> new input. I guess for fast sources polling will be as good, but for >> slow sources, notifying the UI is better. > > Perhaps we're just talking about the same thing, differently. > > What I meant, the source should invoke the callback when it gets new > data, and the callback should store the result somewhere, and it can > notify the UI about the possibility of refreshing (the frontend > implements the callback, so it knows whether and how to do it). But > whether to refresh right away, or wait, debounce, or simply discard the > output, should be the frontend's choice. 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 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. Daniel