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: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico Date: Thu, 8 Apr 2021 00:56:42 +0300 Message-ID: <76a4d0e2-117b-165d-d56e-5bc2f504b50c@yandex.ru> References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <78741fe6-2612-d7c9-2bc4-0b68ea7fa51a@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="2659"; 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 Cc: Philip Kaludercic , emacs-devel@gnu.org, Manuel Uberti , "T.V Raman" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 07 23:57:27 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 1lUGAx-0000ZQ-2w for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 23:57:27 +0200 Original-Received: from localhost ([::1]:52428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUGAw-0006jE-4E for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 17:57:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51380) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUGAM-0006Ho-Et for emacs-devel@gnu.org; Wed, 07 Apr 2021 17:56:50 -0400 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:46862) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lUGAJ-0003WA-Ri for emacs-devel@gnu.org; Wed, 07 Apr 2021 17:56:50 -0400 Original-Received: by mail-wr1-x436.google.com with SMTP id a12so9740741wrq.13 for ; Wed, 07 Apr 2021 14:56:46 -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=V4Y5uS60cR4jUF1p9n4nO1Y8y7E7cZNIzJtGw3tY2bI=; b=Jc7U5jfiZ38QPVxw/7vU1SaVm12oot61iGzZMKgtZAQTJIukwQx1j9rq0kb7Lsmva/ c9OYySM8mNCRIUOjR45EIgCDbjNRNs/UEu9wWKYNHJ3p5ZCwJZl8eSU/riFBz/vCWpKc sdWOL9yjlUZksbSo4q5gfQTRP5QQ6Z4YPaXPUcC5GWn8sxhTH+SQdl/ffYkrz/FnbGQr om+Kq6slSM7V4KlVobDenmiQRhW8nPz3Qbp+G6SmKQTwyI8cs92a+zJk9h/nG9BFXqMq NIEzdtymVQlGhc9xfbHCksMbmjEqwMI9okwp+Tz+nrRx/jn9KCxTgygwjAbmHN3b7tgu bP9w== 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=V4Y5uS60cR4jUF1p9n4nO1Y8y7E7cZNIzJtGw3tY2bI=; b=TVwQp/ysauzGz6uuqnskRQLnr3AEV2NjXLQ6w2RCV8/a+I5s39u56PV7RuAaB+CFNv jgoW5bWYSYq3Fuv3wvovqFbSdmac+qqngBc2GzQT+oRZrPWctxnM4Ly659pyKviZcbAw bvZN/6zH8njoqHAqrfoDKp7HXw+/i074Wwb29sA3oDb2HGZPzAON4hYzcfl5wsUbnefo P9w7NhML78kMNgB5KBgTbMB4PXXAaFLvAy6U+b1jKa7G9cqwJTUhKDI7bkf9lc/EZMbi 4hZgY+o5pKfKUja2e/399vx46untqZF748SmMLTuo0rXjg3UHtOPnc8sFmYWMUYwaTRX V2wQ== X-Gm-Message-State: AOAM53348p7PXknV69g73vDzLpO4SdRN6+94sAX7pWzoWdtMl7vd//pC NJn0w8JPhqwgMooZauCoRjjH4jZc/lQ= X-Google-Smtp-Source: ABdhPJz26cD47iDZiQuZ9aEckMFoNwbKAVhG57YCP/7qLyYrd+h9yxydNamYNKaG/F2qx/K+LoRXKw== X-Received: by 2002:a5d:6242:: with SMTP id m2mr6695933wrv.384.1617832605446; Wed, 07 Apr 2021 14:56:45 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y12sm18123931wrs.65.2021.04.07.14.56.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Apr 2021 14:56:44 -0700 (PDT) In-Reply-To: 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.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:267578 Archived-At: On 07.04.2021 17:44, Stefan Monnier wrote: >>> Most completion frameworks I have looked at seem to limit themselves to >>> the latter. To simplify, they collect all the options of a collection >>> using all-completions and then narrow it depending on user input. Ido >>> and all it's descendents (Ivy, Helm, Selectrum and now vertico) seem to >>> be based on that approach. >> I don't think that's true. > > I don't think the frequency of refreshing the list of candidates is what > he was referring to, but rather the support for "TAB completion" which > corresponds to the `(completion-)try-completion` operation which is > expected to extract the commonality between the various candidates. > > Most completion frameworks minimize the importance of this operation (or > don't support it at all) and instead focus on displaying the set of > candidates, filtering them, and finally picking one of them. I don't know if they really do minimize it: the TAB binding in company-active-map, pressing TAB once in Ivy, and likely equivalent bindings in other systems, all complete the "common" part to let the user continue typing to resolve ambiguities. That's something a pure "selection UI" wouldn't have. And I do think it's > Seen from the point of view of the implementation, I can understand why > it's done this way: the more sophisticated your completion style is, the > harder it gets to implement `try-completion` (and often the less useful > it gets as well. E.g. for things like `flex` it's very common for there > to be no commonality at all to extract). > > So removing the `try-completion` operation makes for a simpler API > and a simpler implementation (it also simplifies significantly the > quote/unquote handling) and users who like things like `flex` won't even > notice the difference. A try-completion operation might indeed be complex to implement for some completion styles, but it's not like we really tried it. Perhaps it would be difficult to design the "externally filtering" completion style, together with this new operation, but I feel like we've never even reached the point if trying to do that, having met other difficulties along the way. Perhaps we could dispense with this feature when designing a new completion table interface, just for simplicity's sake (though I don't see why we couldn't add it as an option in a later revision). What I was disagreeing in the previous message, is whether it's worth to create a semantic distinction between completing-read and selecting-read. How would a Lisp author choose between the two? The former should actually be more powerful (it will retain support for TAB completion, and yet it could still be supported by selection-style frameworks such as Company or Ivy); the latter, on the other hand, would effectively mandate a minimum "niceness" of the UI (though not necessarily nicer than the former, depending on user customization), but would be unable to support more advanced completion tables. Such as ones with "fields" (which includes file name completion). So it seems the guiding principle might be: use selecting-read for "simple" completion tables. But I don't see why this direction is desirable.