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 #2 Date: Wed, 27 Jun 2012 19:59:25 +0300 Message-ID: <83fw9g8zde.fsf@gnu.org> References: <4FE827B6.6020306@yandex.ru> <4FE89369.2000708@gmx.at> <4FE896A9.3090002@yandex.ru> <4FE9643C.1090201@gmx.at> <83a9zq9jhp.fsf@gnu.org> <4FEAB0FD.9050409@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1340816374 22356 80.91.229.3 (27 Jun 2012 16:59:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2012 16:59:34 +0000 (UTC) Cc: dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 27 18:59:31 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 1SjvaR-00035x-VY for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2012 18:59:28 +0200 Original-Received: from localhost ([::1]:39813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjvaS-0000SD-2P for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2012 12:59:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjvaK-0000S8-VY for emacs-devel@gnu.org; Wed, 27 Jun 2012 12:59:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SjvaF-0001y6-6Y for emacs-devel@gnu.org; Wed, 27 Jun 2012 12:59:20 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:38229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjvaE-0001xa-UT for emacs-devel@gnu.org; Wed, 27 Jun 2012 12:59:15 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M6A00400C7CVV00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Wed, 27 Jun 2012 19:59:12 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M6A004I5CINQU80@a-mtaout21.012.net.il>; Wed, 27 Jun 2012 19:59:12 +0300 (IDT) In-reply-to: <4FEAB0FD.9050409@gmx.at> 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:151227 Archived-At: > Date: Wed, 27 Jun 2012 09:06:37 +0200 > From: martin rudalics > CC: dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > Why a "hack"? Lisp object are good precisely for this reason: that > > you can give them values of different types of object. > > window_end_valid is documented as > > /* t if window_end_pos is truly valid. > This is nil if nontrivial redisplay is preempted > since in that case the frame image that window_end_pos > did not get onto the frame. */ > Lisp_Object window_end_valid; > > but the code in xdisp.c checks it usually just as > > !NILP (w->window_end_valid) > > Consequently, the assignment > > w->window_end_valid = w->buffer; > > looks fragile (one has to be sure that the NILP checks don't happen > while it's set to the buffer since otherwise we end up trying again for > no use) and at least contradicts the initial comment of try_window_id > > /* Try to redisplay window W by reusing its existing display. W's > current matrix must be up to date when this function is called, > i.e. window_end_valid must not be nil. > > but apparently the current matrix is not up to date when the value is > non-nil but some other buffer. So unless this is better documented > and/or the corresponding code cleaned up it remains a "hack" IMHO. What you see happens a lot in Emacs sources: comments don't correspond to what the code really does, and tell only part of the story. Usually, someone changes the code, but fails to update the comments (because these comments are in another file, where the struct is defined, not where the change is being done). I tripped on such issues several times when working on display features (in conjunction with the various flags and state variables in 'struct it'). That's why I asked Dmitry to update and improve the comments whenever some variable or struct member is being updated/modified. > >> Can you see whether the part > >> > >> /* When splitting windows or for new windows, it happens that > >> redisplay is called with a nil window_end_vpos or one being > >> larger than the window. This should really be fixed in > >> window.c. I don't have this on my list, now, so we do > >> approximately the same as the old redisplay code. --gerd. */ > >> && INTEGERP (w->window_end_vpos) > >> > >> in xdisp.c still makes sense? > > > > No, there's no code anymore that sets it to nil. > > Fine (apparently that was another "hack" in redisplay). No, it's another instance of "change-code-but-don't-update-comments" phenomenon.