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: Fri, 1 Jul 2022 08:54:53 +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="31826"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/+ () (2022-05-21) Cc: michael_heerdegen@web.de, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 01 07:59:21 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 1o79gW-00086N-PV for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jul 2022 07:59:20 +0200 Original-Received: from localhost ([::1]:60836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o79gV-0001qD-Cx for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jul 2022 01:59:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o79f1-0000Uw-EI for emacs-devel@gnu.org; Fri, 01 Jul 2022 01:57:48 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:59121) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o79ew-0003F9-Nu; Fri, 01 Jul 2022 01:57:46 -0400 Original-Received: from localhost ([::ffff:154.230.66.106]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000087C4D.0000000062BE8CD3.00004EED; Thu, 30 Jun 2022 22:57:38 -0700 Mail-Followup-To: Richard Stallman , michael_heerdegen@web.de, emacs-devel@gnu.org 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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:291763 Archived-At: * Richard Stallman [2022-06-30 06:08]: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > I have many use cases for initial-input, when making calls I need to > > make a note, and I like entering new date and time automatically as > > initial input, so that I do not need to invoke keys in minibuffer. > > Is there a reason not to handle this the way most commands do? That > is to use the current or last-used date-time as the default, if the > argument is empty. There are good reasons. I am using read-from-minibuffer and completing-read many times per day as that is one of the way how I enter new notes about assigned tasks. In general INITIAL-INPUT is helpful to easier enter some value, and DEFAULT is what is chosen if no value is entered. Those are two different meanings not related to each other. If some people choose to make them same, it does not make their underlying functionality same. That is matter of docstring to explain it well for users. The DEFAULT I use for those cases where there is nothing written in the prompt in minibuffer, so just by pressing RET I would get the default. DEFAULT may be inserted also with M-n however, when there are many entries in completing that is rather for me "unsafe" way to choose the default as I may not have assurance that I have pressed M-n once or more times, and more often I use M-p to go back in history to choose some previous value. INITIAL-INPUT I use to help myself to enter some information quickly in the minibuffer. It is often, in my case more than often, different then the default. Practical examples: =================== Task has been assigned, and report is written on the task. DEFAULT is "2022-07-01 Customer informed." but INITIAL-INPUT may be exact date and time with space waiting for me as user to enter the actual note about it, like this: "2022-07-01 14:22 ". If I however, delete it, and press RET, I would get default "2022-07-01 Customer informed." Further, I do not use those functions directly, they are wrapped in my functions and what is DEFAULT is usually database backed entry, while what is INITIAL-INPUT is usually dynamically generated string to help me as user spare writing. This may not mean much to people who rarely use completing-read or read-from-minibuffer -- it means to me and team members who use it way too often and where INITIAL-INPUT becomes helpful string placed in mini buffer to help the with editing. It does not represent the DEFAULT. Also note that in database backed editing there may be different users, and one user could turn off INITIAL-INPUT, while other could have it, while third one could customize it. In general INITIAL-INPUT shall not be considered neither similar nor equivalent to any DEFAULT, it should be considered as helpful way to put initial string in minibuffer, whatever it may be such, and initial input is on my side rather editable, while DEFAULT is not necessarily considered editable. Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/