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 21:59:31 +0300 Message-ID: References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <78741fe6-2612-d7c9-2bc4-0b68ea7fa51a@yandex.ru> <76a4d0e2-117b-165d-d56e-5bc2f504b50c@yandex.ru> <87blapln0r.fsf@posteo.net> <37bd2e96-ce04-eb6d-24da-fdd7ea427e61@yandex.ru> <87im4wx2ct.fsf@posteo.net> 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="30566"; 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: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 08 21:00:18 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 1lUZt3-0007ob-7A for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 21:00:17 +0200 Original-Received: from localhost ([::1]:44700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUZt2-00030g-7g for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 15:00:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58356) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUZsP-0002Z0-3X for emacs-devel@gnu.org; Thu, 08 Apr 2021 14:59:37 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:41550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lUZsN-00084S-Au for emacs-devel@gnu.org; Thu, 08 Apr 2021 14:59:36 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id t5-20020a1c77050000b029010e62cea9deso1775699wmi.0 for ; Thu, 08 Apr 2021 11:59:34 -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=n6ifwH9IGoDBERdJFiNDBbDfm9El/hxDRlikXN4vHW8=; b=KizNz3BZlqUFKaYfVxUokU6bXe96lk4rqgnwZZ5rdI2VcXmXeD2orBaxhmms68VV0v G0WPbG409B35riV5aX4dqJ9eHbNYsvTDZNW5/JBoMxUGM114yC9lPlKBrfDUyhHnUQjg eMUxw2sIOfuHXexdqw6QhNBDOFErbJTD48JNr6MhemsXTqvteXX09TpN7eoubnUFAP5J j1G9p6OXaHFJC2K0rOs7Ykgmt0GRKphhDKg++MOnsJHGz0D36EWy8nYTmrpy8sq1JyFw xMTtpw//kAOAM8Aibm8/0zbhqcVT5NRG3YnglFUgg8D5sImaRlditdWngvEQTCJOoc6G 6fjA== 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=n6ifwH9IGoDBERdJFiNDBbDfm9El/hxDRlikXN4vHW8=; b=WaDL5o+Nor5OEbGjfk6c+jFLungGc8DCMmd+clE6kyWAsbTuiPn29Ppj2KxGxEfOmm wqjvvXkaNqMKgCE61in9tMvQuWJR2WUP2L7pkVkZaDjtvdrnb2/7qS4sPxNKBOcfFnH6 FQ0Wh0ghB7SG2u5rd3+nGpnexkhDUUrjEhyd4Y+hhqQtZ30+ZsAaAgd/zI9+4kZojwBW G0yiTYL6UwGSCHBU+vHP6t6sKGvRGjLnd93AZDWBA41iph28WXs6lG2DClu1uL0tYAMK jBe6aFmH5RBT9Um3s7xnAsHJSWf0OkLUgw4Y4KWXR8yetz/y7rPp3mBXXIGWfa2urpkh 9MFw== X-Gm-Message-State: AOAM5322ObBzE9LNdLZvAwP1BlBGgI6wQS/VaTeiRfEbfqiLxtIGbPJn gVCNBTBTbwolysWDVKXl9cEpgc40Rqc= X-Google-Smtp-Source: ABdhPJx0P0E20aiPOYywH9/6ZiAfi1YrEeaN4TZggTd6h4DTmPvAXoxhq1p9BSqlNhU1+5+2vU8p4w== X-Received: by 2002:a1c:e2d7:: with SMTP id z206mr10554302wmg.85.1617908373976; Thu, 08 Apr 2021 11:59:33 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id 24sm157172wmg.19.2021.04.08.11.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Apr 2021 11:59:33 -0700 (PDT) In-Reply-To: <87im4wx2ct.fsf@posteo.net> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32e.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.25, 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:267653 Archived-At: On 08.04.2021 17:44, Philip Kaludercic wrote: > Dmitry Gutov writes: > >> On 08.04.2021 01:59, Philip Kaludercic wrote: >>> Dmitry Gutov writes: >>> >>>> 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); >>> completing-read can be more powerful, as it includes expanding text >>> and >>> selecting items, but I if you are not interested in text-expansion you >>> should probably limit yourself to selection, >> >> Am "I" in this example the user, or the author of the caller code? > > The I was probably a typo. I was asking what you meant by "you", actually. Probably not important at this point. >>> so that everyone is ensured >>> to have the same presentation. >> >> If that's the goal, why don't we make sure to include a "selection" >> interface that supports text-expansion as well, like both Company and >> Ivy do? >> >> What's the purpose of having that distinction? > > My hypothisis is that selection is held back by completing-read, and > that a framework that is explicitly made for selection and not > retrofitted into the existing framework could stand to improve the user > experience. Ah... all right. So the idea could be to annotate the cases where text-expansion is not needed. I'm not sure there is a good way to make that determination, though. OTOH, I can imagine cases which pretty much *need* selection-like interface. xref-show-definitions-completing-read would be one example (it's relatively awkward to make the choice using completion, though certainly not impossible). And I think I have a simple idea of a selection-centric completion UI: ones that use TAB for other things, like iteration between completions (without intermediate steps, like one TAB expands, next ones iterate). VS Code's dropdown completion kind of does that. YouCompleteMe's completion popup does too. So which I personally prefer hybrid approaches, this seems like a good avenue to explore. But I'm not sure we can decide on criteria for when text-expansion is really needed (or not), aside from the user's preference.