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: Thu, 8 Apr 2021 22:20:11 +0300 Message-ID: <597310b6-892c-a7d9-a663-f270ed3b0f0e@yandex.ru> References: <0342c2d5-02dd-ad9e-5b8e-dfe52f6469c6@daniel-mendler.de> <264397e8-5a03-9eff-436c-639d76514775@daniel-mendler.de> <82c86e8f-06e7-a7ed-56c5-5f6766df591b@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="4964"; 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 Thu Apr 08 21:21:36 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 1lUaDg-0001Bg-0x for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 21:21:36 +0200 Original-Received: from localhost ([::1]:49090 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUaDf-0000vj-2g for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 15:21:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUaCV-0008N2-1t for emacs-devel@gnu.org; Thu, 08 Apr 2021 15:20:24 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:52973) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lUaCM-00035m-R7 for emacs-devel@gnu.org; Thu, 08 Apr 2021 15:20:19 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id y204so344692wmg.2 for ; Thu, 08 Apr 2021 12:20:14 -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=LRfOm1F5ur9aEdWwsthlMF6FPxmmfA1BOcoJohSljuQ=; b=D2bJMjBkvWBx9Ywurlql6z5ah2YosUjDt31nML5v0oiFr+6VxJnz/BTA6wr/p34XaC M6cVi36gAAqYDumqf1RU54mNGb7losPjJqn2RbWAXX1JsAYrYX5FJeyW1X3dWySvoGsr gEuqPuLMEyY+Kbc52zhd1uqBEN1pXZKj2JJEbz0V7WzAa1Ne7YFkDh2SWr8FoovXSjRS Dzl1JdvwIR+qnesZgUj/vgEMjA5hQWp9w1XpGC2UWc7EIMHChLS4dyE/N0jSkDs4uwah 3YDEe5WR0Jh6GpJUnOAZfxUAnzwxxeObRBiXUOXQaqRYGyZIg6/JozXo8vSuS7rcyx7d XZBg== 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=LRfOm1F5ur9aEdWwsthlMF6FPxmmfA1BOcoJohSljuQ=; b=HiFUyMckFGhmpv8u8Siu5JvSPya3didgF93GBSZzZE3ebLmppwB6kDIGh4zvk/Fj3c fErxTbgcBmrsoCjrvLoCsycepySGcWtoqlQz/LqN/OCW0HS+zN6/xAjfB0Q74t6FBmeJ 2nCTyleXhJLjDIVC5PJSkWcK3oca1dGfHTrHitiEdGuv9fK/H0x4eaJULXQTpFlde8eS vGSntJ4l0d3GNrJNTwOUq+XoCdCS3FA4iajIDNJn4QudZrHpvyaMkcpuApFpO2AsrB/M P6BgiyCyfOsp1iPHasOfeGzjUf4/6/oEdQr/b+Gvlq44B8/z/3HQq9P1fsEj14B5VKpu qcVg== X-Gm-Message-State: AOAM531q7cFW0bBVaOK1wc4xppV6U1rl9xCfu3HFAEoN9GPRidjnDy1H 8iIVurGfZV0WpAdN7kQmlAiyxqo/TUE= X-Google-Smtp-Source: ABdhPJyV3CLjwlDg6ore2l9ClwnI3ZwbdVvjQ/RNu+75vWThMlArM+sHcfZamX9Qw7GINyn9HwPa4g== X-Received: by 2002:a1c:a145:: with SMTP id k66mr10399837wme.54.1617909613280; Thu, 08 Apr 2021 12:20:13 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y31sm226435wmp.46.2021.04.08.12.20.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Apr 2021 12:20:12 -0700 (PDT) In-Reply-To: <82c86e8f-06e7-a7ed-56c5-5f6766df591b@daniel-mendler.de> 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:267659 Archived-At: On 08.04.2021 18:37, Daniel Mendler wrote: >> I think we should arrange for the completion table to provide that extra >> text, so it can be more meaningful than an arbitrary number.  Also the >> user needs to be able to know "which is which", so it needs to be >> connected to something that's displayed in *Completions* that >> distinguishes them. > > Yes, that would be the best possibility. There are many ways to provide > that data: Via a text property, via an extra metadata function, etc. In > the case of Swiper the extra data could simply be the line number. > However a general solution should also automatically generate indices, > since it is probably better to not require the completion table to > provide the information in any case. I would like some graceful > degradation. Another approach would be to add a new "extra property" or metadata element which will say "don't remove duplicates". I do think it's questionable, though, to include completions that are hard to distinguish. >> E.g. maybe we could arrange for the minibuffer text to be >> matched against the *annotated* candidates in some cases.  I think this >> requires more thought, together with concrete examples. > > Generally matching against annotations functions is problematic. As I > interpret things, the point of annotations is that they are not > matchable. Maybe they are more expensive to compute, so this should > happen lazily for the displayed candidates. But using it only for > disambiguation should be okay. Then one would only compute the > annotation when doing the actual completion? Matching on annotations is indeed problematic. And if such conflicts are rare, perhaps we could rely on the user making the final choice using the *Completions* buffer? Further, that's only important if the choice between them is actually important (and we weren't using them just to display, say, all available overloads of a method in the completion popup).