From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Minibuffer positioned at a location other than the bottom of the frame? Date: Mon, 27 Nov 2017 09:49:46 +0100 Message-ID: <5A1BD1AA.80506@gmx.at> References: <5A13F19A.9000502@gmx.at> <83fu97d43z.fsf@gnu.org> <838teu8hu7.fsf@gnu.org> <5A1A96C5.1040203@gmx.at> <83efol6nbo.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1511772673 2378 195.159.176.226 (27 Nov 2017 08:51:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Nov 2017 08:51:13 +0000 (UTC) Cc: emacs-devel@gnu.org, zhenya1007@gmail.com, john@yates-sheets.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 27 09:51:09 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJF80-00085t-2L for ged-emacs-devel@m.gmane.org; Mon, 27 Nov 2017 09:51:00 +0100 Original-Received: from localhost ([::1]:59759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJF87-0006L5-7g for ged-emacs-devel@m.gmane.org; Mon, 27 Nov 2017 03:51:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJF75-00062O-Bz for emacs-devel@gnu.org; Mon, 27 Nov 2017 03:50:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJF72-0008S5-9k for emacs-devel@gnu.org; Mon, 27 Nov 2017 03:50:03 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:60034) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eJF71-0008Rp-VZ; Mon, 27 Nov 2017 03:50:00 -0500 Original-Received: from [192.168.1.100] ([46.125.250.81]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M4jbN-1f43Ku0VYb-00z0tA; Mon, 27 Nov 2017 09:49:53 +0100 In-Reply-To: <83efol6nbo.fsf@gnu.org> X-Provags-ID: V03:K0:45YE8YIYsW7g0ahjmxONurBFVQZXsLxKNq/gndnrm/uQ441jpYy 5z+JfzDoP7kvsnuPCtC5PTEKymqzswZigi/HP4tHQ7ydOst300JmOX49YAXOKs6DGnkqM7m 7TNpB6H54TOwuiK7m6spQzTTITus/Iefgzu4UWDN/zFTYVKBBTP62r+u6t1e288rddhtriI 8sXLqRhiSzuFMoMMTZAIQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:3iL2XJSGW4o=:XYzfyiJpKSGbjZIn+qDes2 V02BG25un5EVwjHpEU+3uEImLs/IBDzCdVDd6vFKVTiMQOUDo1OWFxMYODxXZhtup6SiKsp6c 1udIcG9IXptwwG1Y0Y4eRjcrk0KwhmCZYRco6z1JK1DIRnYnvuXRdYTrBk99c/aDlqP8DGzXx 1jMdM3UDhcBNZMxoT8ZhNSvK9HBolrSBw6bEnUevgg1NU3AsnE+8BS3c7AVUwQvpbQLTXBQMy qpbwc3unbySLrlcr5tD5dcNNiPAhiEYPnMG+NTqDRNsTl0yD8a35jVna8t6mOVaSxZ+nPVdBs U3JdiDe0SqmSxwIQ7Hm1G1LMTjJWUzEZTFMErBEi90o+S3xngPe5nW4rTx218qfxXPahdHGwl N518VBwTPGuNiddXF9vGHimjxBBkU0FKr5e6iS900YrStGYzXQ6NmlpkQC1RrobWejpUhJfq0 KcG4P6pQZBKCvt52UtSQdH8wa35xWYjU6rNBjak1SC3cO7LxNuSZ4xdrXsvJzvR+yJ1WYJHdU toTT+kibZ3MS2RcEJCtHKmu1WDBelAdHCbuX5MjawfJVScolCU5WM/vjtglsWTquptpKvUQWY K7cnPVcJkioxPwWowoBECJEJ/27CrZp6ud9UUC92z/IQjbnxqfsaDF9sISjqwyrPkhGOH3Im/ s0NL0pP4DEu/y1T+H+t59oPrqUV9BPnXvLNiyuXBTCFjyKXAGpgTK2F3IqFwMGELviNFAKQK8 aE4eOh78G1Mivnfg8GotRsUn0sm5IRDg9tJXAFU3LinwXvSt7HIz0LXTPoq6gA77ZqJDi1h1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220478 Archived-At: >> I doubt that "Positioning the minibuffer to the top of the frame" would >> be "much easier" > > "Much easier" than positioning it dynamically below the selected > window, or some other dynamic positioning. I'm sure you will agree. Logistically, yes. But not when it comes to handling the visual appearance. I recall that I once tried to resize a frame's windows proportionally when resizing the echo area. You were not amused. >> When Emacs enlarges the minibuffer window it then has >> to move all windows beneath down by the number of lines the minibuffer >> window has been enlarged. > > Why "all"? why not just the next window below the minibuffer? That's > what we do now: we resize only the window immediately above the > minibuffer. Right? When you have two side-by-side windows on the top of a frame you have to resize them both. Just as we do now when there are two side-by-side windows right above the echo area. If such windows have fixed height or are too small, we have to resize other windows as well. >> To not make these windows' texts move down >> accordingly (which would constitute a very unpleasent visual experience) >> we would have to try to change these windows' start positions and >> restore them accordingly when shrinking the minibuffer window back. > > That's probably true, but we need to redisplay that window anyway, so > we can choose a different window-start while we are at that. But there's a great visual difference when the entire contents of a window move on screen instead of when just some of its bottom lines get hidden or revealed. >> Obviously, with point near the top of the window or varying line heights >> such an attempt might become very tricky or even impossible. > > I don't see why it would be impossible. To keep the text exactly in place, we would possibly have to start a window with a partly obscured line. IIUC we could do that but there are no functions for it (have the iterator step backward, calculate how much to show of the first line of a window). So it's "impossible" with our current means. > And in any case, this will be > an opt-in feature, so those who don't like the result will not use it. > >> Putting the minibuffer window below some arbitrary (maybe even internal) >> window of a frame would not run into such difficulties. > > I'm okay with that as well, if someone figures out how to implement > it. A first step would be to allow not showing echo area and minibuffer at all and, in case of a user interaction, show them just in the selected window or on a separate frame as a fallback. And, obviously, create a minibuffer window on the fly whenever and wherever it's needed. Note that while some comments in our sources still consider it vital that the minibuffer window is always visible, in practice this has no importance since you can always shrink a frame to its title bar (which for a GUI might be the most convenient position for showing echo area and minibuffer anyway). martin