From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Emphasizing the top of the frame Date: Sun, 10 Apr 2022 10:50:35 -0400 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" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35220"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 10 16:54:00 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 1ndYwx-0008yn-5S for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 16:53:59 +0200 Original-Received: from localhost ([::1]:60148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndYwv-0000nK-PV for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 10:53:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52128) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndYtv-0006jr-20 for emacs-devel@gnu.org; Sun, 10 Apr 2022 10:50:52 -0400 Original-Received: from mail-ot1-f44.google.com ([209.85.210.44]:46844) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndYts-0005ir-La for emacs-devel@gnu.org; Sun, 10 Apr 2022 10:50:50 -0400 Original-Received: by mail-ot1-f44.google.com with SMTP id z9-20020a05683020c900b005b22bf41872so9587576otq.13 for ; Sun, 10 Apr 2022 07:50:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GLlQcnelDS3yLsomO1aNxXc/8NsGqfO3KVWEX3yLvBI=; b=Nbg4tf7sVOyQY+1FS53jIcH5r41v9nRk7hboDkos/AFZIWO7dbXpq/A2p94qybaMxZ jjiEwfuMtzRnxBYmBti9MFlu32xV1c9dZyijGsdwt4vx48iuc7XZxJNVh85Lesjm1OYz DE8JP4UG/OyAABxoSVWf19htwtQ+OB0Bw/0fMyLwV5+MTMUZ/L+m9pAOonfpqsnkMM6t smkBXyGbIR8mZ7Xtam45dIFqq03N/5KtGC02aW6TM4gkHdcP+NDJL+6+GA5e6OaMlJxo rTJmKWjzz+dmSiKi7gPy27Freml6r1FHtoDEAZqhisJ2qLr1lDYzx7dxK7hq0imWl6UM VgdA== X-Gm-Message-State: AOAM532gQ6EW6hqhbLRJEr8PyCXWUdGBcT1siBmQl3T+W6RTKUdyCZ/4 UEp/RASNrs1tfsscIBmenj4Ny+xtG66xsooYCLF+wYiE2MZ94g== X-Google-Smtp-Source: ABdhPJxpcFfR9fWVl2u7uFsOig8UIvYK3eMEWpDcmT4pYnvvWFBtznyuPCtABWNdlfYeaA9b1NsATvhIUcEr+m4TEYI= X-Received: by 2002:a05:6830:4121:b0:5c9:4d2b:7364 with SMTP id w33-20020a056830412100b005c94d2b7364mr10099133ott.366.1649602246780; Sun, 10 Apr 2022 07:50:46 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=209.85.210.44; envelope-from=john.yates.sheets@gmail.com; helo=mail-ot1-f44.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:288146 Archived-At: Hi Martin, > 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. Of course. I am doing nothing to the main window. My fundamental shift is to a minbuffer frame that lives near the top of the frame and, when it grows, does so by overlapping portions of topmost windows. Because such behavior violates emacs orthodoxy I feel that I need to present a working example. > 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. So we both are happy with a minibuffer that can overlap portions of the main frame. My version, tries to preserve as much of classic minibuffer behavior as possible. That is why I do not use auto-hide. And if I do not auto hide then I need to find a way to keep the minibuffer visible at all times and, when not expanded, avoid overlapping any important content in the main frame. Which leads to overlaying the menu bar. > 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. Clearly I missed that (but see below). > > --with-pgtk \ > > I think that's the culprit. Thanks. Removed. > Nowadays you could also try overlaying the tabbar. Great suggestion. That menu bar was outside of emacs' managed space, leading me to eschew the child window mechanism. Not so the tab bar! I have switched to overlapping the tab bar and made the minibuffer frame a child of the parent window. A very nice simplification. I set position to (0, 0) at creation and never update again. Plus I removed all vestiges of restacking and hooking move-frame-functions. Finally my two frames move and resize as a unit. > OK. But what would you change in core Emacs? Let me defer answering that question until I have a more complete mockup. > 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. Did you just say that one can position the echo area separate from the minibuffer? Where is that explained? Clearly, your package accommodates many more set-ups than I envision. My goal is to preserve the minibuffer-per-frame model that most users know. (That works for me because I live primarily within a single maximized emacs frame.) > 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. I am not able to make sense of that statement. Are you saying that when a separate minibuffer frame resizes some other window on another frame resizes? I think that I would find such behavior disconcerting. Thanks for multiple very helpful suggestions. /john