From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame Date: Sat, 13 Oct 2012 20:08:37 +0200 Message-ID: <83obk65joa.fsf@gnu.org> References: <50720A4F.2010200@gmail.com> <83391p5sjc.fsf@gnu.org> <50729A38.8000800@gmx.at> <83haq53qy8.fsf@gnu.org> <5073F029.4040201@gmx.at> <83y5jfziey.fsf@gnu.org> <50754C80.7010809@gmx.at> <83ehl6z5y0.fsf@gnu.org> <50767172.4060807@gmx.at> <83a9vtkkvl.fsf@gnu.org> <5077C771.1000208@gmx.at> <837gqw843w.fsf@gnu.org> <5077E47D.4080300@gmx.at> <50783A85.1080808@gmx.at> <83626e7nse.fsf@gnu.org> <507939B2.8070709@gmx.at> <83wqyu5ynn.fsf@gnu.org> <5079A8B0.7050000@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1350151756 30972 80.91.229.3 (13 Oct 2012 18:09:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2012 18:09:16 +0000 (UTC) Cc: 12600@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 13 20:09:23 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1TN69G-0006ak-Bh for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 20:09:18 +0200 Original-Received: from localhost ([::1]:38899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN699-0000nf-3p for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 14:09:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN696-0000nN-5i for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 14:09:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TN693-0001Bz-Qp for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 14:09:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN693-0001Bv-NJ for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 14:09:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TN69y-0000tG-CX for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 14:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Oct 2012 18:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12600 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12600-submit@debbugs.gnu.org id=B12600.13501517843390 (code B ref 12600); Sat, 13 Oct 2012 18:10:02 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 13 Oct 2012 18:09:44 +0000 Original-Received: from localhost ([127.0.0.1]:42786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TN69f-0000sc-R1 for submit@debbugs.gnu.org; Sat, 13 Oct 2012 14:09:44 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:44813) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TN69d-0000sQ-S8 for 12600@debbugs.gnu.org; Sat, 13 Oct 2012 14:09:43 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MBU00G00FL3JZ00@a-mtaout20.012.net.il> for 12600@debbugs.gnu.org; Sat, 13 Oct 2012 20:08:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBU00G8YFQ86070@a-mtaout20.012.net.il>; Sat, 13 Oct 2012 20:08:32 +0200 (IST) In-reply-to: <5079A8B0.7050000@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:65569 Archived-At: > Date: Sat, 13 Oct 2012 19:45:20 +0200 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org > > >> (1) Change the window's buffer via `set-window-buffer'. > > > > This is taken care of by setting windows_or_buffers_changed. > > windows_or_buffers_changed is a global flag. How does redisplay find > out _which_ window got a new buffer? Or does redisplay not care? It doesn't care, in the sense that it always considers every window. It _does_ care, in the sense that certain redisplay optimizations are turned off when windows_or_buffers_changed is non-zero. E.g., if nothing's changed since the last redisplay, then redisplay will only enter try_cursor_movement for each window, quickly see that point didn't move, and exit without doing anything. But if windows_or_buffers_changed is non-zero, this optimizations is disabled. > >> (2) Change the size of the window (including toggling of scrollbars and > >> fringes). > > > > Redisplay figures this out already, I think. Which commands/functions > > make these changes? > > They all end up calling window_resize_apply. They all also set windows_or_buffers_changed non-zero. So I think these cases are already covered, as far as redisplay is concerned. > > >> (3) Change the buffer's position in the window (usually via scrolling, > >> `set-window-point' and `set-window-start'). > > > > These likewise set windows_or_buffers_changed, so they shouldn't be a > > problem. > > But usually they affect only one window. Again, redisplay might not > care. But I would be surprised that it doesn't handle such a simple > case of optimization. It tries. It disables fewer optimizations when last_modified is reset than when windows_or_buffers_changed is non-zero. But I doubt that this difference shows in many important situations. At least resizing a window never affects only one window. > >> Now in all of these cases, the respective routines in window.c would set > >> the window's last_modified_flag to t, marking the window as dirty. > > > > I don't think this is necessary. Can you try without setting this > > flag, and see if anything breaks? > > I said "would". last_modified_flag doesn't exist. The same should be tru for the last_modified and last_overlay_modified fields, which do exist. > >> So why do we currently reset last_modified and last_overlay_modified in > >> window.c? > > > > See above. Maybe I'm missing something, but > > windows_or_buffers_changed should take care of all of this. > > OK. I'll comment them out after the feature freeze and we'll see ;-) Thanks. > Replace the three struct members last_modified, last_overlay_modified > and window_end_valid by one struct member called last_modified_flag - > actually calling it window_modified would be better. Set > window_modified to t wherever we currently reset one of the three > members. Redisplay, when fully done, would reset window_modified to nil > for every window it completes instead of setting the other members. And when a buffer is modified or its overlays are modified, what should we do to indicate to redisplay that the corresponding windows might need a more thorough redisplay?