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: Latest changes in redisplay code Date: Tue, 05 Feb 2013 20:01:21 +0200 Message-ID: <83d2weabda.fsf@gnu.org> References: <83pq0g9hcf.fsf@gnu.org> <51109E0B.3000402@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1360087287 25719 80.91.229.3 (5 Feb 2013 18:01:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Feb 2013 18:01:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 05 19:01:44 2013 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 1U2mpu-0006i1-Mc for ged-emacs-devel@m.gmane.org; Tue, 05 Feb 2013 19:01:38 +0100 Original-Received: from localhost ([::1]:46715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2mpc-0000XN-2W for ged-emacs-devel@m.gmane.org; Tue, 05 Feb 2013 13:01:20 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2mpZ-0000XH-BH for emacs-devel@gnu.org; Tue, 05 Feb 2013 13:01:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2mpV-0004gu-Ed for emacs-devel@gnu.org; Tue, 05 Feb 2013 13:01:17 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2mpV-0004gf-6m for emacs-devel@gnu.org; Tue, 05 Feb 2013 13:01:13 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MHR00000DI8FH00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 05 Feb 2013 20:01:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHR000CSE1X3DA0@a-mtaout22.012.net.il>; Tue, 05 Feb 2013 20:01:10 +0200 (IST) In-reply-to: <51109E0B.3000402@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:156831 Archived-At: > Date: Tue, 05 Feb 2013 09:52:11 +0400 > From: Dmitry Antipov > CC: Emacs development discussions > > On 02/04/2013 08:25 PM, Eli Zaretskii wrote: > > > This change loses the ability to track the buffer whose line numbers > > are being displayed on the mode line. This means we will now never > > show line numbers in this window, even after the buffer it displays > > changes. (I just tried that, and it really is so -- another bug.) > > Could you please provide an example? I don't see the way to reproduce it. Forget it, my testing was wrong. I always forget that line-number-display-limit is counted in characters, not lines. And it didn't help that the change in adjust_window_count was not mentioned at all in the ChangeLog entry for this set. (Please do make sure you describe all the changes there, it's important for analyzing who changed what and why.) In any case, the potential for problems is still there, because now w->base_line_pos gets reset to zero in many more places than it was before. Previously, only xdisp.c would manipulate this attribute in a few well-defined places. Now it can be reset by any function that calls adjust_window_count, including wset_buffer, which is called from many primitives, most of them outside xdisp.c. Therefore, it's quite possible that we will now have to count from the beginning of the buffer much more frequently than we did before. In large buffers, this could be quite a hit. > > Revision 111584 also has a suspicious change: > > > > @@ -3189,7 +3182,7 @@ set_window_buffer (Lisp_Object window, L > > wset_window_end_pos (w, make_number (0)); > > wset_window_end_vpos (w, make_number (0)); > > memset (&w->last_cursor, 0, sizeof w->last_cursor); > > - wset_window_end_valid (w, Qnil); > > + > > > > Why was this setting dropped? You didn't answer that. > > How can we make this process less dangerous? > > Hm. Although I agree that I had to test 111647 more carefully, there always will > be the things which can't be tested by just one developer (like 111594, for example). > As for the redisplay, automated testing is practically impossible; at least, it would > be nice to have a set of "non-typical" (beyond basic editing) use cases which should > trigger some corner-case situations. Granted, I'm well aware of that. It's precisely _because_ of this lack of a comprehensive test suite that I'm worried by such changes. I can only suggest to try to minimize the danger by thorough discussions of every non-trivial changeset. I realize that this will slow down development to some extent, but I see no other way to make sure we don't introduce hard to find bugs. The display code is tricky, and the number of obscure display features in Emacs is mind-boggling. The result is that no single individual can possibly grasp all the possible implications of a change in core data structures and algorithms. Discussing such changes can go a long way towards uncovering potential pitfalls in advance. Btw, here's one more questionable change, from revision 111583: @@ -13784,25 +13777,21 @@ mark_window_display_accurate (Lisp_Objec for (; !NILP (window); window = w->next) { w = XWINDOW (window); - mark_window_display_accurate_1 (w, accurate_p); - if (!NILP (w->vchild)) mark_window_display_accurate (w->vchild, accurate_p); - if (!NILP (w->hchild)) + else if (!NILP (w->hchild)) mark_window_display_accurate (w->hchild, accurate_p); + else if (BUFFERP (w->buffer)) + mark_window_display_accurate_1 (w, accurate_p); Isn't it possible for a window to have both an hchild and a vchild?