unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: John Yates <john@yates-sheets.org>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Emphasizing the top of the frame
Date: Mon, 11 Apr 2022 09:13:52 +0200	[thread overview]
Message-ID: <e8efa482-4ba4-83ab-f063-9872c1b4f7f9@gmx.at> (raw)
In-Reply-To: <CAJnXXojRZhb_ifT3ZqyevV-XioO3DsAP64yY-eqwBh2zK8td_w@mail.gmail.com>

 > 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.

I noticed that your 'resize-mini-frames' function preserves the width of
the frame, something which should be done by default.  But I'm always
reluctant to change established defaults, no matter how silly they are.

 >> 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.

You might consider experiencing with the 'keep-ratio' parameter of the
child frame.  The idea is that if this parameter is t, the child frame
automatically resizes along with its parent.

 >>   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?

I've been confusing you.  My minibuffer in a child frame solution which
is similar to yours lives in a self-contained package I use ever since
Emacs 26.  The "modified version" doing what I sketched above lives in
my local changes to the Emacs redisplay and window management code and
is explained only locally there.

 >> 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.

I meant that when the minibuffer is _not_ on a frame of its own,
resizing it will resize at least one other window on the same frame.
You have to keep this in mind if you want to display, for example, the
minibuffer on the top of a TTY frame.

martin



  reply	other threads:[~2022-04-11  7:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25 17:53 Emphasizing the top of the frame John Yates
2016-10-25 18:04 ` Clément Pit--Claudel
2016-10-25 18:06 ` Drew Adams
2016-10-25 18:27 ` Eli Zaretskii
2016-10-25 18:40   ` Eli Zaretskii
2016-10-26  8:10     ` martin rudalics
2016-10-26 12:00       ` Eli Zaretskii
2016-10-26 12:31         ` martin rudalics
2016-10-26 13:13           ` Eli Zaretskii
2016-10-26 14:23             ` martin rudalics
2016-10-26 14:58               ` Eli Zaretskii
2016-10-26 17:56                 ` martin rudalics
2016-10-26 18:40                   ` Eli Zaretskii
2016-10-26 18:51                     ` Eli Zaretskii
2016-10-26 19:26                       ` Paul Eggert
2016-10-26 20:18                         ` Stefan Monnier
2016-10-27 17:35                     ` martin rudalics
2022-04-08  1:48                       ` John Yates
2022-04-08 15:11                         ` martin rudalics
2022-04-09 14:47                           ` John Yates
2022-04-10  8:42                             ` martin rudalics
2022-04-10 14:50                               ` John Yates
2022-04-11  7:13                                 ` martin rudalics [this message]
2022-04-10 16:23                               ` [External] : " Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e8efa482-4ba4-83ab-f063-9872c1b4f7f9@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=john@yates-sheets.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).