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: Emphasizing the top of the frame Date: Sun, 10 Apr 2022 10:42:23 +0200 Message-ID: References: <83zilsuvw4.fsf@gnu.org> <83y41cuvak.fsf@gnu.org> <581064F8.5060804@gmx.at> <83funjuxp8.fsf@gnu.org> <5810A216.9080304@gmx.at> <83bmy7uuc5.fsf@gnu.org> <5810BC6B.6020003@gmx.at> <834m3zupgm.fsf@gnu.org> <5810EE37.70703@gmx.at> <83shrjt0lt.fsf@gnu.org> <58123AE1.8080804@gmx.at> <947c9703-596b-fdc4-6170-2f0fb7386f6d@gmx.at> 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="20549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Emacs developers To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 10 10:43:44 2022 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 1ndTAc-0005BG-Vx for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 10:43:43 +0200 Original-Received: from localhost ([::1]:33818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndTAb-0004f8-Id for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 04:43:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndT9U-0003yL-HY for emacs-devel@gnu.org; Sun, 10 Apr 2022 04:42:32 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:58347) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndT9S-0008Rd-E7; Sun, 10 Apr 2022 04:42:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1649580144; bh=xaAIwM6Sq2ttCUi2aG2bqn/Ye5rjaXj0TIMp3dY0ePo=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=S19il+nZ8mIrEHhWPoOq5TUTIyL/v++wqQXlpXuUzKEeq+YORTwSrpLZ+Zf3rhxY6 AjF322lhNxvguy0pKaRxl5hGOjduw3pirKVPXnTn2TTdnChzqL+pq4b/xIZalWQC55 DFK3EfyIGw0/oU99fUXMKKULjxN/iF8DYzNq5Q6U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([213.142.96.238]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Md6Qr-1oCG4R1pBL-00aDXo; Sun, 10 Apr 2022 10:42:24 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:QxCpCpKHlhq/q1LCXax3wCZwrutzWClEXT9Fx7VNAAjMlVHvivu 9v88Nks+CvXWxv/FAmqH/kNCOxuKwWKBVUnPfB4aGBqZkruL6a0XK9E3WmDT9GH/lk4nH2x 00QWmbauFwElEhcg8/6uFfdB7fDDo4/utjszvG2l5gBOdP4dlpWcRa50gDhjvfOluAhtgkJ ayhtTeCe4qfqE7HCC7Mjg== X-UI-Out-Filterresults: notjunk:1;V03:K0:2ORDlP7Sbqc=:KWbg6cJ+6+RuouIsIQMs8V b0t0YByyIT73dBx6tfi18JCpamF1L/XtPAqz/o4y+iKfnCtcgdf/yHcT4khBj6qzg+BQ7zo7I 13QzM1HTbWDQcj06LKp+D1g842QNxO+cywHF1opJVUSN58lUxrs7jlm7DWHAr9j3UCV0c3WTB uJXWnYl5/3uGsRzWKqy0h5ieK++E2TZ5lA8XsyugbPU3xfIybPj2inX91SC0Cl0bXdKjqe61C pPgER3XyF7tgyoRoVJlZzXvK43sCPmRDRmgxrSPz18WoMdnsbBVS/KHLtPbK36WWJlmyRAy8v euAA/i4lET4+qOzV3zUQxmfHu90c0WTeV4uUyGZ0ayV058SP4JSdnRZicos1oxOqHTZeDqRbE O0HCk6Em2a89pMHFSPeO61ruujQg5reNqsIjD2Y1PNOiMjQdv0vCwAAiko9lo/w9mJEKaEaMO zlMjOplmKnAbJlOyiiXIB4GTtOQ5sraHEV767n0slBBe8IeRycg8lP30YYCLMm3u3Qrh6o75B HIQXvxNYAnGfrOVUkc7g02gwOSNLJ4ejpZT7rC8OrlqposSjBphi/Jot1eQ5UEDscBHtWtmW9 n4SOe6aslv57I6Ka+1y1AiZec48tcpxJvvceY++37jlHzJVsFJASoyNS8u6e/zrXaLUmA5TBd 39mljV/Mjq2+8DnGehx5mMKwf3N3BmseP3x7Uyi/sEg7p32gPYBb4xhZPXY7RKLENvt4FgXz8 yFv/Qg2pgvBfBywAbGYtU2N9o7nAQZp5CZhsgaSBwm1BlAOBFt4K4/SiFhgcVp0wI0XbaZbR Received-SPF: pass client-ip=212.227.15.18; envelope-from=rudalics@gmx.at; helo=mout.gmx.net 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:288118 Archived-At: > Indeed. And I like it. Except that some packages assume > upward growth and so position the prompt at the bottom of > the frame, whereas in my case the more natural position > would be at the top. Please don't ignore one important design principle here: The windows within an Emacs frame, including the minibuffer window, do not overlap. Hence, enlarging one window inevitably will shrink another window. If you want overlapping windows, you have to use child frames. > I suspect that if I used a child frame then at least some > of the glitches that I encounter would disappear. The > reason that I cannot use a child frame is that doing so > constrains the minibuffer frame to reside within the space > managed by emacs. As such it would be guaranteed to > hide something. Right. But IIUC your minibuffer frame also hides the menubar and, when it grows (downwards), will hide other parts on top of the Emacs frame too. And didn't you claim initially that hiding is a feasible strategy, something on which I agree because I do it myself. > It is interesting that you mention that your separate > minibuffer frame "rarely has let [you] down". From > that I conclude that you too know that the separate > minibuffer experience is not as polished as that with > a traditional minibuffer. It is occasionally problematic when switching focus between two or more normal frames and a minibuffer interaction is going on and when trying to quit the minibuffer. And since my minibuffer frame auto-hides when I don't need it, I have to turn off all sorts of things Emacs wants to show in the echo area that I never want to see. > To avoid visible flashing and resizing during frame > creation, I initially marked the frame invisible, making > it visible at the last moment once all setup was done. > Part of the setup was an attempt to get the main and > the minibuffer frames into a proper stacking relationship. > It took a night's sleep and a shower for me to realize > that perhaps restacking an invisible frame might not > be supported. The Elisp manual warns that Note that the effect of restacking will only hold as long as neither of the involved frames is iconified or made invisible. so you have to restack the minibuffer window also, for example, after you deiconified the underlying normal frame. This is a problem child frames solve automagically. > (I am a C++ compiler writer by trade > and gui concepts are quite foreign. I am having to > learn as I go. :-) > >> (add-hook >> 'move-frame-functions >> (lambda (frame) >> (message "Frame %s moved to %s" frame (frame-position frame)))) >> >> If you don't see them, please tell us which toolkit and window manager >> you use. > > I had tried essentially that same experiment on my > own. Just to be sure, I retried with your text verbatim. > Nothing shows up in *Messages*, neither with my > init.el loaded nor when I run emacs -Q. > > I am on vanilla Ubuntu 21.10. > I build emacs regularly from the tip thusly: > > ./configure \ [...] > --with-pgtk \ I think that's the culprit. You should use --with-pgtk if and only if you use the Wayland backend. If the problem persists even with a normal X build, then the window manager might interfere. [...] > As I stated earlier, one goal is to demonstrate an > attractive layout and experience. Were this part > of core emacs, a minibuffer at the top of the frame > would never overlay the title bar. Overlaying the > menubar, by contrast, places the minibuffer visually > in a very natural position. Nowadays you could also try overlaying the tabbar. >> > I hope that the existence of mbmb prompts owners >> > of minibuffer-resizing packages to support growth >> > downward in addition to today's growth upward. >> > (Could we standardize a frame parameter to record >> > this direction?) >> >> Do you mean we should resize the frame whenever the minibuffer window >> changes size? That sounds hardly feasible. > > No. Not at all. I mean various packages assume > that, in a multi-line minibuffer layout, the persistent > minibuffer line is at the bottom and any additional > space has been added above. Similarly, there are > packages that assume adjacency of the minibuffer > and the completions buffer is achieved by having > the completions buffer sit above the minibuffer. OK. But what would you change in core Emacs? My own modified version of Emacs can show minibuffer and/or echo area combined/separately on bottom and/or top of a frame or in an arbitrary window and hide them away when they are empty. The one restriction that remains is the one I cited on top of my mail - resizing any of these windows will resize at least one other window. martin