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: Window tree and window's internal height Date: Tue, 20 Nov 2018 18:06:39 +0200 Message-ID: <83va4rivhs.fsf@gnu.org> References: <83o9anuahg.fsf@gnu.org> <5BF06068.60103@gmx.at> <83bm6mtm9l.fsf@gnu.org> <5BF1C03B.2030801@gmx.at> <834lcet9pf.fsf@gnu.org> <5BF2852F.7010400@gmx.at> <838t1okj87.fsf@gnu.org> <5BF3D3B3.9020105@gmx.at> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1542729913 28644 195.159.176.226 (20 Nov 2018 16:05:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Nov 2018 16:05:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 20 17:05:09 2018 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 1gP8WT-0007Kp-5o for ged-emacs-devel@m.gmane.org; Tue, 20 Nov 2018 17:05:09 +0100 Original-Received: from localhost ([::1]:34486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gP8YZ-0004M9-R5 for ged-emacs-devel@m.gmane.org; Tue, 20 Nov 2018 11:07:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gP8Xw-0004Ln-FY for emacs-devel@gnu.org; Tue, 20 Nov 2018 11:06:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gP8Xs-0003Y9-DO for emacs-devel@gnu.org; Tue, 20 Nov 2018 11:06:40 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gP8Xn-0003Mr-9K; Tue, 20 Nov 2018 11:06:32 -0500 Original-Received: from [176.228.60.248] (port=4346 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gP8Xm-000197-Tl; Tue, 20 Nov 2018 11:06:31 -0500 In-reply-to: <5BF3D3B3.9020105@gmx.at> (message from martin rudalics on Tue, 20 Nov 2018 10:28:19 +0100) 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:231251 Archived-At: > Date: Tue, 20 Nov 2018 10:28:19 +0100 > From: martin rudalics > CC: emacs-devel@gnu.org > > > Well, I turned to the manual after becoming disappointed in the > > comments to 'struct window' definition... > > Tell me which ones you find not useful or incomplete and I'll try to > fix them. The next/prev pointers and their relation to the parent pointer and to the 'contents' and pseudo_window_p members. You will see that I already added some details there, but maybe they aren't accurate enough, or you can add more explanations. The original problem was that when I saw this: if (!NILP (w->parent) || WINDOWP (w->contents) || !NILP (w->next) || !NILP (w->prev) I concluded that I didn't have a clear idea what each one of the tests means, and how they differ from the following test from window_wants_mode_line: return ((WINDOW_LEAF_P (w) && !MINI_WINDOW_P (w) && !WINDOW_PSEUDO_P (w) && !EQ (window_mode_line_format, Qnone) && (!NILP (window_mode_line_format) || !NILP (BVAR (XBUFFER (WINDOW_BUFFER (w)), mode_line_format))) && WINDOW_PIXEL_HEIGHT (w) > WINDOW_FRAME_LINE_HEIGHT (w)) > We should also decide what to do with the Object Internals > section of the Elisp manual - update or remove it. I'd do the latter > because IMHO we'll be hardly able to keep it up to date unless we add > rather strong advices to window.h, buffer.h and process.h. Emacs is sometimes accused to be completely devoid of documentation of its internals, something that is said to be an obstacle for people who might otherwise try hacking Emacs on the C level. So I think we should keep the little of the internals documentation we have. We don't (or rather shouldn't) change the internals too frequently, so the maintenance burden isn't supposed to be too heavy. I will fix that chapter soon.