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 15:51:31 +0200 Message-ID: <83txtz7q8s.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1350049938 3699 80.91.229.3 (12 Oct 2012 13:52:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Oct 2012 13:52:18 +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 15:52:25 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 1TMff5-0003Ac-KV for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2012 15:52:23 +0200 Original-Received: from localhost ([::1]:56757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMfez-0008HD-1e for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2012 09:52:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMfev-0008Gw-PQ for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 09:52:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMfeu-0006dG-BH for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 09:52:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMfeu-0006dC-7Q for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 09:52:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TMffi-0006kP-6O for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 09:53: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 13:53: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.135004995025897 (code B ref 12600); Fri, 12 Oct 2012 13:53:02 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 12 Oct 2012 13:52:30 +0000 Original-Received: from localhost ([127.0.0.1]:40710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMffB-0006jd-GN for submit@debbugs.gnu.org; Fri, 12 Oct 2012 09:52:30 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:47116) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMff8-0006jL-FC for 12600@debbugs.gnu.org; Fri, 12 Oct 2012 09:52:28 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MBS00D0092OBW00@a-mtaout21.012.net.il> for 12600@debbugs.gnu.org; Fri, 12 Oct 2012 15:51:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBS00DTZ95TBJ10@a-mtaout21.012.net.il>; Fri, 12 Oct 2012 15:51:29 +0200 (IST) In-reply-to: <5077E47D.4080300@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:65519 Archived-At: > Date: Fri, 12 Oct 2012 11:35:57 +0200 > From: martin rudalics > CC: cschol2112@gmail.com, 12600@debbugs.gnu.org > > > 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. > > If these concern the display engine exclusively, there's no problem. I think this is why these are there, yes. > Problems arise when the window handling code is supposed to change them. Like where and when? > >> 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. > > That's exactly what I had in mind: Either something that corresponds > textually to what is used in buffer.h or just mention the name of the > corresponding field used in buffer.h. OK, will do. > >> 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. > > IIUC this can only increase monotonously But BUF_MODIFF could also change, no? And a window can display another buffer, can't it? > When last_modifed_flag is set, the window must be redisplayed. Not exactly, but OK. > OTOH when the buffer iself is modified it has to be > redisplayed anyway because we hardly know where the change happened. If course, we know: we know where the window begins and ends. > So I don't see why such a comparison of counters is useful. But > maybe I'm missing something. We probably both are, but what's the bottom line here? > >> 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. > > I doubt whether such optimizations exist. What, you mean in theory? That's a strange opinion, as there are any number of ways of optimizing redisplay. In fact, there are comments today in the display code that describe optimizations that could be implemented, but never were. > Suppose we could exclude a change to happen within the bounds of a > window as for example a buffer displayed with a window starting at M > and ending at N and an overlay modified at some position < M or > N. > Wouldn't this require to associate each single overlay with a > modification counter? Maybe, but I doubt that would allow any gains. To make use of these counters, you'd have to examine every overlay; but as soon as you have an overlay in hand, its buffer position is as easy to access as its counter. The problem with overlays is that overlays-at, next-overlay-change, etc. are slow, not that we lack some info in the overlays themselves. Anyway, it would seem to be bad design to have a _window_ flag that would change when some text or overlay in a buffer is modified. Emacs separates between display-related structures and buffer-related structures for a number of good reasons, the most important being that they are modified and examined independently, and there's no 1:1 relation between buffers and windows. > I think that a correct implementation would have for each window w > > (w->last_modified < MODIFF) => (NOT (w->window_end_valid)) > > but strongly doubt that this implication holds currently. You could try putting assertions like that in the code and see if they fire. > I don't intend to make any cleanups. I'd like to have a simple routine > we can use to reset any such structur members within window.c and have > that DTRT. Under what circumstances does window.c need to do that? > Currently, `window-end' is clearly broken and we should fix it. An optimization that sometimes does the wrong thing is easy to fix: either discover a condition under which the optimization works, or simply disable the optimization.