From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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 19:45:20 +0200 Message-ID: <5079A8B0.7050000@gmx.at> 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> 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: ger.gmane.org 1350150377 20489 80.91.229.3 (13 Oct 2012 17:46:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2012 17:46:17 +0000 (UTC) Cc: 12600@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 13 19:46: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 1TN5my-0006li-5c for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 19:46:16 +0200 Original-Received: from localhost ([::1]:38235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN5mr-0007GU-FR for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 13:46:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN5mp-0007GN-4Y for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 13:46:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TN5mn-0002Av-US for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 13:46:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN5mn-0002Aq-Qd for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 13:46:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TN5ni-0000LS-DY for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 13:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Oct 2012 17:47: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.13501503941285 (code B ref 12600); Sat, 13 Oct 2012 17:47:02 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 13 Oct 2012 17:46:34 +0000 Original-Received: from localhost ([127.0.0.1]:42777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TN5nF-0000Kg-La for submit@debbugs.gnu.org; Sat, 13 Oct 2012 13:46:34 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:46215) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TN5nD-0000KP-DU for 12600@debbugs.gnu.org; Sat, 13 Oct 2012 13:46:32 -0400 Original-Received: (qmail invoked by alias); 13 Oct 2012 17:45:28 -0000 Original-Received: from 62-47-56-114.adsl.highway.telekom.at (EHLO [62.47.56.114]) [62.47.56.114] by mail.gmx.net (mp070) with SMTP; 13 Oct 2012 19:45:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/HwlY495HHRqfjwbZJMvUfDurasPzJsCze/Yh8Ux LbJ60nJPaWiw8T In-Reply-To: <83wqyu5ynn.fsf@gnu.org> X-Y-GMX-Trusted: 0 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:65568 Archived-At: >> (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? >> (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. >> (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. >> 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. >> 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 ;-) > We are going in circles, so there must be some misunderstanding here. > Can you describe your complete change suggestion, wrt these flags? In > particular, what about buffer_modified_flag, and how does it enter > this picture? 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. I care about BUF_MODIFF/BUF_OVERLAY_MODIFF only in one place: When calculating `window-end' after a buffer change but before the next redisplay, `window-end' with UPDATE non-nil has to consult BUF_MODIFF/BUF_OVERLAY_MODIFF in order to be sure whether it can reuse window_end_pos. window_end_pos would be nil (invalid) initially, set to a valid value when Fwindow_end updates it, and be reset to nil wherever we change the value of window_modified. martin