From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#16431: 24.3.50; `follow-adjust-windows' sometimes fails (patch included) Date: Thu, 16 Jan 2014 13:58:41 -0500 Message-ID: References: <837g9z3jax.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389898755 10739 80.91.229.3 (16 Jan 2014 18:59:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 18:59:15 +0000 (UTC) Cc: 16431@debbugs.gnu.org, andlind@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 16 19:59:20 2014 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 1W3s9v-0005OE-SF for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 19:59:20 +0100 Original-Received: from localhost ([::1]:34565 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3s9v-0000HW-Fq for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 13:59:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3s9l-0000ES-Vs for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 13:59:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3s9e-00014Q-L7 for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 13:59:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3s9e-00014F-I2 for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 13:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3s9d-0001XT-RN for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 13:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jan 2014 18:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16431 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16431-submit@debbugs.gnu.org id=B16431.13898987275891 (code B ref 16431); Thu, 16 Jan 2014 18:59:01 +0000 Original-Received: (at 16431) by debbugs.gnu.org; 16 Jan 2014 18:58:47 +0000 Original-Received: from localhost ([127.0.0.1]:53983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3s9O-0001Wu-B8 for submit@debbugs.gnu.org; Thu, 16 Jan 2014 13:58:47 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:31813) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3s9L-0001Wg-Ol for 16431@debbugs.gnu.org; Thu, 16 Jan 2014 13:58:44 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwstBxIUGA0kiB4GwS2NVYM1A4hhiXmSIIFegxU X-IPAS-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwstBxIUGA0kiB4GwS2NVYM1A4hhiXmSIIFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45127876" Original-Received: from 76-10-140-163.dsl.teksavvy.com (HELO pastel.home) ([76.10.140.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Jan 2014 13:58:42 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id D7B28600B8; Thu, 16 Jan 2014 13:58:41 -0500 (EST) In-Reply-To: <837g9z3jax.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Jan 2014 19:53:10 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:83610 Archived-At: > I don't have a clear understanding of how your suggestion would work. Don't worry: you're not alone. > Now, the above doesn't say, but your later message indicates that by > "redisplay a window" you mean only the first part. That's right. > However, the current redisplay cycle marks a window's display > "accurate" only after update_frame was called and was able to complete > its job. I'm not sure we can mark a window "up to date" without > actually delivering the stiff to the glass. Indeed, we may need to introduce a new boolean flag to distinguish the "matrix up to date" from "display up to date". I haven't had to deal with this part of the code yet, so I'm not sure it will turn out. But seen from a distance, it looks like it should be doable without any serious restructuring. > Next, there's a complication on TTYs: there, update_frame updates the > entire frame at once, not one window at a time (as it does on GUI > displays). So the TTY redisplay cannot easily update several windows > one by one without doing a lot of redundant work. That's actually good. It means there's an existing road that goes in the direction of separating the "update the matrix" vs "update the display". > The function that redisplays a window in your sense already exists: > it's redisplay_window; you just need to expose it to Lisp. More or less, yes. > But calling that function from pre-redisplay-function, i.e. from > inside redisplay, means you are potentially re-entering the display > engine, which is non-reentrant. Note that pre-redisplay-function is called from redisplay, not from redisplay_window, so having pre-redisplay-function call redisplay_window does not in itself create a circularity. Of course, the devil is in the detail, but again, from a distance it looks doable. > OTOH, the job at hand is very simple: we need to ask the display > engine to redisplay several windows in a particular order, and to > determine the window-start of each of these windows from the > window-end of the previous one. It's not quite that simple because point may want to move from one window to the other instead of scrolling. Of course, my plan currently does not account for this either (my best guess so far is that we should somehow tell redisplay-window not to change scroll and if that causes point to move it means scrolling was needed, at which point we can decide whether to move point to another window, or to call redisplay-window again (but letting it scroll this time)). > This is a much easier job, one that doesn't require re-entering the > display engine, nor usurping its job by redisplaying some windows > behind its back "by hand". Could be. As you know, I'm a big fan of moving code to Elisp to provide ever more rope for users to shoot themselves in the foot. E.g. maybe the same functionality can later be used for scroll-all-mode and two-columns-mode. Presumably, ediff could also use that kind of functionality. Stefan