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: Thu, 12 Nov 2020 08:58:27 +0100 Message-ID: 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> <22623003-a30e-44f4-b396-97843fe32933@default> 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="39593"; 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 Thu Nov 12 09:03:09 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 1kd7ZV-000A3z-1A for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 09:03:09 +0100 Original-Received: from localhost ([::1]:49378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kd7ZT-0004ih-T1 for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 03:03:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kd7VH-0002bi-U7 for emacs-devel@gnu.org; Thu, 12 Nov 2020 02:58:47 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:57241) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kd7VD-0002kc-7T; Thu, 12 Nov 2020 02:58:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605167909; bh=O9IWmcsy/S/LGe5RDkQ4z/xbNeKdeCSF3c+Q0zdwzhU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=eI1RQQPNv3LuZ2JI30iKqImXDbZxhqmzNyb1S/GHVZ6kioh8z33WHduuRm/wGrgmc ZoLqbirZXXop3cs1mzpOOZBT1vSQnf7xymD14Fc1LK/paRKDTepEGQ5V/MFKelADzU hFTVPiCB0hwR3iASpc3GuiTPExp9vIXyF4IOI8j8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([46.125.249.79]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MryTF-1jyXwm1TDZ-00nvlr; Thu, 12 Nov 2020 08:58:29 +0100 In-Reply-To: <22623003-a30e-44f4-b396-97843fe32933@default> Content-Language: en-US X-Provags-ID: V03:K1:/O/QI+Sm55cxtOnutBOVA3fBvKi3A1lyBeiszvVhEFfKGDIZAEH Mupmw5/CvMWYx6zD7MP54KFuIgV5uvSR62Y1LVdSO/WyVajQtSao5p15EoL4GVQwhbUE+UB xgUn3GtU/0tqxxtIO777Rjiv0BXZcC0EOAEYZibcL3ofucPf1ci0tcJZAQFvEFGNUEBj4sP jcsfWInxq5rkGIIiIu4LA== X-UI-Out-Filterresults: notjunk:1;V03:K0:jLOJ6qdyJkM=:vJzLP6xcxOtnX3LuY/KkHm ByDK0ACliSzd4drmhMIJ4LoXokJpfuY+E9AGKgvp+j5B+4TUEk5TCxrzS5Gdnm/STs1YAjSLR MFaXNqLHSBC6GSExKp+OIbIBH5tYsWi2Gx+SDB/7feGv1RdTdWf9tW9NapC/cxfDpnKdBHIOI Tm4RdBNe8B8e6DsFyDmlphv+i2joyEGDCQXNSqeZzSpYxk2EKEBdFOD1QaNR8Q5+CSntTDtwc +pO656CS8We1Z/Noi7MGuhReYF61fMESqapV9nBNOjgqUsn/rt/jz4PRwf2OLZ6Zy2VU5lx2D lWhL4/g+uPRPYMEQ6NuZG1CAiymKMweOOKCS+DAe5nM8o4Nzcml1CygAIiEtqyx6LZI6XmZxH rDjW/uoS0ixL9cmUAAbqF8vU5OTu7v1zVh9uyJx21dtQZagXPlG0FjexZ1JSNiwvVx74waZq+ iUWGpmkLbKkYVunLHEfSuRtMf6W+X1URtu1PMY/Y5xh2td4jwOmkCEW+bPqxSeCMFitxa/sSI Ao+b2LPCzqEw0sWrwA5pIgJiWkRguw8C6J57RNWUvWKVppWuocb9wc1Fid1QJ9HlB6PM3pjKs 85IuSoIYRCJDqHBoe42GiGdPhoQVMygdoPCj7xXe2ABID1omsuUp0gHQcZRQE1vUfXm4XJ3Gj KR8MuxXx585wFw1mSXlkRUhm87Nj4Q0xSSgTsZjinrYggA0IDfmRhTSeRToF/pkuiWUNaBzwG dFmxFa5N+H7UBm7uwijh8YopfFhbUxNWwCaOgbIgWyFgm4v63wFCL+nx3rr9FfWuzHPQn22p Received-SPF: pass client-ip=212.227.17.22; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/12 02:58:40 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:259061 Archived-At: >> 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. With one subtle distinction: If an application tells me that in order to get a better user experience I should customize a variable in a certain way, I usually trust it. I will trust it even more, if it supports my own previously customized value. But I don't trust an application that tells me that in order to get a better user experience it will make the customizations for me. >> 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. I tacitly assume that standalone minibuffer management obeys any customization of the option 'resize-mini-frames' instead. > 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. The default minibuffer windows work well under fair use. Displaying a few lines of text is OK. Using a quarter of a frame's height can be already troublesome, in particular with small windows present at the frame's bottom. martin