From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: [External] : Improvement proposals for `completing-read' Date: Thu, 8 Apr 2021 11:29:40 +0200 Message-ID: <3470841e-d0ef-69d2-aa58-67fd0fd57645@daniel-mendler.de> References: 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="11043"; mail-complaints-to="usenet@ciao.gmane.io" To: Drew Adams , "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 08 11:31:48 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 1lUR0s-0002ba-Rw for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 11:31:46 +0200 Original-Received: from localhost ([::1]:39436 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUR0r-0002f5-S8 for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 05:31:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUQyz-0001oN-Vf for emacs-devel@gnu.org; Thu, 08 Apr 2021 05:29:49 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:53261 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUQyv-0007Q8-J2 for emacs-devel@gnu.org; Thu, 08 Apr 2021 05:29:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/qewhjw1Y+LzUEggx9AHyJ6xRJlPOKhM9STsO8FKz4A=; b=vnK0qUXeJM/TNm5+/XFu31z02B ATEUyOrNrCkleKmWGWD7ONniE8zbfonN9iyV4c+EJRQhPSbWy8Wcgf8hnHZEly0GwB/XHFXKhh6JD 6fb5kc1zv50dxe4YBikmTCmJVJAFwMPsNxdIQqhZ3OlLpeT8DTEFz9lt/VjLMzfBvk00=; In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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:267603 Archived-At: On 4/8/21 1:49 AM, Drew Adams wrote: >> Proposal 1: Disabling the history >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > What's the problem? How does it hurt for users to > have the default history, `minibuffer-history', > available? They don't have to use it, right? > > I'm not saying I'm opposed to your proposed solution. > I'm saying I haven't seen the problem specified that > you're trying to solve. As an author of completion commands I like the ability to disable the history if I think it is useful. One such case is when you browse the history itself using `completing-read`, but this is certainly a very narrow case. But `read-from-minibuffer` already accepts the `t` argument, so it will be less confusing if `completing-read` is aligned with it. >> Proposal 4: Add support for `group-function' >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > So the overall problem you say you want to solve is > that `completing-read' is too complex, hard to use, > and hard to implement. Yet you want to add something > like this, to make it even more complex and hard to > implement? ;-) Haha, yes :) But adding metadata functions is a small cost and small addition in complexity. > My main concern about further complicating the code > implementing `completing-read' is that things will > end up hard-coded - and hence difficult to use by > users and by implementers of 3rd-party code. In this case it is actually an optional extension. The UI does not have to use it, but can use it to offer an enhanced display. If the completion command does not use it nothing is lost. The proposal is fully forward/backward compatible. It is a pure enhancement, like annotation/affixation functions. >> Proposal 5: Forbid the null completions for `REQUIRE-MATCH=t' >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Empty completion returning a special value (namely "") > lets code know that the user provided empty completion. > That's a _feature_. I'd say it is a bug. Stefan Monnier seems to agree to some extent if I understood correctly. Unfortunately the bug is widespread so one has to look a bit around if there will bad effects due to fixing the bug. >> Proposal 6: Return text properties from `completing-read' >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 100% agreement. I proposed this a zillion years ago > (and added it to Icicles). Rejected for Emacs. But > this feature should only be _possible_, not imposed. I hope that patches which allow text properties will be accepted. The initial responses I received sounded positive. There seems to be some agreement that it is useful to improve the support of the selection use case of `completing-read`. >> Proposal 7: Allow duplicates and retain object identity >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> There are not many completion tables which generate >> duplicate candidates > Do you mean not many _kinds_ of completion tables, > or not many completion tables (in practice)? If > you mean the latter, I'd like to know why you think > that, as I doubt it's the case. (No, I don't have > numbers either.) I am just saying that I have not observed many duplicates while using Emacs with completion systems, which do not deduplicate. I think `find-library` or `load-library` shows duplicate candidates? >> and there exist multiple completion systems >> which do not perform deduplication at all. > > Icicles among them. And Selectrum and Vertico :) >> Note that this proposal is useful mainly for completion tables which >> disable sorting by setting `display/cycle-sort-function' to the >> identity function. > > Why? (I'm pretty sure I disagree.) I assume a Swiper-like command. If you don't sort then you can simply scroll through the duplicate candidates, which retain their original order. I am sure one can jump through many hoops to make this nice in any case. Stefan Monnier requested that default completion should also disambiguate the duplicates on the UI level, such that one can still chose between them ("reifying the object identity"). >> Proposal 8: Completion style optimization of filtering and highlighting >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Again, please explain just what's been found, > instead of reporting what you've decided. Details > matter. What kind of highlighting? When and how > was highlighting done, and to what? What was tried? > In what contexts? Just what problems were found? No, I am making concrete proposals here. I am not reporting issues. > General critique: Please present _one_ proposal per > thread, for consideration. This thing about a Yalta > meeting having taken place and someone descending > from the summit with stone tables presenting the > IX Proposals isn't so helpful, IMO. I considered this but decided against it due to the relations and to keep the discussion at one place. As you see from the current responses the discussion seems to be productive. This includes your mail. Thank you for your responses! Daniel Mendler