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 19:53:10 +0200 Message-ID: <837g9z3jax.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389894853 26836 80.91.229.3 (16 Jan 2014 17:54:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 17:54: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 18:54: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 1W3r91-0002xY-6d for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 18:54:19 +0100 Original-Received: from localhost ([::1]:34290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3r90-0004yQ-Sm for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 12:54:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3r8q-0004mn-1X for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 12:54:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3r8k-00053v-Mh for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 12:54:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3r8k-00053g-K8 for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 12:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3r8j-00085o-Vi for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 12:54: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 17:54: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.138989479631039 (code B ref 16431); Thu, 16 Jan 2014 17:54:01 +0000 Original-Received: (at 16431) by debbugs.gnu.org; 16 Jan 2014 17:53:16 +0000 Original-Received: from localhost ([127.0.0.1]:53934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3r80-00084Z-8P for submit@debbugs.gnu.org; Thu, 16 Jan 2014 12:53:16 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:35913) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3r7x-00084M-DU for 16431@debbugs.gnu.org; Thu, 16 Jan 2014 12:53:14 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZI007009IFR900@a-mtaout22.012.net.il> for 16431@debbugs.gnu.org; Thu, 16 Jan 2014 19:53:11 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZI0074W9ONM070@a-mtaout22.012.net.il>; Thu, 16 Jan 2014 19:53:11 +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:83605 Archived-At: > From: Stefan Monnier > Date: Wed, 15 Jan 2014 23:39:50 -0500 > Cc: 16431@debbugs.gnu.org > > And since I'm here, thinking about how to better support follow-mode, > here's an idea: IIUC the main problem currently (other than the "empty > last buffers") is that we have to redisplay in order to find the > window-end, after which we can adjust subsequent windows, and force > another redisplay. So we'd like redisplay of the various windows to be > done "in the right order" and be able to run some Elisp code in-between. > One option for that would be to provide a new `redisplay-window' > function which does a redisplay of only one window, and then use it > inside pre-redisplay-function. This way, when we do a normal redisplay, > our follow-pre-redisplay-function would check if some of the windows use > follow-mode. If so, follow-pre-redisplay-function would redisplay its > windows "manually" in the right order via `redisplay-window' (and setup > window-starts between each window, as appropriate). After that the > normal redisplay would continue and would find those windows "already > up-to-date", which would avoid the double-redisplay. Not sure if this discussion belongs here, but... I don't have a clear understanding of how your suggestion would work. As you well know, a redisplay cycle has 2 parts: first, the "desired" glyph matrices are created for each window that needs to be redisplayed, and then the differences between the "desired" and the "current" glyph matrices are computed and delivered to the glass. The second part is inside the call to update_frame. Now, the above doesn't say, but your later message indicates that by "redisplay a window" you mean only the first part. 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. 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. The function that redisplays a window in your sense already exists: it's redisplay_window; you just need to expose it to Lisp. 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. 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. 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". IOW, I'm not sure it is a good idea to use pre-redisplay-function for doing part of redisplay's job. Instead, we should let the display engine do its job, and provide some hints to it that would produce the necessary effect.