From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: 'struct window' cleanup #3 Date: Wed, 27 Jun 2012 20:24:00 +0300 Message-ID: <83ehp08y8f.fsf@gnu.org> References: <4FE827B6.6020306@yandex.ru> <4FE89369.2000708@gmx.at> <4FE896A9.3090002@yandex.ru> <4FE9643C.1090201@gmx.at> <83a9zq9jhp.fsf@gnu.org> <83lij98nhj.fsf@gnu.org> <4FEAB1EA.3000307@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1340817869 2548 80.91.229.3 (27 Jun 2012 17:24:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2012 17:24:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 27 19:24:28 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SjvyZ-0004U9-Da for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2012 19:24:23 +0200 Original-Received: from localhost ([::1]:49427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjvyZ-0006ld-AA for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2012 13:24:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjvyS-0006cR-UG for emacs-devel@gnu.org; Wed, 27 Jun 2012 13:24:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SjvyM-0006pb-ML for emacs-devel@gnu.org; Wed, 27 Jun 2012 13:24:16 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:40869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjvyM-0006oz-E3 for emacs-devel@gnu.org; Wed, 27 Jun 2012 13:24:10 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M6A00500DJ30T00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Wed, 27 Jun 2012 20:23:46 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M6A005QXDNM0O20@a-mtaout21.012.net.il>; Wed, 27 Jun 2012 20:23:46 +0300 (IDT) In-reply-to: <4FEAB1EA.3000307@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151230 Archived-At: > Date: Wed, 27 Jun 2012 11:10:34 +0400 > From: Dmitry Antipov > CC: emacs-devel@gnu.org > > 1. IIUC, `window_initialized' is redundant and obsolete. Does it still work to run "./temacs -Q", after this change: > - if (window_initialized) > + if (initialized) The reason I ask is because window_initialized was set non-zero in init_window_once, which was called from emacs.c when 'initialized' is zero. So the above 'if' would trigger when 'initialized' was zero, but after your change it will only trigger when 'initialized' is non-zero. Am I missing something? 'initialized' is zero when running un-dumped Emacs, e.g. 'temacs'. > 3. The check: > > && INTEGERP (w->window_end_vpos) > && XFASTINT (w->window_end_vpos) < w->current_matrix->nrows > > is transformed to: > > && w->window_end_vpos > 0 > && w->window_end_vpos < w->current_matrix->nrows I don't think this is right. window_end_vpos is the number of the last glyph row of a glyph matrix, so it can legitimately be zero, when w->current_matrix->nrows is 1. We need to initialize this member with some invalid value, like -1, if we want to distinguish between values we can and cannot trust. Or maybe test window_end_valid here (to put our money where our mouth -- i.e. the commentary -- is ;-). > I never get w->window_end_vpos >= w->current_matrix->nrows Try something that enlarges and then shrinks the minibuffer window. Or maybe split a window on a TTY. Anyway, this does happen. > but run into w->window_end_vpos == 0 several times. See above: it's a legitimate value. > At this moment, I have no ideas whether Gerd was correct about > fixing window.c, so this needs more detailed investigations. My gray hair taught me that Gerd is usually right.