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 16:13:14 +0300 Message-ID: <83bmy7uuc5.fsf@gnu.org> References: <83zilsuvw4.fsf@gnu.org> <83y41cuvak.fsf@gnu.org> <581064F8.5060804@gmx.at> <83funjuxp8.fsf@gnu.org> <5810A216.9080304@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 1477488004 19747 195.159.176.226 (26 Oct 2016 13:20:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 13:20:04 +0000 (UTC) Cc: emacs-devel@gnu.org, john@yates-sheets.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 26 15:19:57 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 1bzO7O-0003G6-4I for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 15:19:46 +0200 Original-Received: from localhost ([::1]:34421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzO7P-00081T-UA for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2016 09:19:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzO19-0004fB-J2 for emacs-devel@gnu.org; Wed, 26 Oct 2016 09:13:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzO14-0008HU-JS for emacs-devel@gnu.org; Wed, 26 Oct 2016 09:13:19 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzO14-0008HQ-Eo; Wed, 26 Oct 2016 09:13:14 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2344 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bzO13-0002lZ-O2; Wed, 26 Oct 2016 09:13:14 -0400 In-reply-to: <5810A216.9080304@gmx.at> (message from martin rudalics on Wed, 26 Oct 2016 14:31:18 +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:208837 Archived-At: > Date: Wed, 26 Oct 2016 14:31:18 +0200 > From: martin rudalics > CC: john@yates-sheets.org, emacs-devel@gnu.org > > >> Does the display engine anywhere rely on that order? > > > > Not that I've seen (by looking at all users of FRAME_MINIBUF_WINDOW), > > I thought about some implicit ordering within the TTY display code. The TTY display code is frame-based, and for a good reason. IOW, it updates the entire frame, not each window separately. > > But doesn't the frame's window tree have to start with the root > > window? If it does, then how do we make the minibuffer window be its > > "prev"? > > 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, so I'm not sure what you mean by "no reliance on prev and next"). > >> Note, however, that enlarging the minibuffer window currently tries to > >> "adjust the trailing edge" of the root window (see that comment in > >> ‘window--resize-root-window-vertically’ > >> > >> ;; When shrinking the root window, emulate an edge drag in order > >> ;; to not resize other windows if we can avoid it (Bug#12419). > >> > >> and the bug mentioned there for why that is important). > > > > And that is at least one implicit dependency on this in the display > > engine. I wonder how many more are there. > > Where do you see an "implicit dependency" here? That AFAIU the display engine knows that it can resize the minibuffer window by moving the lower edge of the root window. > > We probably should have a variable that tells where the minubuffer > > window appears, and code which needs to know needs to examine its > > value. > > An option, yes. Or a special value `top' for the minibuffer frame > parameter. Maybe both. An option is easier to customize than a frame parameter.