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: Wed, 14 Apr 2021 03:00:56 +0300 Message-ID: <9cf1358c-ad0a-4220-974d-86cf1089f20a@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> <000385dc-a234-ade9-584b-c4f515d7b01f@yandex.ru> <8117fc58-4dae-d0b4-43d8-d2e521d1e586@daniel-mendler.de> <9c780787-e205-6344-4cf2-dd67b14db1d9@daniel-mendler.de> 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="11892"; 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 Wed Apr 14 02:01:51 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 1lWSyb-0002yP-Sf for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Apr 2021 02:01:49 +0200 Original-Received: from localhost ([::1]:42286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWSya-0004R0-NA for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Apr 2021 20:01:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWSxq-0003xN-5x for emacs-devel@gnu.org; Tue, 13 Apr 2021 20:01:02 -0400 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:35622) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lWSxo-0007Ro-IY for emacs-devel@gnu.org; Tue, 13 Apr 2021 20:01:01 -0400 Original-Received: by mail-wr1-x436.google.com with SMTP id a4so18103167wrr.2 for ; Tue, 13 Apr 2021 17:01:00 -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=Pc1zDYVh7PWtA4bQXVjW5Z+N3j2e8H5m+SecfAjV8nw=; b=bVY1Z5Uiid3X5B8l4ArGOUfui2OwSTMoh3E9clnRyoTHq6hJ3JOFp26jo14jMsZaND tP67aYsY1ilCdQucEGzncsdFjH67mFf6gu7+dssFNlDodPDhM+YWhc0eD/Nq46JEw0iB 4CKl/x38dLhA3BApqNDgNRs4ufg5SL53xteRwT7sBg/ONSGdMiuSoTEHMv3aEZ3USJhs BBsGTKq+hrc2nN6SJ4ssaA3HkmCWkqOGR7jd36iS1ocai/rUbRdq7oh2edmBRLZlwl9h xODtOv5ktAPT/BU8mqhBgzqfiyoXQyjZc1c/6PilYlF8rztj0Z7uJL/YeOwbXVfiBQSZ CNrA== 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=Pc1zDYVh7PWtA4bQXVjW5Z+N3j2e8H5m+SecfAjV8nw=; b=OlhtKzhWVoHcUri6Aa/tMM3nmvFai5cAs1MQxY5Cc/tZNAgiRC31+LN8KLywkOnPyx nCbV+PvkzpI+eI519AU9EWmrsoSyAAxRYgeMV27Xayq16Y91Jla4+JRdz/6RBfbLUIkK KMdQrNDjkNoZmy34cZxnQ4lj5aqCtPl6CEEaSaHX23B4zkW65iiOZwAgvxq/XUg6P/pE +2ERAOX0GRobzu4L1fH3iwrfoMMXSbySZpr/ClhXx5cmM9Qj84csGy/0/49VgsxvVEM1 PCn65YBTkqzJwFsCvyQAVYaOHHvv3LZF1v5rQqN+1xiYDX0rT/NCPA3NCkfy6aW2lKqD eJEw== X-Gm-Message-State: AOAM533fgnM2jb/nPkNjxSgNBrUs2lCQOwhQQbCj0f22lMwwU9D3bhXB TnHUQdJsW8l2/+UCEx7NiCGGVJrNuCk= X-Google-Smtp-Source: ABdhPJydsx0lU22XP20MnSAlltLuOx3Y8z8+UISKe1UeG8k9XsQ1BGoS+aT2sIt9snzTN+j0PURa3Q== X-Received: by 2002:a5d:424f:: with SMTP id s15mr27530296wrr.356.1618358458938; Tue, 13 Apr 2021 17:00:58 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i4sm6933358wrx.56.2021.04.13.17.00.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Apr 2021 17:00:58 -0700 (PDT) In-Reply-To: <9c780787-e205-6344-4cf2-dd67b14db1d9@daniel-mendler.de> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=raaahh@gmail.com; helo=mail-wr1-x436.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.25, 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:268018 Archived-At: On 12.04.2021 14:04, Daniel Mendler wrote: > On 4/12/21 12:47 PM, Dmitry Gutov wrote: >> What happens if you have an anomalously long running request in one >> nested minibuffer, which you exit, so it arrives in the "parent" one >> that's still managed by Consult, but shows the results for a different >> command/input/etc? > > This cannot happen. If you exit the minibuffer, the running request will > be terminated. Because the process belongs to the buffer? > The parent minibuffer, maybe also running a Consult > command (or something else) is isolated from the child minibuffer and no > disruption should happen. > > I just tested running nested `consult-ripgrep` and that should work, but > for some reason there is a problem > (https://github.com/minad/consult/issues/272). I have to check if this > can be fixed. So what I described to you is how everything should work > in theory, since the state is captured in the closures. > > The `consult--async-sink` contains this code which performs the refreshing: > >      ;; Refresh the UI when the current minibuffer window belongs >      ;; to the current asynchronous completion session. >      (when-let (win (active-minibuffer-window)) >        (when (eq (window-buffer win) buffer) >          (with-selected-window win >            (run-hooks 'consult--completion-refresh-hook))))) OK, so it seems like the sink saves the "context" which it was called from, and then compares it against the current one upon completion, and does nothing when they don't match. Sounds good for minibuffers, but not so great for code completion, where context is more complex. And since completing-read shares the notion of completion table with completion-at-point-functions, I think any async support we add should work for both purposes.