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: Sat, 9 Apr 2022 10:47:51 -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="29104"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Emacs developers To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 09 16:49:23 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 1ndCOx-0007T4-Na for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 16:49:23 +0200 Original-Received: from localhost ([::1]:51498 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndCOw-0003Zc-8A for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Apr 2022 10:49:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndCNi-0002s9-3E for emacs-devel@gnu.org; Sat, 09 Apr 2022 10:48:06 -0400 Original-Received: from mail-oa1-f45.google.com ([209.85.160.45]:42485) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndCNg-0004lJ-6N; Sat, 09 Apr 2022 10:48:05 -0400 Original-Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-de3ca1efbaso12652702fac.9; Sat, 09 Apr 2022 07:48:03 -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=lyO+2vpL/S9nu/YlBUTMzlpcR+413LBlQ/YxnxO7+lg=; b=qiPWUKcIyLU4MderEPmJ5luGLOCo9q6DkR6rdUKQi+AAH9kKA1AqEB7uLHeIEefV/H BRGDWadI6UsynQEWK2bmfiD89bKbah/GH/33pGdGcSov2TLkTqk7J1Z4Is1G5XXj3eTd gku0KCjE5YfSK1bZ6+IxyrFKiChI3PyWM1MH86meYAUyLCVdAcwgJifOb3dYdf/ta1Fw uEyvG1O+z39b6tU2WVZdUHGhLLHq+eZ34oYaEZwcBSMGyxztAWOC7ZmyVcyKbk/I4eVB P4mfMZjBUaOxrVY6RI+mraD0dpP/sEKj0GAJl/WxZtDePLFgB7OkawDXv9sOQ3QBaMgw /1kw== X-Gm-Message-State: AOAM533xXFwxu93t75RP3r4ztoXfINvKfco/6aqBuaJdL2HRQ668lDUT E1SpkX3aF6fmaTGlmH6f5tvR7YyoQ5EfLm8i14u5NcYOxZ1eJw== X-Google-Smtp-Source: ABdhPJxYFwiX9ooFfcsQ3f75+mFG7XRUXou41tm5jOVy9twQUmYOf0gNnj2AWlZ/qXljlVtuJyz+Xz04dxquiO4VMxU= X-Received: by 2002:a05:6870:f104:b0:da:b3f:2b62 with SMTP id k4-20020a056870f10400b000da0b3f2b62mr10758375oac.257.1649515682418; Sat, 09 Apr 2022 07:48:02 -0700 (PDT) In-Reply-To: <947c9703-596b-fdc4-6170-2f0fb7386f6d@gmx.at> Received-SPF: pass client-ip=209.85.160.45; envelope-from=john.yates.sheets@gmail.com; helo=mail-oa1-f45.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:288029 Archived-At: Hi Martin, Hi Martin, I failed to make this obvious in my previous post, but I have two agendas: * Make my own life tolerable on my 42" screen at work * Provide a sufficiently complete mockup of a top-focused emacs that I can trigger some interest in making such a mode part of the core I envision three components to such a mockup: * Demonstrate that a minibuffer at the top need not imply all of the rework that would be necessary to support frame relayout on minibuffer expansion * Demonstrate mode-lines at the top of windows * Convince maintainers of some key minibuffer interaction packages to support downward growth (more below) > BTW, your minibuffer > frames grows downw 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. > I'm using a minibuffer child frame based on that principle for several > years now and it rarely has let me down so far. 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. 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. > > * Management of the z-axis is not great; frame > > restacking triggers an error on my Ubuntu box > > Which error? I solved this one... 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. (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 \ --prefix=/usr/local/emacs \ --program-transform-name='s/^ctags$/ctags.emacs/' \ --disable-year2038 \ --disable-acl \ --with-modules \ --with-json \ --with-file-notification \ --with-native-compilation \ --with-xwidgets \ --with-pgtk \ >/tmp/config > > * Occasionally the echo area enters a rapidly > > flashing state; sufficient ^g tend to clear it > > I have never seen such behavior here. If you do not directly interact > with the minibuffer in such a situation, it might depend on some minor > mode like eldoc-mode enabled (I don't show eldoc in the echo area). Ah. Yes. eldoc-mode. Will disable that. > You waste cycles updating the menubar, though. At home and at work I have a hunky desktop. I do not observe any impact from menubar updates. > Have you ever tried > putting the minibuffer frame on top of the title bar? Yes I have. The subjective experience was less pleasant as my emacs frame(s) diverged visibly from the ui conventions. 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. > > 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. /john