From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: Doc of deprecated INITIAL-INPUT arg of completing-read Date: Wed, 29 Jun 2022 01:00:04 +0300 Message-ID: References: <87v8smt9lp.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29532"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/+ () (2022-05-21) Cc: Michael Heerdegen , Emacs Development To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 29 00:02:36 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 1o6JI4-0007PG-DV for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jun 2022 00:02:36 +0200 Original-Received: from localhost ([::1]:59530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6JI3-00024x-08 for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jun 2022 18:02:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6JGC-0001HJ-HF for emacs-devel@gnu.org; Tue, 28 Jun 2022 18:00:41 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:34327) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6JG9-0006lG-VB for emacs-devel@gnu.org; Tue, 28 Jun 2022 18:00:40 -0400 Original-Received: from localhost ([::ffff:197.239.7.68]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000087C4C.0000000062BB7A00.00000741; Tue, 28 Jun 2022 15:00:32 -0700 Mail-Followup-To: Stefan Monnier , Michael Heerdegen , Emacs Development Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:291703 Archived-At: * Stefan Monnier [2022-06-29 00:33]: > > For anything there must be reason. What is reason to "strongly warn" > > programmer not to use it? > > Because there's a lot of past experience where people want to have the > Windows-style behavior where prompts get prefilled with the (selected) > default, and they don't understand that in order to get that they need > to change `completing-read`. So instead they abuse `initial-content` in > their code (even though it doesn't give quite the same behavior either > but gets the closer). That would hypothetically mean that for one smaller group of users using Windows-style behavior every programmer has to be "strongly warned". Your explanation above is also not part of docstring and I do not say it is necessary to be, but when you think there are such reasons than maybe better is to solve how that understanding will arrive to users. Understanding will arrive with good communication in the docstring. Instead of strongly warning against useful function it is better to strongly make distinction in the description what that initial input means as distinguished to the default value. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/