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: Mon, 15 Oct 2012 11:41:05 +0200 Message-ID: <507BDA31.6040608@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> 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 1350294145 20317 80.91.229.3 (15 Oct 2012 09:42:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Oct 2012 09:42:25 +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 Mon Oct 15 11:42:31 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 1TNhBp-0002ea-17 for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Oct 2012 11:42:25 +0200 Original-Received: from localhost ([::1]:55962 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNhBi-0003v6-6s for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Oct 2012 05:42:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNhBW-0003py-S7 for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2012 05:42:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TNhBM-0000ZY-Br for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2012 05:42:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNhBM-0000ZO-8B for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2012 05:41:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TNhCQ-0001Ju-6F for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2012 05:43: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: Mon, 15 Oct 2012 09:43: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.13502941505025 (code B ref 12600); Mon, 15 Oct 2012 09:43:02 +0000 Original-Received: (at 12600) by debbugs.gnu.org; 15 Oct 2012 09:42:30 +0000 Original-Received: from localhost ([127.0.0.1]:44678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TNhBt-0001Iz-Kn for submit@debbugs.gnu.org; Mon, 15 Oct 2012 05:42:30 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:44971) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TNhBr-0001Id-Cs for 12600@debbugs.gnu.org; Mon, 15 Oct 2012 05:42:28 -0400 Original-Received: (qmail invoked by alias); 15 Oct 2012 09:41:15 -0000 Original-Received: from 62-47-46-26.adsl.highway.telekom.at (EHLO [62.47.46.26]) [62.47.46.26] by mail.gmx.net (mp001) with SMTP; 15 Oct 2012 11:41:15 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+nGc1dlsenkQqDN6urCKAthDNBb0GnTejQD1gv1f 58HjazxSh9z/JK In-Reply-To: <83y5j84yd9.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:65625 Archived-At: >> > How do you know whether the window's buffer was modified, under your >> > suggestion? Won't we need some record of "the last buffer state when >> > this window was displayed"? E.g., how do we know that point moved >> > since last full redisplay of the window? >> >> If we do not know whether point moved in a buffer since its last >> redisplay, we probably can't optimize anything at all. > > We do know, but only because we record that (in w->last_point). > >> But we already >> got MODIFF, CHARS_MODIFF, and OVERLAY_MODIFF. What are these good for >> if we always have to redisplay a window showing a buffer whose point >> could have moved since the last redisplay? > > Those MODIFF features record actual changes, not cursor motion. > >> But apparently >> try_cursor_movement handles this if I understand your text below >> correctly. So why are you asking this? > > Because I don't understand your plan to redesign these variables and > flags. I don't see the big picture. I never proposed to redesign the handling of w->last_point. All I cared about were last_modified, last_overlay_modified, and window_end_valid. >> So try_cursor_movement cares about the no buffer change, no overlay >> change, no window change, no font change, ... only point movement case. > > No, it is only _called_ when there are no changes of the kind you > mention above. If any of these changes are detected, > try_cursor_movement is bypassed, since it is known that it will not do > the job. Sorry for being unclear. That's what I tried to describe with my sentence above. Maybe "bothers" would have been a better term ... > And current_matrix_up_to_date_p is computed thusly: > > current_matrix_up_to_date_p > = (!NILP (w->window_end_valid) > && !current_buffer->clip_changed > && !current_buffer->prevent_redisplay_optimizations_p > && w->last_modified >= MODIFF > && w->last_overlay_modified >= OVERLAY_MODIFF); > >> > then >> > "goto done". try_window_id is called only if there's some change that >> > requires redisplaying some of the text, not just moving the cursor. I got the impression that the big conjunct below if (/* Point may be in this window. */ PT >= CHARPOS (startp) /* Selective display hasn't changed. */ && !current_buffer->clip_changed /* Function force-mode-line-update is used to force a thorough redisplay. It sets either windows_or_buffers_changed or update_mode_lines. So don't take a shortcut here for these cases. */ && !update_mode_lines && !windows_or_buffers_changed && !cursor_type_changed /* Can't use this case if highlighting a region. When a region exists, cursor movement has to do more than just set the cursor. */ && !(!NILP (Vtransient_mark_mode) && !NILP (BVAR (current_buffer, mark_active))) && NILP (w->region_showing) && NILP (Vshow_trailing_whitespace) /* This code is not used for mini-buffer for the sake of the case of redisplaying to replace an echo area message; since in that case the mini-buffer contents per se are usually unchanged. This code is of no real use in the mini-buffer since the handling of this_line_start_pos, etc., in redisplay handles the same cases. */ && !EQ (window, minibuf_window) /* When splitting windows or for new windows, it happens that redisplay is called with a nil window_end_vpos or one being larger than the window. This should really be fixed in window.c. I don't have this on my list, now, so we do approximately the same as the old redisplay code. --gerd. */ && INTEGERP (w->window_end_vpos) && XFASTINT (w->window_end_vpos) < w->current_matrix->nrows && (FRAME_WINDOW_P (f) || !overlay_arrow_in_current_buffer_p ())) indicates all the cases where try_cursor_movement fails immediately. > I'm not sure I understand where you are getting, but to facilitate > this discussion, let me describe the logic of redisplay_window. It > goes like this: > > . if nothing changed except possibly point, call > try_cursor_movement; if that succeeds, we are done But you clumsily check there whether "nothing changed". So I'd move this to the end. I'd start checking conditions like windows_or_buffers_changed and do the through redisplay immediately. > . otherwise, if the buffer is unchanged, try reusing some of the > current glyph matrix, assuming that just the window-start has > changed -- this is what try_window_reusing_current_matrix does What happens when the window width has changed? Is the glyph matrix still OK? In that case not even the window-start position might have changed. > . if that fails, call try_window_id, which tries reusing of the > current glyph matrix, assuming that only some lines at the > beginning or the end of the window have changed > > . if that fails, too, call try_window to redisplay the entire window > using the previous window-start point Provided the window-start position is still the same, I assume. Do we assume that the buffer has changed from here on? > . if try_window finds that point ends up outside the window, > "scroll" the window, i.e. find a better window-start point such > that point enters the window -- this is what try_scrolling does I suppose this could be called by the next as well? > . if that fails as well, compute the new window-start and redisplay > the entire window starting from there OK. I suppose the order is due to the fact that if applying step N fails, you continue with step N + 1. I thought there are enough cases where one decided statically (that is, when redisplay starts) that the last step doing the full redisplay is needed anyway and it doesn't pay to try another step first. >> This would mean that try_cursor_movement had instead of >> >> && !windows_or_buffers_changed >> >> check >> >> && !w->window_modified >> >> and the respective MODIFF conjuncts for w's buffer. > > What would we gain by this change? That for certain windows we could exclude that a redisplay is needed because the window's size or the buffer's start position in the window changed. But if you can't use this information there's obviously no need providing it. 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. Or am I wrong again and `force-window-update' never discriminates between updating a single or all windows of a frame. > It depends on how you reason about logic. To me, the condition > > !NILP (Vtransient_mark_mode) > && !NILP (BVAR (current_buffer, mark_active)) > > is clear, whereas its reverse is less so. ... doubling the negation is even less clear ;-) Ayway, I now checked in a fix for this bug based on the assumption that all involved routines set windows_or_buffers_changed. Some, like the frame resizing functions, never did so and I changed that as well. martin