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#21333: 25.0.50; window-size-change-functions not called after mini-window resize Date: Fri, 28 Aug 2015 16:13:44 +0300 Message-ID: <837fof4ktz.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <55DDB8A2.8020606@gmx.at> <55DEC348.8080306@gmx.at> <83bnds69e8.fsf@gnu.org> <83y4gw4l19.fsf@gnu.org> <83fv334tpi.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1440767665 27320 80.91.229.3 (28 Aug 2015 13:14:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 13:14:25 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 28 15:14:15 2015 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 1ZVJTu-0005Fw-Mc for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 15:14:10 +0200 Original-Received: from localhost ([::1]:47860 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVJTu-0002H1-7I for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 09:14:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVJTq-0002Gn-HT for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:14:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVJTm-0001IB-8b for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:14:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVJTm-0001I5-4l for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZVJTl-0000YE-Lq for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Aug 2015 13:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21333 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21333-submit@debbugs.gnu.org id=B21333.14407676282089 (code B ref 21333); Fri, 28 Aug 2015 13:14:01 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 13:13:48 +0000 Original-Received: from localhost ([127.0.0.1]:40893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJTX-0000Xd-Py for submit@debbugs.gnu.org; Fri, 28 Aug 2015 09:13:48 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:45417) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJTV-0000XU-E0 for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 09:13:46 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NTS00B00N8RXE00@a-mtaout20.012.net.il> for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 16:13:44 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTS00B5GNETNW40@a-mtaout20.012.net.il>; Fri, 28 Aug 2015 16:13:44 +0300 (IDT) 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: 208.118.235.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:105915 Archived-At: > Date: Fri, 28 Aug 2015 12:34:53 +0000 > From: Pip Cet > Cc: rudalics@gmx.at, 21333@debbugs.gnu.org > > . both window-size-change-functions and pre-redisplay-function is > being discussed, although it should be clear their purpose is > different, > > What's the huge difference? As far as I can tell: > pre-redisplay-function: "I'm about to redisplay these windows, and they might > have changed size or content" > window-size-change-functions: "I'm about to redisplay windows on this frame, > and some of them might have changed size" There are at least 2 differences. (1) pre-redisplay-function _must_ be run before the bulk of the redisplay code, because it is meant for functions that want to affect the current redisplay cycle. (2) The place where window-size-change-functions is currently called is too early, if it is supposed to pick up all of the resizes during this redisplay cycle, because later code that's part of redisplay could decide it wants to resize mini-window. More generally, if window-size-change-functions is supposed to be able to access the changed sizes, it must be called closer to the end of redisplay cycle. > > Wish #1: a way of knowing "when" windows are resized or moved, even > > temporarily. Whether that "when" is "just before" or "just after" doesn't > > really matter, but it should be one of those. > > This wish needs to be described in more detail. Resizing of a window > is done in several distinct steps: > > . some function (resize_mini_window, if we are talking about the > mini-window) decides whether a window should be resized, and if so, > computes its start position; > > . redisplay_window, called by redisplay_internal, computes the > "desired" contents of the window on screen; > > . update_window, called by update_frame, actually delivers the needed > changes to the glass > > > Wish #1 is for the hook to be called at any of the following points: > - between steps 1 and 2 > - between steps 2 and 3 > - shortly after step 3. But then the results of resizing will be incomplete for the first two alternatives. That might not be important for your wish, but could be important in other use cases. > In addition, it is not clear whether your hook will care if the window > actually didn't change at all. > > The hook function must be able to deal with that case, for wish #1 and wish #2. > I see no way around that complication. I do: redisplay knows that, so it could tell the hook, if we called the hook at the right place. > > Wish #1, assuming something like my proposed changes go in and this bug > is > > closed, has been granted; there's a race condition, but I might just have > to > > live with that. > > Do you still think it has been granted? > > If I'm not allowed to use pre-redisplay-function, no. Of course you are allowed. I'm just saying it's not the good place for what I think you want to do. > > The function update_frame only reflects on the glass what its > > redisplay cycle computed to be the desired display. If redisplay > > didn't recompute the window contents, update_frame will change > > nothing. > > > > That's not what I seeing running x_sync manually. > > I don't understand what that means > > Let me explain (I think you know all this, of course, but I might have it > wrong): > When update_frame returns, it's possible that it has made Xlib calls to change > the screen content but that Xlib has not yet sent out messages to the X server > to install those changes. In this case, the screen will still show the > pre-redisplay state even though redisplay() is about to exit. Calling x_sync > manually ensures that that doesn't happen. > > IOW, there are several ideas of what the screen looks like: > 1. the glyph matrix etc. > 2. what Xlib has been told the screen should look like > 3. what the screen actually looks like. > > update_frame synchronizes (2) with (1). x_sync synchronizes (3) with (2). Yes, I know. But how does that let you know what update_frame actually did? It could do very little or nothing at all, and you need to put a breakpoint at the right place (like the call to the draw_glyphs method of the display interface) to see which parts are being actually redrawn. > I omitted some steps. How about (again, this is a description of the typical > case that I'm actually seeing here): > 1. user input > 2. command loop handles user input > 3. command loop calls redisplay I think step 1 should be omitted. It doesn't add any information, and is inaccurate (because input that triggers step 2 could come from other sources). > 4. prepare_menu_bars called > 5. pre-redisplay-function called > 6. window-size-change-functions NOT called. > 7. grow_mini_window called, calculates new window size > 8. redisplay_windows/redisplay_window_1 called, compute data for update_frame > based on the new window sizes > 9. update_frame is called, writes the new, enlarged mini-window to the glass > 10. control returns to command loop > 11. redisplay is called again > 12. prepare_menu_bars called > 13. prepare-redisplay-function called > 14. window-size-change-functions not called on unmodified Emacs, called with my > initial suggested patch. Agreed. Which is why I said that your proposed change will cause window-size-change-functions to be called on the next redisplay cycle, not the one which actually resized the windows. > Are you suggesting a hook between steps 8 and 9? If we want window-size-change-functions to be able to say whether any windows were resized by the current redisplay cycle, I don't see how any other place would do.