From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet 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 20:49:17 +0000 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c31f74d545ef051e511928 X-Trace: ger.gmane.org 1440708627 5296 80.91.229.3 (27 Aug 2015 20:50:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2015 20:50:27 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 27 22:50:18 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 1ZV47l-0008J1-G2 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 22:50:17 +0200 Original-Received: from localhost ([::1]:44634 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV47k-0004f9-TC for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 16:50:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV47d-0004Wl-3y for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 16:50:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV47X-0003Fm-Na for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 16:50:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV47X-0003FE-BU for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 16:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZV47W-0004fw-Se for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 16:50:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Aug 2015 20:50: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.144070856217880 (code B ref 21333); Thu, 27 Aug 2015 20:50:02 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 20:49:22 +0000 Original-Received: from localhost ([127.0.0.1]:40622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV46r-0004eJ-Fg for submit@debbugs.gnu.org; Thu, 27 Aug 2015 16:49:22 -0400 Original-Received: from mail-ig0-f179.google.com ([209.85.213.179]:37007) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV46o-0004e6-Qg for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 16:49:20 -0400 Original-Received: by igui7 with SMTP id i7so3233773igu.0 for <21333@debbugs.gnu.org>; Thu, 27 Aug 2015 13:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xDHrCQZL4FYJCqyUlDCwi/hEwPTUpU1L1q19Hp8Z7BE=; b=FUe3l4vp5CmpmASSU8212yoMGgR8u8LBDquQ+17BZLm6KDJMDOldGm2gSKnYWY1R4k 5i5oUlN9pNJhEhO4qtk/ediolx396WG+msbT0JlpeeC5LosOb/OkBLQZKKou27VJLqYZ lTruI1+2VCFM0cXTiszChs6Z5zLBEjeperhp11xXaMM1M9wEF/CMQE/Yz4RIyW5o0jS0 L9WDT0KhTWIoirhDUT+VjaoWl7PbWhPTwOLaS64i5nL3d0O2FYLsLCTvIF0ppY11chOD uWGP8cpQ/R8diwlAiVtgTCdgRFrpR6XcikH3bst17221cLgK5TfvehY/5Xt6YhEpezxs LWmg== X-Received: by 10.50.137.100 with SMTP id qh4mr533162igb.1.1440708558141; Thu, 27 Aug 2015 13:49:18 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Thu, 27 Aug 2015 13:49:17 -0700 (PDT) In-Reply-To: <83y4gw4l19.fsf@gnu.org> 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:105894 Archived-At: --001a11c31f74d545ef051e511928 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 6:57 PM, Eli Zaretskii wrote: > > 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. > I'm sorry, I totally misread that, then. I think of redisplay cycles as beginning when redisplay() is called and ending when it returns, so in my terminology the "next" redisplay cycle is the one that will happen after control briefly (or not so briefly, see below) returns to the command loop and redisplay() is called again. I don't insist on my terminology, but I don't understand what yours is. I understood "next redisplay cycle" to refer to the redisplay cycle for which redisplay() has not yet been called, not the one for which redisplay() has already been called. > > 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. Except when they're not, I've just seen this backtrace: #0 grow_mini_window (w=3D0x1265ef0, delta=3D210, pixelwise=3Dtrue) at window.c:4488 #1 0x0000000000452c01 in resize_mini_window (w=3D0x1265ef0, exact_p=3Dtrue= ) at xdisp.c:10833 #2 0x0000000000426fb9 in do_switch_frame (frame=3D54632789, track=3D1, for_deletion=3D0, norecord=3D43920) at frame.c:1163 #3 0x000000000042718d in Fselect_frame (frame=3D54632789, norecord=3D43920= ) at frame.c:1225 #4 0x0000000000496566 in select_window (window=3D54633277, norecord=3D4392= 0, inhibit_point_swap=3Dfalse) at window.c:499 #5 0x00000000004967de in Fselect_window (window=3D54633277, norecord=3D439= 20) at window.c:575 #6 0x0000000000453fe7 in x_consider_frame_title (frame=3D54632789) at xdisp.c:11487 #7 0x0000000000454437 in prepare_menu_bars () at xdisp.c:11595 That's calling resize_mini_window *between* pre-redisplay-function and window-size-change-functions. I had not thought of that possibility. This was triggered by C-x C-e in an elisp buffer after "(read-from-minibuffer longstring)". 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. > But here you're using "next redisplay cycle" to mean the one that has not been started (redisplay() hasn't been called yet), not the one we're currently in. I had assumed your message referred to the state of Emacs as of HEAD, not with my proposed changes included. > 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 doe= s > its > > job. > > Yes, and that is not what you want because?... > Because the next call to redisplay() might not be until five seconds later. > 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). > That wasn't clear to me. If you're asking "will you shut up already if the changes you've already proposed go in", the answer is yes. So, in the hopes of finally clarifying matters: I want two things. 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. Wish #2: a way of knowing, in advance, that a window is going to be resized or moved, even temporarily, before any of that hits the X server. That would eliminate the (small) window left by #1 when the X server has been updated but redisplay hasn't been called again. 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. Wish #2 eliminates the race condition. > , 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 one I call "the current cycle"? 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'm still grateful for the warning, though. > > Moreover, the scenario where "prepare_menu_bars is > > called before auto-resizing the minibuffer window", and as result > > "=E2=80=98window-size-change-functions=E2=80=99 wouldn't catch thos= e auto-resizes", > > seems impossible. > > > > > > I don't think it's impossible, I think it's clearly happening to produc= e > 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. > Thanks for the warning. I verified with x_sync that the changes had been written to the glass. I think we agree on what's happening: 1. user input 2. redisplay called 3. prepare_menu_bars called, calls hooks. Hooks think nothing has changed. 4. grow_mini_window called, calculates new window size 5. update_frame is called, writes the new, enlarged mini-window to the glas= s 6. control returns to command loop 7. redisplay is called again 8. prepare_menu_bars called, calls hooks. Hooks notice mini-window has resized. Right? But there's no guarantee that there won't be intermediate commands executed between steps 6 and 7. In fact (progn (message "long message") (sleep 10.0)) will make step 8 happen ten seconds after the changed sizes have been written to the glass. Wish #2 would mean swapping steps 3 and 4. Thanks again, particularly for the warning about update_frame not doing anything, Pip --001a11c31f74d545ef051e511928 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 27, 2015 at 6:57 PM, Eli Z= aretskii <eliz@gnu.org> wrote:
&g= t; Date: Thu, 27 Aug 2015 16:35:44 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 21333@debbugs.gnu.org
>
>=C2=A0 =C2=A0 =C2=A0The call to grow/shrink_mini_window on= ly recomputes data
>=C2=A0 =C2=A0 =C2=A0about the windows for the next redisplay cycle.
>
> No. It computes data about the windows for the cycle that's curren= tly
> happening, that has already called prepare_menu_bars and will most lik= ely not
> do so again.

That's exactly what I said, just in other words.

I'm sorry, I totally misread that, then. I think o= f redisplay cycles as beginning when redisplay() is called and ending when it returns, so in my terminology the "next" redi= splay=20 cycle is the one that will happen after control briefly (or not so briefly,= see below) returns to the=20 command loop and redisplay() is called again. I don't insist on my term= inology, but I don't understand what yours is.

I unde= rstood "next redisplay cycle" to refer to the redisplay cycle for= which redisplay() has not yet been called, not the one for which redisplay= () has already been called.
=C2=A0
> 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.
Except when they're not, I've just seen this backtrace:=

#0=C2=A0 grow_mini_window (w=3D0x1265ef0, delta=3D210, pixelwise=3D= true) at window.c:4488
#1=C2=A0 0x0000000000452c01 in resize_mini_window= (w=3D0x1265ef0, exact_p=3Dtrue) at xdisp.c:10833
#2=C2=A0 0x00000000004= 26fb9 in do_switch_frame (frame=3D54632789, track=3D1, for_deletion=3D0, no= record=3D43920) at frame.c:1163
#3=C2=A0 0x000000000042718d in Fselect_f= rame (frame=3D54632789, norecord=3D43920) at frame.c:1225
#4=C2=A0 0x000= 0000000496566 in select_window (window=3D54633277, norecord=3D43920, inhibi= t_point_swap=3Dfalse) at window.c:499
#5=C2=A0 0x00000000004967de in Fse= lect_window (window=3D54633277, norecord=3D43920) at window.c:575
#6=C2= =A0 0x0000000000453fe7 in x_consider_frame_title (frame=3D54632789) at xdis= p.c:11487
#7=C2=A0 0x0000000000454437 in prepare_menu_bars () at xdisp.c= :11595

That's calling resize_mini_window *between* pre-redisplay-function and=20 window-size-change-functions. I had not thought of that possibility. This w= as triggered by C-x C-e in an elisp buffer after "(read-from-minibuffe= r longstring)".

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.

= But here you're using "next redisplay cycle" to mean the one = that has not been started (redisplay() hasn't been called yet), not the= one we're currently in.
=C2=A0
I had assumed y= our message referred to the state of Emacs as of HEAD, not with my proposed= changes included.

> The call order is that redisplay_internal calls prepare_menu_bars, the= n calls
> grow_mini_window, then performs the frame update. It doesn't go ba= ck to calling
> prepare_menu_bars, but it does call update_frame, and that actually do= es its
> job.

Yes, and that is not what you want because?...
=
Because the next call to redisplay() might not be until five= seconds later.

>=C2=A0 =C2=A0 =C2=A0When that next cycle comes, it will first call pre-= redisplay-function
>
> Yes. With a nil argument. I don't fully understand why.
>
>=C2=A0 =C2=A0 =C2=A0and window-size-change-functions
>
> No. Miniwindow resizes do not set the WINDOW_SIZES_CHANGED flag even i= f they
> resize other windows.

I was talking about the situation after you proposed changes, which<= br> will cause the flag to be set (AFAIU).

= That wasn't clear to me. If you're asking "will you shut up al= ready if the changes you've already proposed go in", the answer is= yes.

So, in the hopes of finally clarifying matters:
=
I want two things.
Wish #1: a way of knowing "when&= quot; windows are resized or moved, even temporarily. Whether that "wh= en" is "just before" or "just after" doesn't r= eally matter, but it should be one of those.
Wish #2: a way o= f knowing, in advance, that a window is going to be resized or moved, even = temporarily, before any of that hits the X server. That would eliminate the= (small) window left by #1 when the X server has been updated but redisplay= hasn't been called again.

Wish #1, assuming somethin= g 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.
<= br>
Wish #2 eliminates the race condition.

>=C2=A0 =C2=A0 =C2=A0, from prepare_menu_bars, and then, after the rest = of redisplay finishes,
>=C2=A0 =C2=A0 =C2=A0actually perform the X repaint, by
>=C2=A0 =C2=A0 =C2=A0calling 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 doe= s
not redisplay it.=C2=A0 The next cycle will.

The one I call "the current cycle"?

The function update_frame only reflects on the glass what its
redisplay cycle computed to be the desired display.=C2=A0 If redisplay
didn't recompute the window contents, update_frame will change
nothing.

That's not what I seeing r= unning x_sync manually. I'm still grateful for the warning, though.
=
=C2=A0
>=C2=A0 =C2=A0 =C2=A0Moreover, the scenario where "prepare_menu_bar= s is
>=C2=A0 =C2=A0 =C2=A0called before auto-resizing the minibuffer window&q= uot;, and as result
>=C2=A0 =C2=A0 =C2=A0"=E2=80=98window-size-change-functions=E2=80= =99 wouldn't catch those auto-resizes",
>=C2=A0 =C2=A0 =C2=A0seems impossible.
>
>
> I don't think it's impossible, I think it's clearly happen= ing to produce the
> breakpoint order that I'm seeing. (This is speculation, but I thin= k 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<= br> redisplay a specific window, or any window.=C2=A0 The fact that
update_frame was called doesn't necessarily mean that anything at all was written to the glass.=C2=A0 These functions have a lot of optimizations=
in them, and try to avoid doing stuff if they think it isn't
necessary.=C2=A0 You need to trace into the functions' guts to see if t= hey
actually update anything.=C2=A0 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.=C2=A0 That function is the last line of
defense against redisplaying the same stuff over and over again.

Thanks for the warn= ing. I verified with x_sync that the changes had been written to the glass.=

I think we agree on what's hap= pening:

1. user input
2. redisplay called
3. prepare_menu_bars called, calls hooks. Hooks think nothing has chang= ed.
4. grow_mini_window called, calcula= tes new window size
5. update_frame is = called, writes the new, enlarged mini-window to the glass
6. control returns to command loop
7. redisplay is called again
8. prepare_menu_bars called, calls hooks. Hooks notice mini-window h= as resized.

Right?

But there's no guarantee that there won't b= e intermediate commands executed between steps 6 and 7. In fact (progn (mes= sage "long message") (sleep 10.0)) will make step 8 happen ten se= conds after the changed sizes have been written to the glass.

=
Wish #2 would mean swapping steps 3 and 4.

Thanks again, particularly for the warning about update_frame= not doing anything,
Pip
--001a11c31f74d545ef051e511928--