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: Wed, 23 Aug 2023 09:07:52 -0400 Message-ID: References: <83jztmro8z.fsf@gnu.org> 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="39831"; 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 Wed Aug 23 15:09:43 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 1qYncF-000ABB-2f for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Aug 2023 15:09:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qYnbt-00082j-9K; Wed, 23 Aug 2023 09:09:21 -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 1qYnbX-00081w-LP for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 09:09:00 -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 1qYnbX-0003yU-Dc for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 09:08:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qYnba-0002z0-CQ for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 09:09: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: Wed, 23 Aug 2023 13:09: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.169279608911394 (code B ref 65459); Wed, 23 Aug 2023 13:09:02 +0000 Original-Received: (at 65459) by debbugs.gnu.org; 23 Aug 2023 13:08:09 +0000 Original-Received: from localhost ([127.0.0.1]:33144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYnai-0002xh-V8 for submit@debbugs.gnu.org; Wed, 23 Aug 2023 09:08:09 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYnad-0002x9-Dk for 65459@debbugs.gnu.org; Wed, 23 Aug 2023 09:08:07 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A60041000AD; Wed, 23 Aug 2023 09:07:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1692796073; bh=oC1LhtphNNyUUPr87vmyZVuRWmbdGaVItcP1K1JGc+4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gd0gBQhGr3hxEMrhvwMB47oOGwfbGww4JdW6ENzG4+2kJXpR6s9EuCUjigET0GuCO 0UYGIB36K9sdG1gWrETXFE8ptROPywunSWO9dOKoeCYUeNS0tHCKEhHAJwgen3jjFu gBD4LnkmUARUwpxZAKm9u14wy6YLA/pigGMt/thPENwwrMgvmTnEd6ZD1hgPeiBm6a nBuXN0U9HtMs8FDh9ZJPLI0nyTYQ0RHScDyLvAEYgaBYIPQgMRMh8AaXp/vgc22Sx7 WenpdPf90AlPg3fibkcD6OFahqedq354LKNB+a+kyK1YGhEfjbJbydKOHXEg0BvmDo zkYmBM+MFwscw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 79174100064; Wed, 23 Aug 2023 09:07:53 -0400 (EDT) Original-Received: from pastel (unknown [104.247.227.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 541A01202D5; Wed, 23 Aug 2023 09:07:53 -0400 (EDT) In-Reply-To: (Heime's message of "Wed, 23 Aug 2023 11:57:55 +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:268239 Archived-At: > How can we describe it - primitive - then. What lots am I missing about > the behaviour of INITIAL-VALUE being independent about the state of the > other variables ? I can't really answer that because I don't fully understand what it is you're trying to do and feel that you can't do with this API. Maybe you're missing what other people usually miss: `completing-read` is also used for completion of things that have structure, like file-names, and where the INITIAL-INPUT may be a good starting point for the user while not being a valid end point (i.e. a choice rejected by REQUIRE-MATCH). > And that entries in collection always start from index > zero when cycling is used. Don't know what you mean by that. Could you clarify? By and large the COLLECTION argument is treated as a *set*, i.e. without any ordering. Instead, the ordering is chosen by the UI (i.e. the completion code) and can depend on various user config choices, so I don't know what you mean by "always start from index zero". I'm also not sure what you mean by "when cycling is used". Are you referring to the first choice offered by `minibuffer-complete` when `completion-cycle-threshold` is set to something like t? > I have found its capability limited, having actually used it. Are you talking about "used it" as an end-user or as a coder? > I expected that as the functionalities get enhanced, some deficiencies > also get pumped up. Giving more control to the programmer about what > gets displayed in the minibuffer. The intention is to try and make room for 3 parts: - what the programmer provides to `completing-read`. - what the end-user sees. - between those two, the specific completion UI chosen by the end-user. So indeed, we don't want to offer too much control to the programmer who calls `completing-read`, so as to give more freedom to the completion UI. Stefan