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 11:51:46 +0200 Message-ID: <507939B2.8070709@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> 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 1350121931 32117 80.91.229.3 (13 Oct 2012 09:52:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2012 09:52:11 +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 11:52:18 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 1TMyOH-0007k7-68 for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 11:52:17 +0200 Original-Received: from localhost ([::1]:34944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMyOA-0000Kc-Ke for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2012 05:52:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43279) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMyO8-0000KX-PW for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 05:52:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMyO7-00083O-MH for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 05:52:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMyO7-00083K-IX for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 05:52:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TMyOz-0003t5-UX for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2012 05:53: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: Sat, 13 Oct 2012 09:53: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.135012197814932 (code B ref 12600); Sat, 13 Oct 2012 09:53:01 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 13 Oct 2012 09:52:58 +0000 Original-Received: from localhost ([127.0.0.1]:42081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMyOv-0003sg-P0 for submit@debbugs.gnu.org; Sat, 13 Oct 2012 05:52:58 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:34427) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TMyOt-0003sU-E1 for 12600@debbugs.gnu.org; Sat, 13 Oct 2012 05:52:56 -0400 Original-Received: (qmail invoked by alias); 13 Oct 2012 09:51:52 -0000 Original-Received: from 62-47-41-74.adsl.highway.telekom.at (EHLO [62.47.41.74]) [62.47.41.74] by mail.gmx.net (mp030) with SMTP; 13 Oct 2012 11:51:52 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/19TJ49xb1wRt0DGjxgcr6Hy9tsBYE3Q8+DFmlul altkvf65nBpFAq In-Reply-To: <83626e7nse.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:65555 Archived-At: >> 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'. (2) Change the size of the window (including toggling of scrollbars and fringes). (3) Change the buffer's position in the window (usually via scrolling, `set-window-point' and `set-window-start'). There might be indirect changes as well (e.g., when setting a window display property) but let's stick to the three cited above. All these require usually a complete redisplay of the buffer in the window. There is one exception, namely when `split-window-keep-point' is nil, `split-window-below' tries to keep the old display (but I doubt that this works with variable height fonts and it will likely fail as soon as we split windows pixel-wise). 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. When resizing or splitting windows, usually more than one window is affected; for scrolling usually one window is affected. When the display engine scans windows, it has to redisplay a window when the flag is set, resetting the flag when it's done. Otherwise, it will redisplay the window iff the buffer's modification flag says so. Note that the last_modified_flag of the window covers both last_modified and last_overlay_modified as far as the window's redisplay is concerned. `window-end' with non-nil UPDATE requires a different treatment anyway because it inspects a cached value that is invalidated either by a buffer modification or a window change. Hence the only simple solution for this is to reset window_end_pos to nil whenenver we set that window's last_modified_flag. `window-end' then would update window_end_pos either if it is nil or the buffer was modified since the last redisplay. > 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? >> 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. martin