From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emphasizing the top of the frame Date: Wed, 26 Oct 2016 17:58:33 +0300 Message-ID: <834m3zupgm.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1477493968 24881 195.159.176.226 (26 Oct 2016 14:59:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 14:59:28 +0000 (UTC) Cc: john@yates-sheets.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 26 16:59:21 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 1bzPfH-0001yp-Oi for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 16:58:51 +0200 Original-Received: from localhost ([::1]:35261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzPfK-0007WN-6I for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 10:58:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzPf5-0007Rt-TK for emacs-devel@gnu.org; Wed, 26 Oct 2016 10:58:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzPf4-0001rq-SZ for emacs-devel@gnu.org; Wed, 26 Oct 2016 10:58:39 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzPf0-0001pB-Eb; Wed, 26 Oct 2016 10:58:34 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2449 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bzPez-0006KC-HW; Wed, 26 Oct 2016 10:58:34 -0400 In-reply-to: <5810BC6B.6020003@gmx.at> (message from martin rudalics on Wed, 26 Oct 2016 16:23:39 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:208845 Archived-At: > Date: Wed, 26 Oct 2016 16:23:39 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org, john@yates-sheets.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. 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. > >> 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? 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. > > 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 functions listed above actually use the 'next' pointer when they walk the 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. 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? > > 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. I thought you were saying that it knew more than that, but the last time I looked at that code was long ago.