From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: 'struct window' cleanup #2 Date: Wed, 27 Jun 2012 09:06:37 +0200 Message-ID: <4FEAB0FD.9050409@gmx.at> References: <4FE827B6.6020306@yandex.ru> <4FE89369.2000708@gmx.at> <4FE896A9.3090002@yandex.ru> <4FE9643C.1090201@gmx.at> <83a9zq9jhp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1340780820 11628 80.91.229.3 (27 Jun 2012 07:07:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2012 07:07:00 +0000 (UTC) Cc: dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 27 09:06:57 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 1SjmL0-0004FM-42 for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2012 09:06:54 +0200 Original-Received: from localhost ([::1]:57018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjmKx-0001VQ-UH for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2012 03:06:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjmKu-0001Ua-JQ for emacs-devel@gnu.org; Wed, 27 Jun 2012 03:06:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SjmKr-00036t-D2 for emacs-devel@gnu.org; Wed, 27 Jun 2012 03:06:48 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:43720) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1SjmKr-000361-32 for emacs-devel@gnu.org; Wed, 27 Jun 2012 03:06:45 -0400 Original-Received: (qmail invoked by alias); 27 Jun 2012 07:06:42 -0000 Original-Received: from 62-47-58-249.adsl.highway.telekom.at (EHLO [62.47.58.249]) [62.47.58.249] by mail.gmx.net (mp029) with SMTP; 27 Jun 2012 09:06:42 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/qd4MmScbq7zdIFWJgSs70I6H6Upb96Eb/4nMoPg OKT1Oeg5wwmhpj In-Reply-To: <83a9zq9jhp.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.23 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:151209 Archived-At: > 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. >> Anyway, window_end_pos and window_end_vpos are the more >> promising candidates (if Eli agrees). > > I don't object. But if we think that Lisp integers cause any > significant slowdown during GC, we could special-case them in > mark_object, because that is a no-op for integers. That would be less > work and less potential bugs. I don't care about GC. But it seems to me that _all_ accesses of these two structure members are via make_number and XFASTINT. So we can only gain from cleaning up this. >> 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). martin