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 10:52:54 -0800 (PST) Message-ID: References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.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="978"; 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 19:54:31 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 1kcvGI-0000AN-UA for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 19:54:30 +0100 Original-Received: from localhost ([::1]:42280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcvGH-0000ez-Vg for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 13:54:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcvEx-00086K-Fv for emacs-devel@gnu.org; Wed, 11 Nov 2020 13:53:08 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:38024) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcvEu-0004OQ-Pi; Wed, 11 Nov 2020 13:53:07 -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 0ABIZQD3067208; Wed, 11 Nov 2020 18:52:57 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=0eLTWGpT/MP6LaJV9IrorDXoBSDRKP2mKVb1rl+/6g0=; b=jQT44VH9NUXnX6+Cc6OF7n804Ar2U7MpYHkXB7ltZVMnJv7z1opJXv3D1PVGrOvAWYNP SLtWXhvbKZzYtj/ujVqpzLa33jEDseWIvfPuht7CEXYIrux3fzQEvvvU0TpsdVfDEUJZ 6SCcOegA3du867nsG2zQB55HyNLxuzZuquUSlUeF2oUs+i5FjEVgIcw41aCHdPP996/0 raUdbgh9by9wOVwsQanxqkZzKPp6yjw1bMO8qQYtnIxtp3FxcApfAxwmMfL7Mt4Z+b4t 8KdotWrM8Hqf4gptbGZ/sfcurWGkgOTsv4afve/teT6B62XJqUostCG72O+hlp6l8MUu iw== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 34p72ercxj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Nov 2020 18:52:57 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0ABIaB04139508; Wed, 11 Nov 2020 18:52:57 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 34rmt3hgt2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Nov 2020 18:52:57 +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 0ABIqtMC020646; Wed, 11 Nov 2020 18:52:55 GMT In-Reply-To: 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 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 mlxlogscore=765 mlxscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011110109 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=789 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-2011110109 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:259041 Archived-At: > Applications have to accept that users want their minibuffer > windows to show just one line. Or at most two lines. Or three ... Huh? Why do you think that? 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. ___ FWIW: 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.