From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.devel Subject: Re: RE: [External] : Doc of deprecated INITIAL-INPUT arg of completing-read Date: Mon, 27 Jun 2022 19:22:55 +0200 Message-ID: References: <87v8smt9lp.fsf@web.de> 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="30551"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , Emacs Development To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 27 19:24:53 2022 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 1o5sTj-0007nI-V6 for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 19:24:52 +0200 Original-Received: from localhost ([::1]:33670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o5sTi-00018o-Sc for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 13:24:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5sS3-00089x-JN for emacs-devel@gnu.org; Mon, 27 Jun 2022 13:23:07 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:56381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5sRy-0008F2-1I for emacs-devel@gnu.org; Mon, 27 Jun 2022 13:23:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1656350576; bh=FfwC8k0uEcTL4tog1BPNxkKOsL63u0B3N/rYr1sfG64=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=b0i97UMmtdMOLrdTYbWukzBTIaZpK+8V8c5459e/uhAELgC4JLUPD0t2uY1Kqn/EY SogxYePyWOS5Asg3L4RyLcBW6bbGivU3kkstDSvTCEocDu7lSeeBDBp4hem3TxBzew LLqDlDNq+t3dak6sBLrEZksjCBWKAV5+vmfplD+I= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [92.251.127.164] ([92.251.127.164]) by web-mail.gmx.net (3c-app-mailcom-bs06.server.lan [172.19.170.174]) (via HTTP); Mon, 27 Jun 2022 19:22:55 +0200 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:YEOJ1/jMO8OtcKOqT4DI7mCloRgDDCDesA9RL9tx5RKrdGr4gtwFHDtB5bVpveAvf/K5D TWpn6OVgQ0thOGey1PTKby3weWDjSkpupzR0QqKA0jSNfAqvxy32p1n2BA/ZcK0Hm5p+zRLP39LV UvmJCO29Uf3+2WKfe55T/Zp+VA3xrWUsjJU3rhxoFkCue6nONv4vmnepEr+d2rWgPjDX+dSNXJ7K rl3WARcMHEs8l90CocnKc2vAdDAlbYjt2B4DV1Qf3CwyXFhUwn8iNJxJKLkSmrWbziOeKOMsyjhs ro= X-UI-Out-Filterresults: notjunk:1;V03:K0:KHPL3eCeC5Q=:5ts6t1wnRAiUuRPsWfJfUj DxqX6WHl4Gegegn+rkp6fdY4NZbXF8OTze2pP8fKPtBsLmTyK8RrvLmF8RLQMHtbWZlX2sXTU ANEnNAgs/PIjiRun8lslhZ3tvPJQZF1QTOJq8dVyPEdLAtDnzUuchzuqh280VNY/V4A+lR2kE IvhWCmomfI9Tp/xDfN49uJXzz4rg3x38FbUuxaipPCwWXGm766MRU6uk+vFMQXzYEnAV5S/yl pIMO4um8YFz2Pzobi6AvpSFg7MKJrhyQs0tLJocCTE/qC9lZjdhNffgR+1RVQElxXhJLFOPmv DAbIli8Xs+P445IA9KIhXKqrCrMWK2e8UK6Ct/+Q4i9fIxGgDuqzdOJyRinMYnvq4cTqbc0zZ QOG/oU4y/BgfCzW/l8H3g0ZhBprfSSk/DCWPgKlI6/J+iUxj7cYBATT2uWtpTeDOn9ZmWkxk5 zVHvp1ia5dLGOl1CejaKS7uCJZamgDWNGD5/c6ibGa03CmNhZ10z6VapI2A+gQUijxKmT9AF8 NQDnvzjgdEpaBZ/noSdvFFcLwy26MwbgXUk7cZ4oY7o43mJaIXsKKkCPgNQm5Beo9lc2iSVOD /6v7G8C1+aEk/IoG6aepaVdSyxzZPfu292Rr0olLoZD9gKnXREk6Zejd1Zs3Y21D32SylVadb gXTcuHKM5b0qAT2EAd6/AEqJBy4cMyc2hgNL5i/I52W+cgpQLgaJRh7jvR3IGSntDW4zkBC1H hPOsj+JdqYh6FBzGgRVShIA7pX6vhKvz12mngVQUw2M3qe4Y5msfq87lPPc9PBMz8HlYFhVd Received-SPF: pass client-ip=212.227.15.19; envelope-from=dimech@gmx.com; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:291669 Archived-At: > Sent: Tuesday, June 28, 2022 at 4:33 AM > From: "Drew Adams" > To: "Michael Heerdegen" , "Emacs Development" = > Subject: RE: [External] : Doc of deprecated INITIAL-INPUT arg of complet= ing-read > > > there was a long discussion in emacs-help about the INITIAL-INPUT > > argument of `completing-read'. Among other things people complained > > about the argument being deprecated. > > > > I agree that it's not good to use it in nearly all cases, but there AR= E > > a few cases where it hardly can be avoided - we have over 30 uses in > > Emacs itself. So I want to suggest to change the docstring to warn > > strongly about the usage of that argument, but stop saying it would be > > deprecated. > > > > This is to make the current state of the code more consistent - I don'= t > > plan to work on changes that had been suggested in that discussion. > > > > So would this patch be ok to install for now? > > FWIW, for my part I disagree that any "warning" > is warranted. There's nothing dangerous to warn > about. > > I disagree with this (as I also disagree with the > deprecation): > > Using this argument is strongly discouraged--it is > ^^^^^^^^^^^^^^^^^^^^ > normally best to pass nil for INITIAL-INPUT and > ^^^^^^^^^^^^^ > supply the default value DEF except in few special > ^^^^^^^^^^^^^^^^^^^^^ > cases like inserting a prefix common to all > completions or an initial part of a file name. > > There's zero reason to discourage its use in any > blanket way, let alone "strongly" discourage. I agree that there exists no reason to discourage it. Nothing bad or difficult happens when it is used. > INIT and DEF are different in behavior, and thus > in use cases. Telling users to use one of them > _instead of_ the other is misguided, IMO. > > All that's needed is to make clear that INIT > isn't intended as a _substitute_ for a default > value - and vice versa. That's really the point > (IMO). The use cases of INIT are different from > those of DEF. That's what should be made clear. > Then leave it up to coders to use each as they > see fit. Right. When people start mixing things up or hack their way to things that creates confusion, the solution in for them to stop with such approaches. > But the confusion over their different uses is > related to a missing feature, IMO, which is the > ability for users to automatically insert the > DEF value (not INIT) into the minibuffer, as an > alternative to using `M-n' to insert it. > > Neither alternative is absolutely "better" than > the other - this is naturally a user preference. > > The mistakes made in deciding to deprecate (or > discourage) INIT-INPUT are two: (1) confusing > it with a default value - DEF is no substitute > for INIT, and (2) thinking that it's never a > good UI to insert default values (DEF) in the > minibuffer. > > #1 should be fixed by removing the deprecation > and explaining the difference between the two > (not by warning not to use INIT). > > #2 should be fixed by letting _users_ decide > which DEF-inserting behavior they prefer: (1) > automatic or (2) manual (`M-n'). > > The choice of whether DEF should be inserted in > the minibuffer should be up to users. It's not > for Emacs to decide for all and always which UI > behavior (auto or `M-n') is better for everyone. > > If a user often wants to use (edit or choose) > the default value then s?he might well want it > to be inserted in the minibuffer. If a user > rarely uses the default value then s?he might > want to insert it only manually, with `M-n'. > > That's really what it comes down to: having to > delete DEF manually, if you don't want it, or > having to insert it manually, if you do. > > (This is somewhat akin to the choice of whether > to use `delete-selection-mode'.) > > In the help-gnu-emacs discussion you cited, I > detailed what I would propose for #2 - I won't > repeat details here. I'll just say that users > should have some way to choose whether DEF is > to be automatically inserted in the minibuffer. > > (I also said there that they should have a way > to choose whether it's inserted in the prompt. > With my proposal, when DEF's auto-inserted in > the minibuffer it's not inserted in the prompt, > but users can also choose to never insert it > in the prompt.) > > In any case, a missing insert-DEF-in-minibuffer > behavior is 100% _independent_ of INIT-INPUT, > which, yes, shouldn't be deprecated. > >