From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65459: completing-read INITIAL-VALUE unaware of COLLECTION and REQUIRE-MATCH Date: Thu, 24 Aug 2023 12:45:53 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28128"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 65459@debbugs.gnu.org To: Heime Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 24 18:47:36 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qZDUe-00075J-58 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Aug 2023 18:47:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZDUB-000100-6I; Thu, 24 Aug 2023 12:47:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZDU2-0000zl-VB for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 12:46:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qZDU2-0001gR-Mz for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 12:46:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZDU6-0003QW-6Z for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 12:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 16:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65459 X-GNU-PR-Package: emacs Original-Received: via spool by 65459-submit@debbugs.gnu.org id=B65459.169289561013155 (code B ref 65459); Thu, 24 Aug 2023 16:47:02 +0000 Original-Received: (at 65459) by debbugs.gnu.org; 24 Aug 2023 16:46:50 +0000 Original-Received: from localhost ([127.0.0.1]:38518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZDTt-0003Q3-QK for submit@debbugs.gnu.org; Thu, 24 Aug 2023 12:46:50 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZDTr-0003Pm-TQ for 65459@debbugs.gnu.org; Thu, 24 Aug 2023 12:46:48 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 615354424AC; Thu, 24 Aug 2023 12:46:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1692895596; bh=3nwFdHrgDoXjCpJcf4SEzQONuHbYJZjSCzKrOM6chz0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G979PLqfZNmOQhKHcejUjJSw3l5qFLayzw/84MGHvAXUOlhZ4Mm0IDPwWJJy4UYjr FHZ+pSRaxTN7Ltjs8Hzwjwm+MyqvKM4omnpF6FVtyXzooe6GnWBUJCoY69GaENxTKT /d9jrR+iA2G94qqgzVlP1YtO2vFJUfB4Lrl7KphE2nuVZXBsu6GpbH15n/a8bySnJR +7KAGFsKRGPfnJR5ssE+pJT6s2zBP946MsFt8N61AE2RDRvbeq+D83AFYQj3dNdgXn /q9euyKCkD6m9tcIEtFvvuOGlKz6CxcpS2LKoNg4/NQjavq/M5IAJyAIWvJGl3csKT bJ7tTRDV6XAvw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 988194424BC; Thu, 24 Aug 2023 12:46:36 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8709912031C; Thu, 24 Aug 2023 12:46:36 -0400 (EDT) In-Reply-To: (Heime's message of "Thu, 24 Aug 2023 14:51:29 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268347 Archived-At: >> > It is not, because the intention is on prefilling the minibuffer with >> > "alpha" rather than considering "alpha" as DEF. >> >> Could you explain why this is important in your case? > > There purpose of INITIAL has always been about prefilling the minibuffer. > No other 'completing-read' functionality can do such a thing. DEF has > always served a different purpose. For some reason that I cannot understand, > most of the communications I have try to persuade me to set INITIAL to nil. > INITIAL had a purpose, which under certain circumstances has implications > to the way COLLECTION is constructed and used. Rather than fixing the > difficulties for certain cases, the answer has always been the same, put > INITIAL to nil and just don't use it, and use DEF if you want. Even though > Default Settings and Minibuffer Prefilling result in two completely distinct > behaviours. My question is not about INITIAL-INPUT but about the behavior that the user sees: why do you want the users of your code to see a minibuffer that is prefilled rather than one whose content is initially empty? That question is not rhetorical. There can be many different perfectly valid answers. Depending on that answer, the best way to code it can be quite different, tho. >> That's partly why I've asked about a concrete example showing the wider >> context :-) - Stefan > > I am working on an Emacs org library for archeological investigations where > field practitioners can insert specific org templates detailing the progress > of excavations and finds. Each phase is categorised. > > For instance > > "Physical_Analysis" "Chronological Dating" "Composition and Provenance" "Isotope Analysis" > > And there exists a certain order. It would be difficult to change > that order on-the-fly just to make 'completing-read' happy. With each > exists specific templates that practitioners can introduce and > elaborate. Once certain aspects are completed, the previous > categorisations would be skipped, because they would no longer be > relevant. What gets shown is then directed towards improving > productivity, particularly when tight deadlines are imposed. So, IIUC, you have a `completing-read` call asking them which template to insert, and you want to order the set of completions based on knowledge of the stage at which they are? I suspect you'll want to use a COLLECTION that explicitly asks to not be (re)sorted and which you "manually" re-order before the call, so that the sort order you choose is obeyed not just by this specific cycling you're using but also for users who rely on different UIs. I don't see any part there that explains why the minibuffer needs to be prefilled, but that is usually handled separately from the completions anyway. Stefan