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: Fri, 12 Oct 2012 17:42:32 +0200 Message-ID: <50783A68.9030804@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> <83txtz7q8s.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 1350056600 2488 80.91.229.3 (12 Oct 2012 15:43:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Oct 2012 15:43:20 +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 Fri Oct 12 17:43:26 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 1TMhOU-00037K-IF for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2012 17:43:22 +0200 Original-Received: from localhost ([::1]:40561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMhOO-0005N0-04 for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2012 11:43:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMhOL-0005Mu-D1 for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 11:43:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMhOK-0005fg-16 for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 11:43:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMhOJ-0005fa-Un for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 11:43:11 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TMhP8-00010N-43 for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2012 11:44:02 -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: Fri, 12 Oct 2012 15:44: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.13500566223828 (code B ref 12600); Fri, 12 Oct 2012 15:44:02 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 12 Oct 2012 15:43:42 +0000 Original-Received: from localhost ([127.0.0.1]:41233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TMhOn-0000zg-IJ for submit@debbugs.gnu.org; Fri, 12 Oct 2012 11:43:42 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:54244) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TMhOk-0000zT-FQ for 12600@debbugs.gnu.org; Fri, 12 Oct 2012 11:43:40 -0400 Original-Received: (qmail invoked by alias); 12 Oct 2012 15:42:39 -0000 Original-Received: from 62-47-32-76.adsl.highway.telekom.at (EHLO [62.47.32.76]) [62.47.32.76] by mail.gmx.net (mp001) with SMTP; 12 Oct 2012 17:42:39 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18hQ4JdWvwh33rmbmEtgqrlAEEQyMIs04aIk5x2oL Lsh7B0se8vSyRv In-Reply-To: <83txtz7q8s.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:65528 Archived-At: >> Problems arise when the window handling code is supposed to change them. > > Like where and when? Currently it does reset last_modified and last_overlay_modified in Fset_window_start, set_window_buffer, window_resize_apply, grow_mini_window, shrink_mini_window, window_scroll_pixel_based, window_scroll_line_based and Fset_window_configuration. I meanwhile assume that I should do that in Fdelete_other_windows_internal too. OTOH Frecenter, Fset_window_fringes and Fset_window_scroll_bars do set window_end_valid but leave w->last_modified and w->last_overlay_modified alone. >> 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. And if possible add for each of these an advice like "Code that may change the start/end position of a buffer in the window is supposed to reset the value of this to Qnil/0". Please keep in mind that not very many people currently have an idea what these fields are used for. So even if your advices are sloppy they will help to keep one's attention. >> > 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? I meant BUF_MODIFF. > And a window can display > another buffer, can't it? This would obviously have to be caught elsewhere since currently you don't check for buffer identities either when you do && w->last_modified >= MODIFF in redisplay_internal (you probably did that before, but in some independent way). In any case, set_window_buffer would set last_modifed_flag as well so again there's no reason for a counter. >> When last_modifed_flag is set, the window must be redisplayed. > > Not exactly, but OK. You mean that in some cases we could get away without redisplaying it? That's what I tried to address below. >> 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. But we don't necessarily know where any buffer change(s) happened at the time we redisplay. >> 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? That I still don't see why comparing last_modifed and MODIFF is useful and why we have to assign two or three integer/Lisp fields instead of one boolean. >> > 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. Could you lay out one possible way where using a counter for last_overlay_modified would allow an optimization? I certainly would not question any other optimizations. >> 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 agree with everything you say here. Only that my conclusion is that using a counter in last_overlay_modified is pretty much useless. >> 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. Why bother? You would have helped me by telling that such an assertion _should_ hold. If so, I can easily fill in the details. >> 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? In the cases I cited at the beginning of this post. And maybe in some cases I'm not aware of. >> 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. If the underlying implementation defies the optimization, we should fix that implementation. But for that I'd have to understand the semantics of the optimization first. martin