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: Tue, 16 Oct 2012 11:39:37 +0200 Message-ID: <507D2B59.7030008@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> <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> 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 1350380415 27821 80.91.229.3 (16 Oct 2012 09:40:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Oct 2012 09:40:15 +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 Tue Oct 16 11:40:22 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 1TO3dH-0002WY-V6 for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Oct 2012 11:40:16 +0200 Original-Received: from localhost ([::1]:55896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO3d9-0006C3-KZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Oct 2012 05:40:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO3d2-00069W-Eb for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 05:40:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TO3cs-0002lL-PB for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 05:40:00 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35913) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO3cs-0002lH-LQ for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 05:39:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TO3e1-0003N3-SW for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2012 05:41:01 -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: Tue, 16 Oct 2012 09:41: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.135038046012949 (code B ref 12600); Tue, 16 Oct 2012 09:41:01 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 16 Oct 2012 09:41:00 +0000 Original-Received: from localhost ([127.0.0.1]:46164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TO3dz-0003Mo-JC for submit@debbugs.gnu.org; Tue, 16 Oct 2012 05:40:59 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:45480) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TO3dx-0003MW-4w for 12600@debbugs.gnu.org; Tue, 16 Oct 2012 05:40:58 -0400 Original-Received: (qmail invoked by alias); 16 Oct 2012 09:39:38 -0000 Original-Received: from 62-47-36-151.adsl.highway.telekom.at (EHLO [62.47.36.151]) [62.47.36.151] by mail.gmx.net (mp031) with SMTP; 16 Oct 2012 11:39:38 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19L7tghgeZLpqNcy/okusNPxQ6vGZSnvqicXjsWpv m+f0f5TYbZQkcF In-Reply-To: <83ipab4j8w.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:65656 Archived-At: >> 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). > 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. > I think resizing requests a thorough redisplay anyway, Resizing a frame almost certainly does. change_frame_size_1 does adjust_glyphs (f); calculate_costs (f); SET_FRAME_GARBAGED (f); f->resized_p = 1; but none of these seem useful for Fwindow_end (are they useful anywhere at all?), so ... > setting windows_or_buffers_changed cannot hurt. ... I _had to_ set this in order to make the check in Fwindow_end fail. martin