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: Tue, 16 Oct 2012 19:35:25 +0200 Message-ID: <834nlu48wy.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> <83obk65joa.fsf@gnu.org> <507A921B.1060807@gmx.at> <838vb95kbi.fsf@gnu.org> <507B0583.50704@gmx.at> <83y5j84yd9.fsf@gnu.org> <507BDA31.6040608@gmx.at> <83ipab4j8w.fsf@gnu.org> <507D2B59.7030008@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1350408963 3820 80.91.229.3 (16 Oct 2012 17:36:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Oct 2012 17:36:03 +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 Tue Oct 16 19:36:10 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 1TOB3p-0000ye-Qr for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Oct 2012 19:36:10 +0200 Original-Received: from localhost ([::1]:55431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOB3i-0005UE-Nu for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Oct 2012 13:36:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOB3e-0005Ty-Lk for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 13:36:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOB3V-0005zf-0e for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 13:35:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOB3U-0005zY-NP for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 13:35:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TOB4g-0006uE-8F for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 13:37: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: Tue, 16 Oct 2012 17:37: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.135040899626511 (code B ref 12600); Tue, 16 Oct 2012 17:37:02 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 16 Oct 2012 17:36:36 +0000 Original-Received: from localhost ([127.0.0.1]:47103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TOB4G-0006tX-EK for submit@debbugs.gnu.org; Tue, 16 Oct 2012 13:36:36 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:54987) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TOB4E-0006tL-CY for 12600@debbugs.gnu.org; Tue, 16 Oct 2012 13:36:35 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MBZ00M00Y0AQT00@a-mtaout23.012.net.il> for 12600@debbugs.gnu.org; Tue, 16 Oct 2012 19:35:14 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBZ00M8DY6PIBB0@a-mtaout23.012.net.il>; Tue, 16 Oct 2012 19:35:14 +0200 (IST) In-reply-to: <507D2B59.7030008@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:65666 Archived-At: > Date: Tue, 16 Oct 2012 11:39:37 +0200 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org > > >> BTW, I meanwhile discovered that the update_mode_line field (with a > >> misleading comment IIUC) is the canonical approach to ask for > >> redisplaying a specific window. > > > > That's not my reading of the code. The w->update_mode_line flag, if > > non-zero, forces redisplay of the mode line, and also of the menu bar > > and the tool bar, of that window. Where did you see that its effect > > is to redisplay the whole window? > > Because the doc-string for Fforce_window_update says "If optional arg > OBJECT is a window, force redisplay of that window only." but the code > does > > mark_window_display_accurate (object, 0); > w->update_mode_line = 1; > if (BUFFERP (w->buffer)) > XBUFFER (w->buffer)->prevent_redisplay_optimizations_p = 1; > ++update_mode_lines; > > and does not set windows_or_buffers_changed. So apparently the above > (and not only setting w->update_mode_line to 1 as I concluded > incorrectly) are sufficient to force the redisplay of a single window > (including all windows showing the same buffer). Yes. The prevent_redisplay_optimizations_p flag is the crucial detail here. > > force-window-update with a window as its argument just marks that one > > window's display "inaccurate", requests redisplay of its mode-line, > > and prevents optimizations of any other window displaying the same > > buffer. Windows that don't display this buffer can still avoid some > > or all of redisplay through optimizations. > > That's the case I had in mind. So if I follow you correctly, > set_window_buffer could instead of doing > > windows_or_buffers_changed++; > > call Fforce_window_update with the window whose buffer gets set as its > argument. Yes, I think so.