From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arash Esbati Newsgroups: gmane.emacs.help Subject: Re: completing-read depricated initial-input Date: Thu, 23 Jun 2022 09:59:13 +0200 Message-ID: <86mte3lsj2.fsf_-_@gnu.org> References: <86r13hubaw.fsf_-_@gnu.org> <86letphfke.fsf_-_@gnu.org> 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="36106"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 Cc: Christopher Dimech , "eliz@gnu.org" , "monnier@iro.umontreal.ca" , Help Gnu Emacs , "carlmarcos@tutanota.com" , "michael_heerdegen@web.de" To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 23 10:08:45 2022 Return-path: Envelope-to: geh-help-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 1o4HtM-0009Dm-VN for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 10:08:44 +0200 Original-Received: from localhost ([::1]:39892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4HtE-00060t-3c for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 04:08:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Hmm-0003tE-Aq for help-gnu-emacs@gnu.org; Thu, 23 Jun 2022 04:01:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Hml-0008Mn-Fo; Thu, 23 Jun 2022 04:01:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=1On4yZzt3pmhV8DG6bcdIqs9z4BytJKsnNoeEvXh1jo=; b=N6kc6BpiOk1PZeTXc/o0 zpTpAcL2Ge9vh88t4+4QJFbnan3RsGrHjuRYyHUq5cwqY9IW/ffrchgIxBmpK5EHoLqg0H4CESLiQ P2dmGUNQKnAV56fhbiy3NzEgMo7iHajVmAUMgIrqNxw7kpEMQ0K9Mj5N+gV/4j9ELMeqabXR+VniB 7ED9BFHHK1nA0fCqbqed1Kxo11VBIdmlg14zTpcDGuD9opPIVQc8E1sHLm/1ZXdqdmG+4fZ/MHoLA usHCxk7wqtWjRAeJ726b0ma7uJ+FiOWpYFzIsB7INUr43JMDkn1BAjzACHL11jVFCBn4EDK2elUvf C4cRCM6x5EJ0iA==; Original-Received: from p4fe3ee56.dip0.t-ipconnect.de ([79.227.238.86]:60490 helo=MUTANT) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Hmj-0007ZF-94; Thu, 23 Jun 2022 04:01:55 -0400 In-Reply-To: (Drew Adams's message of "Tue, 21 Jun 2022 22:07:41 +0000") X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:138002 Archived-At: Drew Adams writes: >> > `completing-read' is extremely general, allowing for many different >> > interactions for many different kinds of use cases. >>=20 >> True, unfortunately. > > Why "unfortunately"? Because extremely general tools give one many ways to do things. It is just hard if you find out afterwards that things went in the wrong direction and you try to clean up. No other reason. > And there's `read-from-minibuffer', which is > even more general. Therefore we have `read-string'. > I'd rather have Emacs implement, test, and maintain it than do so > myself, if possible. ;-) Good strategy ;-) >> but you're still free to use the old feature if you >> think it has a added value from a user perspective. > > Sure. With the risk that what's deprecated might be > desupported at some point. > > (At which point you can always choose to copy the old > code and continue to use it. With the bother of > dealing with incompatibilities, inconsistencies, and > having to keep some bits synchronized...) I don't think this will happen for `completing-read'. Looking at other places than the docstring of `completing-read', you find: =E2=80=A2 Emacs Lisp Ref: 21.5 Initial Input[1] Several of the functions for minibuffer input have an argument called initial. This is a mostly-deprecated feature for specifying that the minibuffer should start out with certain text, instead of empty as usual. [...] We discourage use of a non-nil value for initial, because initial input is an intrusive interface. History lists and default values provide a much more convenient method to offer useful default inputs to the user. There is just one situation where you should specify a string for an initial argument. This is when you specify a cons cell for the history argument. See Minibuffer History. 21.6.2 Completion and the Minibuffer[2] Function: completing-read [...] The argument initial is mostly deprecated; we recommend using a non-nil value only in conjunction with specifying a cons cell for history. See Initial Input. For default input, use default instead. =E2=80=A2 `read-string' docstring: Read a string from the minibuffer, prompting with string PROMPT. If non-nil, second arg INITIAL-INPUT is a string to insert before readi= ng. This argument has been superseded by DEFAULT-VALUE and should normally be nil in new code. It behaves as INITIAL-CONTENTS in =E2=80=98read-from-minibuffer=E2=80=99 (which see). Note the terms "mostly-deprecated", "discourage", "recommend", "superseded". So maybe the docstring of `completing-read' should be adjusted to the statements above in order to avoid confusion? Best, Arash Footnotes: [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Initial-Inpu= t.html [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Minibuffer-C= ompletion.html