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 14:45:00 +0200 Message-ID: <83wqyu5ynn.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1350132370 11557 80.91.229.3 (13 Oct 2012 12:46:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2012 12:46:10 +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 14:46:17 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 1TN16f-0005fR-3f for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 14:46:17 +0200 Original-Received: from localhost ([::1]:36675 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN16Y-0005F8-F7 for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 08:46:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN16W-0005F2-B3 for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 08:46:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TN16V-0002eg-1s for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 08:46:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60176) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TN16U-0002ea-UH for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 08:46:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TN17N-00022l-UZ for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 08:47:01 -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 12:47:01 +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.13501323647585 (code B ref 12600); Sat, 13 Oct 2012 12:47:01 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 13 Oct 2012 12:46:04 +0000 Original-Received: from localhost ([127.0.0.1]:42194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TN16R-0001yH-4p for submit@debbugs.gnu.org; Sat, 13 Oct 2012 08:46:03 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:38693) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TN16M-0001xl-QQ for 12600@debbugs.gnu.org; Sat, 13 Oct 2012 08:46:00 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MBU00C000K34F00@a-mtaout22.012.net.il> for 12600@debbugs.gnu.org; Sat, 13 Oct 2012 14:44:56 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBU00BE90QWZZ30@a-mtaout22.012.net.il>; Sat, 13 Oct 2012 14:44:56 +0200 (IST) In-reply-to: <507939B2.8070709@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:65560 Archived-At: > Date: Sat, 13 Oct 2012 11:51:46 +0200 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org > > >> last_modifed_flag is a fictitious variable I would set when the window > >> changes. When it's set, redisplay must redisplay the window. > > > > What do you mean by "window changes"? And how would any code outside > > of the display engine know whether some change requires to redisplay a > > window? > > There are three types of window changes we have to consider: > > (1) Change the window's buffer via `set-window-buffer'. This is taken care of by setting windows_or_buffers_changed. > (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? > (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. > 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? > > Anyway, I don't think the above is right. Only the display engine > > should set this variable. The display engine should figure out itself > > whether to redisplay a window, by using other means. If it doesn't, > > that's a bug. > > 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. > >> We'd obviously have an independent buffer_modified_flag. A window must > >> be redisplayed if either buffer_modified_flag is set (modulo any > >> optimizations which I won't dispute here) or its last_modifed_flag is > >> set. > > > > But comparing the buffer's modiff with last_modified already > > accomplishes this, so what would be the purpose of converting > > last_modified to a boolean flag, and then introducing another struct > > member that acts exactly like last_modified does today? > > The last_modified_flag struct member would replace three members that > have very obscure semantics IMHO. 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?