From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Improvement proposals for `completing-read' Date: Thu, 08 Apr 2021 13:30:57 -0400 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29340"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 08 19:33:01 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 1lUYWb-0007Xp-DQ for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 19:33:01 +0200 Original-Received: from localhost ([::1]:46062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUYWa-0005JT-BR for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 13:33:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUYUq-0004AC-8r for emacs-devel@gnu.org; Thu, 08 Apr 2021 13:31:14 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63176) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUYUl-00013A-E3 for emacs-devel@gnu.org; Thu, 08 Apr 2021 13:31:11 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DE1094409E5; Thu, 8 Apr 2021 13:31:05 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 75185440939; Thu, 8 Apr 2021 13:31:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1617903064; bh=3kNKqcupE4byWTOavqqFnP2Q6afy4OhUgVHooCAurts=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=njn4TKKcKyVQfyTI5Nu1JU1GgyiBA+GJDdUdaLukLbviwcD3OGqoz0SjK3G0SJ7Av 4H2Ymq7zTrsuffjJq1iLJZlow4AzuD1Mshx8eCHnuhfGA792xq5n2ySyBAZBVYtSdR 8SWA/UaXrcUFsLP0QS75UBvsxWY7UfvdgjFwnA+5HfDzootmhIwVRxyC1jd1U2zj7q Rv5tnUm1eD9YxhLC0c0q0XRlRTQJRrUP+B7o+NxVZ4LQWdmU/zfaXliPTYm0JA0oiw LSqYwHLsnpRh51Eh4J3MbNKP3L5DpNc1EFRl2etIgD4Qyq6wZR0r6f+jnD/kAzM0fn F56MeVTRy9jBA== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4C44A120802; Thu, 8 Apr 2021 13:31:04 -0400 (EDT) In-Reply-To: <82c86e8f-06e7-a7ed-56c5-5f6766df591b@daniel-mendler.de> (Daniel Mendler's message of "Thu, 8 Apr 2021 17:37:39 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:267638 Archived-At: > 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. There's also the issue that we want the system to work "by default" (e.g. even if your UI doesn't take advantage of all the latest extra metadata features). So maybe rather than having a way to add extra data for disambiguation, we should require the completion candidates to be unique (as is the case currently), and then add an extra feature that can hide some part of the text. E.g. for a completion table of something like Swiper, every entry would contain the line's text plus a suffix containing the line number. And then the metadata would tell the UI how it can hide the suffix if it doesn't need textual uniqueness. >>> One thing to consider - maybe returning the highlights as some extra data is >>> not actually faster than simply propertizing the strings? >> The extra opaque data is cheap/free to compute. It would not contain >> "the highlights", but just the side information that might be needed to >> compute the highlights: e.g. you can't do the highlighting correctly for >> `partial-completion` without having access to the "pattern" against >> which it was matched. > I don't think this is true. [...] I don't see anything in your description that disagrees with what I said, so it looks like we're in "violent agreement" ;-) Stefan