From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: john@yates-sheets.org, emacs-devel@gnu.org
Subject: Re: Emphasizing the top of the frame
Date: Wed, 26 Oct 2016 16:23:39 +0200 [thread overview]
Message-ID: <5810BC6B.6020003@gmx.at> (raw)
In-Reply-To: <83bmy7uuc5.fsf@gnu.org>
> The TTY display code is frame-based, and for a good reason. IOW, it
> updates the entire frame, not each window separately.
But for that it (1) has to "walk the window tree as well" and (2) know
where to draw the minibuffer window.
>> Both, a frame's root and minibuffer window, are accessible directly.
>> There is no reliance on the prev and next fields of these windows
>
> There are at least two functions in the display engine that walk the
> window tree,
Which ones are that?
> so I'm not sure what you mean by "no reliance on prev and
> next").
I meant the prev and next fields of the root window and the minibuffer
window. The next field leading from the root window to the minibuffer
window is conceptually redundant - but might be still in use somewhere
as, for example, in ‘window-tree’.
The window tree proper is the tree rooted at the root window. The root
window and the minibuffer window of a "normal" frame do not form a tree
- they have no common ancestor.
> That AFAIU the display engine knows that it can resize the minibuffer
> window by moving the lower edge of the root window.
All the display engine should know is that it can resize the minibuffer
up to a certain extent. Deciding who pays for that operation and to
what extent should be left to the window code. Think of a one line high
window bordering the minibuffer window.
martin
next prev parent reply other threads:[~2016-10-26 14:23 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 [this message]
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
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=5810BC6B.6020003@gmx.at \
--to=rudalics@gmx.at \
--cc=eliz@gnu.org \
--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).