From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Wed, 11 Nov 2020 20:10:22 +0100 Message-ID: <3622f4d2-c27b-eefe-e7fa-7e0fe0dab214@gmx.at> 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; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13227"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew Adams , Andrii Kolomoiets , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 20:15:24 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 1kcvaW-0003Jq-Fi for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 20:15:24 +0100 Original-Received: from localhost ([::1]:49858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcvaV-00065X-34 for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 14:15:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcvVs-0004q4-Ir for emacs-devel@gnu.org; Wed, 11 Nov 2020 14:10:36 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:40469) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcvVq-0002NX-Go; Wed, 11 Nov 2020 14:10:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605121823; bh=fvuD+GCxzVtAd1m+au0tLuvOy/Ebx38fpiXY0iYWfEk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=DIigb1G+nmAZnnegWXE/j3KWtj8eELaErYWuFlRqg8up6ydh1IUOI8/K0e4hvvm0H Mw+uuvpUs10pa/IR04P8GV5f0QjlPhR/a6ocM9fx+aZWG5gwzdTZ9HAG6/U59dOKi1 pQ0fCfwRWRSJWfNDFKE1atiMIp5wfOpQ0dAUGnNY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.34]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N95eJ-1kGniy2sXn-01690f; Wed, 11 Nov 2020 20:10:23 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:Uy2YMElx3u7egzREnIL+0lYu1+1NrV15gQkX/8mpg+ZlE53V7Lc moOmZgh4vQobBSi4a5M2IACOMUlQFEFP6w4ONsmaUr54CI85EW+iPID4KgID+gDWuW8+cws 2jkt6Pdo4gCBm7bsayed0DVxRqF9lfjN+JVPXeLe8zTOUTyRpplo6jtDnP0uY5+akQfgc40 xrAzpbSX59ML2Ube9W8lQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:kYPzQ7DIWwM=:ifbTlxbNcnuFMg4EJLGWpZ UKcUR6SnxaITalClgoN8k3OAIiINfYBzH7EPMK8SgAIt0vtJO7XVhMYipLVrKry12PeXNPXHr Z5HcL++muCAbgLfrWu9ZIMNp5D9l9UABgVP/tpJDZiUGXD5CiD2jruO5Svy1kiWlXYzOd5cym 48PptKbGk+toYbaDB/Vc1NvYYgDmOiEgcUtwA9RGC9RjmDIV3gWHPiMeNNy5wsKhvQ/n492c6 DdQ91n5WCofZxvNKQKhPOjN45DfPArlkm7ROidaq6hzVomM6VxxASywN93087Kos37Pyzo/vK mXPoflng+Arx2QVRQYgAhsXcCydfrV3Qi7RJqbCQqQSaUu1JFssZ7vUomA2VLYc/Qg0SqzTPn b18kezgve+RV4oGbfRtn3NNYPhBHwxmMTsh04foVpAw4qKi7mQq4JUQANr2AXZKwlqdg2/+O1 4cq9yYz7EZ97Q/tpOqyoT/lJ9gi0QpQcrmxdSU6rq7vGJ2ljvTOH3uO8OjlkiOSO5VnEaWdBf wdndHWhy9UVDn6lyqrGzdV7sBINsUz+IRWwWEd8GYD3XTpp33AsmtG2i4zEdUlj+xzspzoDXy P8dJgJAq/48SN3CSPSNQ5RwR3mYmGw3R9d90qR8W7fuTiSMiCmHKgPs5nVczabNJRPumUtpQu QsLFQALS7DKVBhyjcJ3CGEPi+tVA9ypN5DJBoRLxGSBKhRd51KC4XtlX3OTvhXMpqZX90i+P8 Ir7KAVnbuy3YZ23ketwbZTlJAj0u3pV3uHsLyuxiqDugZrtv/ceNtQ9lebGmKyK+ZduZXt93 Received-SPF: pass client-ip=212.227.17.21; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/11 12:15:09 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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:259044 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. 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. > 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. Standalone minibuffer frames are not subject to the restrictions cited above. Their size is constrained only by that of the display screen. martin