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:03:59 -0800 (PST) Message-ID: References: <> <<20201105235735.oxouuek66ehu5o45@Ergus>> <> <<20201106151541.dpgep7borlja25su@Ergus>> <> <<837dqv5huk.fsf@gnu.org>> <> <<83mtzp2qj0.fsf@gnu.org>> <> <<83r1p11369.fsf@gnu.org>> <> <> <> <> <<837dqr27zs.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8894"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii , martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 20:05:14 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 1kcvQg-0002BA-AB for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 20:05:14 +0100 Original-Received: from localhost ([::1]:45762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcvQf-0003Jm-Bn for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 14:05:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcvPf-0002oH-Gz for emacs-devel@gnu.org; Wed, 11 Nov 2020 14:04:11 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:45960) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcvPd-0008M8-ES; Wed, 11 Nov 2020 14:04:11 -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 0ABItLQU098667; Wed, 11 Nov 2020 19:04:02 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=kBCSU2WQMIf/dIFg/0tkhw+g5DlUV/a3sUWkdsCKSjo=; b=cjiADv9jI8SK23SyrAP1xwUtkuY54XufpdQYKitBwySwNdTqthwQHZR2UGlu4g5JSHei Cpl8TaDDZImmvQfetRNF2frGaXJx+Hrax5rSlcTDXxJ3JRnMUuK0laUHzjXWYWKBkSfg jrMwt88XBCGYy586K1zAHPQHGFZkz5KcyJ8zPdXje2OeJGjtGvGO/sloSHko8WNYeqSb 5eFZmaKHpRBpOJJgMfFo1eZEqJE9S7+hLKKsAaAsYQ4ZkbsQS5DMdXzGkLma2vtJYjoY xdtbkFgVugBeRZHeTx6loZsuDwuNs7lKXuWdiZgp5AYwUT1Lr0IilwRa+09vK9Dypxnr 6w== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 34p72erduf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Nov 2020 19:04:02 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0ABItGTu031865; Wed, 11 Nov 2020 19:04:01 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 34p55qad26-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Nov 2020 19:04:01 +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 0ABJ40TO027010; Wed, 11 Nov 2020 19:04:00 GMT In-Reply-To: <<837dqr27zs.fsf@gnu.org>> 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 adultscore=0 spamscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011110110 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-2011110110 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:259042 Archived-At: > Emacs's minibuffer input was not > designed for showing too many completion candidates, let alone show > them vertically arranged. It was even less designed to display the > candidates or other hints in overlays. Maybe so. What the creator originally had in mind was designed in the terminal-only days, back in the Dark Ages. I'd say too that minibuffer content and height is not only about showing multiple completion candidates, i.e., what Ido, Icomplete, and similar do. In my use, the minibuffer only shows one completion candidate. But that candidate can be multiple lines of text. Your point should be, I think, that it's about the size of what is displayed in the minibuffer, regardless of what is displayed there or how (text or overlay, for example). Your apparent assumption that the issue is only about showing multiple candidates, and hence your comments about implementing combo-boxes etc., may be warranted in the context of only this thread, which is about Icomplete. But the general issue of minibuffer size is, well more general. In any case, I think that the Emacs minibuffer should be able to handle pretty much arbitrary text, overlays, etc. - just what other buffers can handle. How such things get displayed can be up to the code that handles displaying it, and it need not be handled well by vanilla Emacs by default. But the minibuffer should allow libraries and user code to handle large content.