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: Fri, 12 Oct 2012 10:52:03 +0200 Message-ID: <837gqw843w.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1350032009 8135 80.91.229.3 (12 Oct 2012 08:53:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Oct 2012 08:53:29 +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 Fri Oct 12 10:53:33 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 1TMazt-0007hB-3O for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2012 10:53:33 +0200 Original-Received: from localhost ([::1]:45195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMazm-0003L5-OE for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2012 04:53:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMazj-0003Ks-S7 for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 04:53:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMazZ-0007BY-MS for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 04:53:23 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMazZ-0007BM-I0 for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 04:53:13 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TMb0M-0007Ob-28 for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 04:54: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: Fri, 12 Oct 2012 08:54: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.135003198328361 (code B ref 12600); Fri, 12 Oct 2012 08:54:02 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 12 Oct 2012 08:53:03 +0000 Original-Received: from localhost ([127.0.0.1]:40378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMazO-0007NO-RZ for submit@debbugs.gnu.org; Fri, 12 Oct 2012 04:53:03 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:49201) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMazK-0007Mr-OD for 12600@debbugs.gnu.org; Fri, 12 Oct 2012 04:52:59 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MBR00C00V6B0D00@a-mtaout21.012.net.il> for 12600@debbugs.gnu.org; Fri, 12 Oct 2012 10:52:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBR00BZDVAQU2A0@a-mtaout21.012.net.il>; Fri, 12 Oct 2012 10:52:03 +0200 (IST) In-reply-to: <5077C771.1000208@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:65514 Archived-At: > Date: Fri, 12 Oct 2012 09:32:01 +0200 > From: martin rudalics > CC: cschol2112@gmail.com, 12600@debbugs.gnu.org > > Before doing that, could you please in window.h eventually update the > comments for display related fields like last_modified, > last_overlay_modified, last_point to say who's supposed to (re-)set them > to which value. I would like to, but I need some guidance as to what is unclear, see below. > I'm afraid the current situation is a mess. I can agree to that. Quite a few struct members related to the display engine (and I suppose other core structures as well) are insufficiently, in accurately, or even downright incorrectly documented. I try to fix every such problem I bump into, FWIW. > For example, what does the "displayed buffer's text modification events > counter as of last time display completed" mean? This one sounds quite clear, please tell which part needs further clarifications. It would be better to say "counter of the displayed buffer's modification events as of last time display completed", but somehow I'm guessing it's not what you had in mind. > Suppose redisplay has set this to 37. Apparently, setting it to 36 > means that the next redisplay will notice that for this window > display is not accurate and has to be redone because 36 < 37. Not necessarily. It depends on what is recorded in the buffer's BUF_MODIFF slot. > But why is a flag insufficient to accomplish that? IIUC it's set only > once by mark_window_display_accurate_1 and everywhere else reset to 0. > Why can't we set it to "accurate" in mark_window_display_accurate_1 and > "inaccurate" everwhere else? How would this work when the displayed buffer is modified behind redisplay's back? The last_modified slot belongs to the window, which redisplay controls, but it doesn't control the buffer, which could well be displayed in other windows as well and modified through there. The display engine treats each window separately; when it displays some window, it doesn't use information from other windows. > And why do we have additional fields for last_overlay_modified and > window_end_valid? What sense does it make to handle these separately? Because changes in overlays do not constitute changes in buffer contents, and are done via yet another set of primitives, yet they do require redisplay. Also because each one of these can allow and disallow certain distinct redisplay optimizations, at least in principle. As for window_end_valid flag, it's there to allow yet another set of redisplay optimizations. > For example, wherever last_modified is reset to 0 last_overlay_modified > is always reset to 0 too. Isn't that plain overkill? The potential for separate optimizations is not realized, that's true. But it exists; I'm not sure we should remove it, and I surely won't spend any of my personal time trying. Fixing real bugs in the display engine is enough to fill my free time already. Of course, if you feel like it, and if no one objects, feel free to make these cleanups.