From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Heime 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 14:51:29 +0000 Message-ID: References: Reply-To: Heime Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8183"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 65459@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 24 16:52:18 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 1qZBh3-0001tB-Om for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Aug 2023 16:52:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZBgn-00067D-IP; Thu, 24 Aug 2023 10:52:01 -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 1qZBgl-00065L-L5 for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 10:51: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 1qZBgk-0004WS-TH for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 10:51:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZBgo-0008WF-DP for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 10:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Heime Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 14:52: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.169288871732735 (code B ref 65459); Thu, 24 Aug 2023 14:52:02 +0000 Original-Received: (at 65459) by debbugs.gnu.org; 24 Aug 2023 14:51:57 +0000 Original-Received: from localhost ([127.0.0.1]:38377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZBgj-0008Vv-2S for submit@debbugs.gnu.org; Thu, 24 Aug 2023 10:51:57 -0400 Original-Received: from mail-40141.protonmail.ch ([185.70.40.141]:18227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZBgh-0008Vh-Cu for 65459@debbugs.gnu.org; Thu, 24 Aug 2023 10:51:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1692888705; x=1693147905; bh=83ABPdPnnTgXi8vGub1iROXr7Nq7NTANa0TO9S8Gv74=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=k49jkKg5sog2bzGXk2ocqQUQLycI7uJRpD3vWFkbaEiDqV9DZGQm2frOv8UImX82i 3iaGr8iqg6M4c3kIHuNhQz6z1KoE5pZmdpqxh7BrsXHDPM2VVfR9A1r3FbStHeAelw XaiTkVA4IGdN24RorbtIFDyv5PrbpnEx3PrO6KlmYQk7uLU9sHoLRE+xrtZmV0Z2dw wF34JBd7ukEoexiOgI4S6jFWxuRmQ0jTmfSda2SV6VsRaql4WQefxrpOx1RPS/NBvY jtaTQUZpT4Bv8nRomCvQuC+67ahQCqgrQGzx6LuauSuaWoWdyWG8e4Rp8F1AbOtrM6 AeLMzal1z/w9A== In-Reply-To: Feedback-ID: 57735886:user:proton 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:268345 Archived-At: ------- Original Message ------- On Friday, August 25th, 2023 at 1:36 AM, Stefan Monnier via "Bug reports fo= r GNU Emacs, the Swiss army knife of text editors" = wrote: > > It is not, because the intention is on prefilling the minibuffer with > > "alpha" rather than considering "alpha" as DEF. >=20 > 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 understan= d, 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=20 difficulties for certain cases, the answer has always been the same, put=20 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 distinc= t =20 behaviours. =20 > > It appears that the maintainers might not be prioritizing the initial > > intention of prefilling the minibuffer. Currently, their emphasis > > seems to be on encouraging developers to either utilize the "DEF" > > approach or actively discourage the use of "INITIAL". But, I haven't > > come across a clear and well-founded reasoning behind these shifts > > in approach. >=20 > Not sure what you mean by "shifts". AFAIK this behavior has been with > Emacs "forever": most minibuffers start empty (but with an associated > default value) rather than starting with an initial value. Right. Because most minibuffers start empty (but with an associated default value) rather than starting with an initial value, this particular use of 'completing-read' in today considered to be the only way to use=20 'completing-read'. Something that is completely wrong because a particular use case has now became dogma. One cannot ever disregard the different fea= ture provided by INITIAL for those who want to use it.=20 =20 > This originally comes presumably from the absence of > `transient-mark-mode` (or associated visual highlighting, both of which > were introduced in Emacs-19) which means that it was annoying having to > erase "alpha" before you can type "beta". >=20 > Starting with a non-empty minibuffer does happen occasionally, most > importantly for `read-file-name` where we do expect that this initial > input will very likely be a part of the name the user will end up > typing, so its rare that the users need to erase it before they can type > the file name they want. Right. Although it is customarily rare, INITIAL does actually have relevan= t use cases. It just happens that over time, additional use cases have cropp= ed up. Rarity seams to have became a reason to discourage use of INITIAL. Su= ch school of thought is seriously misguided. =20 =20 > > But this is only easily done only when collection is actually being > > constructed in-place via the 'let' clause. But once COLLECTION > > starts getting imported from somewhere else (via a call to same other > > function for instance), your suggested solution is impossible > > to achieve. >=20 > 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 progres= s of excavations and finds. Each phase is categorised. For instance "Physical_Analysis" "Chronological Dating" "Composition and Provenance" "Is= otope Analysis" And there exists a certain order. It would be difficult to change that ord= er on-the-fly=20 just to make 'completing-read' happy. With each exists specific templates t= hat practitioners can introduce and elaborate. Once certain aspects are completed, the previ= ous categorisations would be skipped, because they would no longer be relevant. What gets show= n is then directed towards improving productivity, particularly when tight deadlines are impos= ed. =20 Tight deadlines in archaeological field excavations arise from a variety of= logistical and=20 operational factors). For instance, certain sites are threatened by constr= uction or development projects, with limited timeframes to excavate and document findings. Some = sites are at risk of deterioration due to environmental factors (e.g. flooding, collapse), meani= ng that emergency=20 excavations within short timeframes to salvage artifacts and information be= comes necessary. Such application should be concrete enough.