From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: carlmarcos--- via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: completing-read depricated initial-input Date: Thu, 23 Jun 2022 12:06:23 +0200 (CEST) Message-ID: References: <86r13hubaw.fsf_-_@gnu.org> <86letphfke.fsf_-_@gnu.org> <86mte3lsj2.fsf_-_@gnu.org> Reply-To: carlmarcos@tutanota.com 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="7350"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Drew Adams , Christopher Dimech , "eliz@gnu.org" , "monnier@iro.umontreal.ca" , Help Gnu Emacs , "michael_heerdegen@web.de" To: Arash Esbati Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 23 12:10:32 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 1o4JnD-0001ke-UR for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 12:10:31 +0200 Original-Received: from localhost ([::1]:48722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4JnC-0002IS-Oz for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 06:10:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4JjQ-0008Pn-EW for help-gnu-emacs@gnu.org; Thu, 23 Jun 2022 06:06:37 -0400 Original-Received: from w1.tutanota.de ([81.3.6.162]:53974) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4JjK-0002NN-CU; Thu, 23 Jun 2022 06:06:35 -0400 Original-Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 12CFCFA056C; Thu, 23 Jun 2022 10:06:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1655978783; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=pF1si/zn6VZ6vNM3gDaH1+cRJzTaNmA5h9E3cqershI=; b=QHb2EU9LcUWuKXDzjWw7WySgj1smRKU0yz7CftInRYDv5CTQ/utJDHa3M8FBRLD0 3O5WkA3R8VHvCnJYSLmBOr44o5bCDtwIJYBrVt09CeBwXiumd8I8uR5comBMe3uvSyP 9sLRI30ly5aqO9Djm8BGz0Jpzg0Gz7h69tDvT3eD3MrQAv0PkgnCXnaAypIP4bWi/Zd 4Z6cCvclFeZDqZQ8XvTQ7gPar2ce+c4aMOs1yqY41Ux0xZX9/cLf/BX/rSNUHIcYGF0 hFLtIgaoGpZe45ReNy45urDTU5GFd7RHtUpiu7oQEB0ZSvX5ULnUzJshf3ocT0hzhqX U3vA6zWAAA== In-Reply-To: <86mte3lsj2.fsf_-_@gnu.org> Received-SPF: pass client-ip=81.3.6.162; envelope-from=carlmarcos@tutanota.com; helo=w1.tutanota.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:138006 Archived-At: Jun 23, 2022, 07:59 by arash@gnu.org: > Drew Adams writes: > >>> > `completing-read' is extremely general, allowing for many different >>> > interactions for many different kinds of use cases. >>> >>> 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. > > 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. > This is where I disagree.=C2=A0 The documentation discouraging and recommen= ding not to use it, reads as a statement that lacks any persuasive discussion. It is not valuable to discourage something simply because it is usually fou= nd that it is empty.=C2=A0 A designer might know better what he is trying to achie= ve.=C2=A0 At times it is better to display some indicative words to the user, than nothing at all= (an empty field). INITIAL-INPUT allows one to display a personally preferable feature whilst = keeping the usual default intact. One must not confuse "initial" with "default".=C2= =A0 An initial value could be assigned to some preferential usage that differs from some well kn= own canonical setting. =C2=A0=C2=A0=20 > =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 readin= g. > 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? > I do not see that the deprecation was superceded through some improved coding mechanism. > Best, Arash > > Footnotes: > [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Initial-In= put.html > [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Minibuffer= -Completion.html >