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: Thu, 27 Aug 2015 21:57:06 +0300 Message-ID: <83y4gw4l19.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1440701914 28840 80.91.229.3 (27 Aug 2015 18:58:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2015 18:58:34 +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 Thu Aug 27 20:58:19 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 1ZV2NM-0008Be-2D for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 20:58:16 +0200 Original-Received: from localhost ([::1]:44185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV2NL-0004PD-CI for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 14:58:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV2ND-0004Op-J9 for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:58:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV2N8-0006r9-9L for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:58:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV2N8-0006r5-6z for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZV2N8-00009H-3k for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Aug 2015 18:58:02 +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.1440701829487 (code B ref 21333); Thu, 27 Aug 2015 18:58:02 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 18:57:09 +0000 Original-Received: from localhost ([127.0.0.1]:40548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV2MG-00007n-Oy for submit@debbugs.gnu.org; Thu, 27 Aug 2015 14:57:09 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:33649) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV2ME-00007e-2w for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 14:57:07 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTR00E008LKNO00@mtaout28.012.net.il> for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 21:56:57 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTR00AIK8MX1A40@mtaout28.012.net.il>; Thu, 27 Aug 2015 21:56:57 +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:105890 Archived-At: > Date: Thu, 27 Aug 2015 16:35:44 +0000 > From: Pip Cet > Cc: martin rudalics , 21333@debbugs.gnu.org > > The call to grow/shrink_mini_window only recomputes data > about the windows for the next redisplay cycle. > > No. It computes data about the windows for the cycle that's currently > happening, that has already called prepare_menu_bars and will most likely not > do so again. That's exactly what I said, just in other words. > Note that grow_mini_window is called by redisplay_internal, via > resize_mini_window, not just by display_echo_area. They are both called _after_ prepare_menu_bars. So if resize_mini_window, however it is called, sets the flag that windows has been resized, only the next redisplay cycle will notice that and call the window-size-change-functions. > If you set breakpoints on prepare_menu_bars, grow_mini_window, and > redisplay_internal, the log is: > > Breakpoint 12, redisplay_internal () at xdisp.c:13310 > Breakpoint 10, prepare_menu_bars () at xdisp.c:11558 > Breakpoint 11, grow_mini_window (w=0x12676a0, delta=15, pixelwise=true) at > window.c:4491 > Breakpoint 12, redisplay_internal () at xdisp.c:13310 I already did that, before writing my message. > The call order is that redisplay_internal calls prepare_menu_bars, then calls > grow_mini_window, then performs the frame update. It doesn't go back to calling > prepare_menu_bars, but it does call update_frame, and that actually does its > job. Yes, and that is not what you want because?... > When that next cycle comes, it will first call pre-redisplay-function > > Yes. With a nil argument. I don't fully understand why. > > and window-size-change-functions > > No. Miniwindow resizes do not set the WINDOW_SIZES_CHANGED flag even if they > resize other windows. I was talking about the situation after you proposed changes, which will cause the flag to be set (AFAIU). > , from prepare_menu_bars, and then, after the rest of redisplay finishes, > actually perform the X repaint, by > calling update_frame. > > > No. The sequence is redisplay_internal, then prepare_menu_bars, then > grow_mini_window, then update_frame. But grow_mini_window only recomputes the start of the window, it does not redisplay it. The next cycle will. 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. > Moreover, the scenario where "prepare_menu_bars is > called before auto-resizing the minibuffer window", and as result > "‘window-size-change-functions’ wouldn't catch those auto-resizes", > seems impossible. > > > I don't think it's impossible, I think it's clearly happening to produce the > breakpoint order that I'm seeing. (This is speculation, but I think my call > order only applies to minibuffer window resizes, as stated above, not echo area > resizes triggered by message3. That might be wrong, though). Careful with drawing conclusions from the call order alone. The fact that redisplay_internal was called doesn't mean it actually decided to redisplay a specific window, or any window. The fact that update_frame was called doesn't necessarily mean that anything at all was written to the glass. These functions have a lot of optimizations in them, and try to avoid doing stuff if they think it isn't necessary. You need to trace into the functions' guts to see if they actually update anything. Especially update_frame, which tries very hard to avoid writing to the glass, if it thinks the desired and the current contents are the same. That function is the last line of defense against redisplaying the same stuff over and over again.