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 15:35:46 -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="17327"; 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 21:37:26 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 1qZG8z-0004K4-8p for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Aug 2023 21:37:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZG8c-0004e9-PQ; Thu, 24 Aug 2023 15:37:02 -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 1qZG8Y-0004cw-D2 for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 15:36:58 -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 1qZG8Y-0002L5-5A for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 15:36:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZG8c-0007xj-81 for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 15:37: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 19:37: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.169290580830588 (code B ref 65459); Thu, 24 Aug 2023 19:37:02 +0000 Original-Received: (at 65459) by debbugs.gnu.org; 24 Aug 2023 19:36:48 +0000 Original-Received: from localhost ([127.0.0.1]:38657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZG8N-0007xI-KT for submit@debbugs.gnu.org; Thu, 24 Aug 2023 15:36:47 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZG8L-0007x2-1F for 65459@debbugs.gnu.org; Thu, 24 Aug 2023 15:36:45 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5E0CB442D8F; Thu, 24 Aug 2023 15:36:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1692905789; bh=p9P/wiG3KQ7FUBqzrAqaDvBS6qyb9eJcXJsUwYvPt00=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=n3YmcTUSHf6iP1j0iO8bqHFbnutNX/C6QMljZekgCrUcNamRTx2IvWnXtu2JkQomL Oqq1jtC2Ugk9oo6L2KQRw9aqIdZjuL8SnxNmw1zm8ZVTTnOJD01rety2VArLWu7P7S F9Gr4y1rH4MFnfOaNsoU3QPGZcYA9WvetU8ajGr4ySrZOqrsSzM0O9uAg2oQrjjLKL Q7qKcVPZrKxBLWsme/dneB81eG5dhkLkE4HojMy6c4DTs8iardiCZ6+50sUamL3S7Q sQapOjxdPQ4plXHqZ0Xh9UYaWFsdbFOVNOH/XBT4vrtUsHIlDlTD9/i8XrQ8RybtQV Y4jeeasGfQdEQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5E5CA442D8D; Thu, 24 Aug 2023 15:36:29 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4D61B1201B3; Thu, 24 Aug 2023 15:36:29 -0400 (EDT) In-Reply-To: (Heime's message of "Thu, 24 Aug 2023 18:50:44 +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:268353 Archived-At: >> 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? > > I was planning something like for 'read-file-name' where one can expect > that the initial input will very likely be the part the user will end up > typing, You mean if the users will probably select "Chronological Dating", you want to prefill the buffer so they don't need to type it and just hit RET? Using the DEFault arg gives you the same benefit without prefilling the minibuffer, so I must be missing something. What would be the advantage for the users by prefilling the minibuffer with "Chronological Dating"? >> 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? > No ordering actually happens, a particular element in collection is used > to prefill the minibuffer entry and consecutive elements in simple > cycling continue through the next stages. Yes, the ordering I'm talking about is the order in the operational flow refined such that if the likely next stage is "Composition and Provenance", then you'll want to use: "Composition and Provenance" "Isotope Analysis" "Physical Analysis" "Chronological Dating" That's what you want, right? >> 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. > Actually, tho order is only obeyed for the specific cycling I am using, but > users have the possibility to use a different UI such as the usual manipulation > possibilities provided by completing read. You mean, if they use, say, `icomplete-mode` or `vertico-mode`, you'd prefer that those UIs use an alphabetical ordering rather than the one based on operational flow? >> 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 > Then my conclusion is that the introduction of INITIAL for 'completing-read' > was a mistake. That completing-read should only be about completion. And that > prefilling the minibuffer should involve a separate function call. FWIW, I tend to agree and if(?) we introduce a new API I'd replace this INITIAL-INPUT argument with a function which could then do what we usually do via the `minibuffer-with-setup-hook` hack. Stefan