From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Emphasizing the top of the frame Date: Wed, 26 Oct 2016 19:56:07 +0200 Message-ID: <5810EE37.70703@gmx.at> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1477504625 3327 195.159.176.226 (26 Oct 2016 17:57:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 17:57:05 +0000 (UTC) Cc: emacs-devel@gnu.org, john@yates-sheets.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 26 19:57:01 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzSRL-00061S-6x for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 19:56:39 +0200 Original-Received: from localhost ([::1]:36484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzSRN-0002Pt-KG for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 13:56:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzSRC-0002Oj-Nl for emacs-devel@gnu.org; Wed, 26 Oct 2016 13:56:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzSR9-00034M-Ma for emacs-devel@gnu.org; Wed, 26 Oct 2016 13:56:30 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:62956) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bzSR9-00034E-DC; Wed, 26 Oct 2016 13:56:27 -0400 Original-Received: from [192.168.1.101] ([212.95.7.115]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZD0K-1cKH4o2ycu-00KuDj; Wed, 26 Oct 2016 19:56:18 +0200 In-Reply-To: <834m3zupgm.fsf@gnu.org> X-Provags-ID: V03:K0:q+qWp870wcGOAQssrBalv2LtgRrELhuWH27PKegdDmZl2TIb5Fd U+IDi0adCSTzbYz9ZQU4483Y7APzBnTI3AvYejYifpaVfRRsk9rd7re9GpZ1s8PZpd//wmT 75qKLGSHid8gp4kl2FiDM6CPuMQXod99633zoxIJy5e+krHwB/m8kMiCPif+7nAYDIKXVGE AlhMxCXL1rMIKHP/OHDsQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Gov9ioHTk0c=:0dzYdeHux7HQevUv+KIvo/ vUhLLlXduGL30QALLButajaNm5jlM9D9kAwZ2Br+TnAlA6DUB0jSv8iv4eVS83OHRjsnjt1Mf do6ukVe1ncJc7f5WLEPOYbb6ZoAOrvfn3ekyB6W76DebzhY6ipZuEhQ8R13dtKUOSvaYjUoJT SUsxcCEf7zu5oAsJ5L/q7DYpzLr1HIBHMRHrW3/NX3BoAoWsUp6yXdIvXSH0Fi0jUROMVURAH vDWIM2cCZI9GfAW9G8WBaTEg8l81fVXMb8WtM57hoSC3mgJLnR7cFg+bV/hwF1g6/D8huQNc+ Y9f+ArbwuQgKIlUL44V/05JEAXjAyOXgExROimGUe/vGu2MukyMjAdvTItTmOR6yjr5iLxyU7 991hgmQgPqDY67lvKW3rIsSlGrKU03/qp1nXsX70kelz1Uq4s8lktvCKyi8FxxNtuZ//e1AK5 caV8S4VyVSlorY2/tEn8NT7JswiWp5sx8MPS6zJJNFlMl1+PqUmdvJp7/Gku+wX/h5xpc0UiX lhZm4u7O867JiBUVrKSIGXgt7AKske+oDdm3mhUj4SDLnGk1REr8Io5vztUs8ZiwhbwL30LAj ARxsZsFy2CPwCI4bfjX9gcpKSuSZEocAA9Muiz5SbTvXZ/QdVlcLsKNr0XCwcOnE6+QVMwbJP In8f/prUJ/hxfAON38KNG8jLrav2yPndqTbjqe/wLwA5WEenikH3m7Am8FWZLRspw8adDDllp k/Q7OhYtwZI72hojggPaY1GJQWkl/+u5ycp/GQ7Qni5F/FwdK7oW671vYpH1T+K5zBX3QOJV X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208847 Archived-At: >> But for that it (1) has to "walk the window tree as well" and (2) know >> where to draw the minibuffer window. > > No, it doesn't. The window glyph matrices on TTY frames are actually > portions of the frame glyph matrix, so whenever a window's glyphs are > updated by xdisp.c, the corresponding glyphs of the frame are > automagically updated as well. Looks like changing the minibuffer position is harder for TTY frames. >> > There are at least two functions in the display engine that walk the >> > window tree, >> >> Which ones are that? > > redisplay_windows and hscroll_window_tree. I now see that so do > mark_window_display_accurate, redisplay_mode_lines, > update_cursor_in_window_tree, and expose_window_tree. As a matter of fact, there are a few more in window.c - foreach_window, mark_window_cursors_off, window_set_before_size_change_sizes, window_size_changed and get_leaf_windows. So I suppose that John should try hard to _not_ change the relative order of the root and minibuffer window and hope that interchanging the coordinates (something he has to do anyway) will suffice. >> 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. > > Maybe I'm missing something, but there's this fragment in make_frame: > > root_window = make_window (); > rw = XWINDOW (root_window); > if (mini_p) > { > mini_window = make_window (); > mw = XWINDOW (mini_window); > wset_next (rw, mini_window); > wset_prev (mw, root_window); > mw->mini = 1; > wset_frame (mw, frame); > fset_minibuffer_window (f, mini_window); > store_frame_param (f, Qminibuffer, Qt); > } > > This seems to arrange for the minibuffer window to be the "next" of > the root window, no? Yes. The root of the next tree, as it were. Obviously, this next field is convenient for walking the structure formed by the root tree and the minibuffer window as your examples from the display engine show. martin