From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [PATCH] Support "\n" in icomplete-separator Date: Wed, 11 Nov 2020 11:49:13 -0800 (PST) Message-ID: <22623003-a30e-44f4-b396-97843fe32933@default> References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> <3622f4d2-c27b-eefe-e7fa-7e0fe0dab214@gmx.at> 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="8335"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: martin rudalics , Andrii Kolomoiets , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 20:50:49 2020 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 1kcw8n-000249-2y for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 20:50:49 +0100 Original-Received: from localhost ([::1]:52772 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcw8m-0005Jd-1M for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 14:50:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcw7V-0004ko-4d for emacs-devel@gnu.org; Wed, 11 Nov 2020 14:49:31 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:50700) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcw7S-00073S-Bj; Wed, 11 Nov 2020 14:49:28 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0ABJdWvh183753; Wed, 11 Nov 2020 19:49:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=cNRvEtv6wsNoDmiC3Ebp7+A/lkMEm+nFgQ/TjHkzHbk=; b=y8Bds24cYU6qWVJVDCU9/nTPPX/89j/wnXoDw2yT/A3/hnJxjzch7+30ntAqAxcYzJrp 7jJPaDu6H4bkqXLaCA9NGrXXt7ySGW6OtDCl1McRUZIRdG2MJbKZjnR7/6tcyCHMOmEn XeZp0liwTy+TYN4JZpzAzb/XGq5JhuVIvXSY1I8tG6sOFOJBlPM7ksA74fi7ZfHmlk+K g5N84rlIFL2Mej6XjZKC1UKhzBOPzHAvUsBTgCciRTJAGAdDf5B54rTyf8sD4o4MYbm5 k92v+CEspF7x1GDz8l83xBDpaL5IGlWkDJsjjwvGk4sWZblkSBkTBEl+Y4+G7Y0kbeX0 RA== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 34p72erhq0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Nov 2020 19:49:16 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0ABJfAuo017738; Wed, 11 Nov 2020 19:49:15 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 34p5g239cf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Nov 2020 19:49:15 +0000 Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0ABJnEeS019174; Wed, 11 Nov 2020 19:49:14 GMT In-Reply-To: <3622f4d2-c27b-eefe-e7fa-7e0fe0dab214@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5071.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9802 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011110114 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9802 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011110114 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/11 12:09:43 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:259047 Archived-At: > > Not sure what you mean by an application, but if the > > application is the thing that's presenting and reading > > the minibuffer then it's up to the application to > > decide how to present and use it, what to expect, and > > what to let users know about what to expect. > > > > There's no such rule/guideline, IMO, and none would > > be appropriate, to say that applications must accept > > that users (in general? always? all users? most?) > > want minibuffer windows to be of a certain shape/size, > > position, or whatever. >=20 > Users decide how large their frames are, how many windows they contain > and what the values of 'resize-mini-windows' and > 'max-mini-window-height' are. Applications that do not obey these > restrictions are wrong. Sure, unless they tell users what the behavior is and users choose to use them, i.e., choose that behavior. An "application" can present choices to users just as much as a user option can. The function `customize-save-variable' is an "application" that a user can use to change, i.e., override an option setting. What makes it OK is that the command tells you what it does, and it's up to use whether you use it. > > My standalone minibuffer frame automatically fits > > itself to the minibuffer content, by default. > > > > And Icicles has commands that can provide large > > completion candidates, e.g., a complete sexp or a > > complete doc string. And some such have more than a > > few lines. And when you cycle among candidates the > > current candidate replaces the minibuffer content. > > > > So it's not so uncommon to have multiple-line > > content in the minibuffer. There's nothing wrong > > with allowing such behavior. I don't see why you're > > prescribing or supposing restrictions on the height > > of a minibuffer. That's up to libraries and the > > users who decide to use them. >=20 > Standalone minibuffer frames are not subject to the restrictions cited > above. Their size is constrained only by that of the display screen. Good to hear. But why the restrictions for non-standalone? What I said about Icicles is independent of a standalone minibuffer frame. There are lots of situations under which minibuffer content can reasonably be more than a line or two. I don't see any good reason presented for such restrictions.