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: Latest changes in redisplay code Date: Mon, 04 Feb 2013 18:25:20 +0200 Message-ID: <83pq0g9hcf.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1359995133 32366 80.91.229.3 (4 Feb 2013 16:25:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2013 16:25:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 04 17:25:52 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 1U2Org-0002LX-N2 for ged-emacs-devel@m.gmane.org; Mon, 04 Feb 2013 17:25:52 +0100 Original-Received: from localhost ([::1]:49553 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2OrO-0003xR-6e for ged-emacs-devel@m.gmane.org; Mon, 04 Feb 2013 11:25:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2OrL-0003x6-FQ for emacs-devel@gnu.org; Mon, 04 Feb 2013 11:25:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2OrF-0008Fn-Ho for emacs-devel@gnu.org; Mon, 04 Feb 2013 11:25:30 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:51823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2OrF-0008FT-A3 for emacs-devel@gnu.org; Mon, 04 Feb 2013 11:25:25 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MHP00600ER6YS00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Mon, 04 Feb 2013 18:25:12 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHP006P8EXZSQ60@a-mtaout21.012.net.il>; Mon, 04 Feb 2013 18:25:12 +0200 (IST) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 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:156818 Archived-At: The few last changesets in this area sneaked in questionable changes which IMO should have been discussed. I gave one example here: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13623#8 But there are more of them. - /* If this field is nil, it means we don't have a base line. - If it is a buffer, it means don't display the line number - as long as the window shows that buffer. */ - Lisp_Object base_line_pos; [...] + /* If this field is zero, it means we don't have a base line. + If it is -1, it means don't display the line number as long + as the window shows its buffer. */ + ptrdiff_t base_line_pos; [...] /* If we decided that this buffer isn't suitable for line numbers, don't forget that too fast. */ - if (EQ (w->base_line_pos, w->buffer)) + if (w->base_line_pos == -1) goto no_value; - /* But do forget it, if the window shows a different buffer now. */ - else if (BUFFERP (w->base_line_pos)) - wset_base_line_pos (w, Qnil); 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.) /* If the buffer is very big, don't waste time. */ if (INTEGERP (Vline_number_display_limit) && BUF_ZV (b) - BUF_BEGV (b) > XINT (Vline_number_display_limit)) { - wset_base_line_pos (w, Qnil); - wset_base_line_number (w, Qnil); + w->base_line_pos = 0; + w->base_line_number = 0; goto no_value; } You set base_line_pos here to zero, not to -1: why? 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? And what about these two: @@ -13758,7 +13756,7 @@ mark_window_display_accurate_1 (struct w else w->last_point = marker_position (w->pointm); - wset_window_end_valid (w, w->buffer); + w->window_end_valid = 1; @@ -27782,7 +27779,7 @@ note_mouse_highlight (struct frame *f, i And verify the buffer's text has not changed. */ b = XBUFFER (w->buffer); if (part == ON_TEXT - && EQ (w->window_end_valid, w->buffer) + && w->window_end_valid Why don't we need to assign a buffer to w->window_end_valid? What purpose did this value serve, and why did you decide it was no longer needed? I'm afraid we are throwing a lot of babies with bath water here. This all is just based on cursory reading of two recent changesets, I wonder what I might discover if I invest more time. How can we make this process less dangerous?