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#16431: 24.3.50; `follow-adjust-windows' sometimes fails (patch included) Date: Thu, 16 Jan 2014 23:38:32 +0200 Message-ID: <83wqhz1uav.fsf@gnu.org> References: <837g9z3jax.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389908353 848 80.91.229.3 (16 Jan 2014 21:39:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 21:39:13 +0000 (UTC) Cc: 16431@debbugs.gnu.org, andlind@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 16 22:39:18 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 1W3uei-0006gh-H9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 22:39:16 +0100 Original-Received: from localhost ([::1]:35130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3uei-00034X-52 for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 16:39:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3ueZ-00033u-W0 for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 16:39:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3ueU-0005Pw-RH for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 16:39:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3ueU-0005Ps-Nt for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 16:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3ueU-00063B-G3 for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 16:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jan 2014 21:39:02 +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.138990832023199 (code B ref 16431); Thu, 16 Jan 2014 21:39:02 +0000 Original-Received: (at 16431) by debbugs.gnu.org; 16 Jan 2014 21:38:40 +0000 Original-Received: from localhost ([127.0.0.1]:54073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3ue7-000626-4O for submit@debbugs.gnu.org; Thu, 16 Jan 2014 16:38:40 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:38878) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3ue2-00061q-VH for 16431@debbugs.gnu.org; Thu, 16 Jan 2014 16:38:36 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MZI00000K210G00@a-mtaout23.012.net.il> for 16431@debbugs.gnu.org; Thu, 16 Jan 2014 23:38:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZI00NLIK484720@a-mtaout23.012.net.il>; Thu, 16 Jan 2014 23:38:32 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il 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:83614 Archived-At: > From: Stefan Monnier > Cc: andlind@gmail.com, 16431@debbugs.gnu.org > Date: Thu, 16 Jan 2014 13:58:41 -0500 > > > 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". Sure, that's what I said above: update_frame is where the display is being updated. In a GUI session, it calls update_window_tree, which updates the windows one by one, whereas in the TTY case it updates the entire foreground frame. In both cases, preparation of the desired matrices is separate from updating the display. > It's not quite that simple because point may want to move from one > window to the other instead of scrolling. Not sure this part should be in C, as it just selects a window. But if so, it's not hard. > > 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. Right. The hard part, as always, is to come up with a design that is flexible enough to serve these use cases, and yet simple enough to avoid placing more burden on redisplay.