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 16:35:44 +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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b874bbe0b4f76051e4d8f67 X-Trace: ger.gmane.org 1440693398 15462 80.91.229.3 (27 Aug 2015 16:36:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2015 16:36:38 +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 18:36:23 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 1ZV09x-00013t-J1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 18:36:17 +0200 Original-Received: from localhost ([::1]:43619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV09s-0007Ol-0h for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 12:36:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV09m-0007Kr-4n for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 12:36:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV09i-0000D8-T7 for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 12:36:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV09i-0000CU-Pu for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 12:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZV09i-00029W-D6 for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 12:36:02 -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 16:36: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.14406933488253 (code B ref 21333); Thu, 27 Aug 2015 16:36:02 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 16:35:48 +0000 Original-Received: from localhost ([127.0.0.1]:40460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV09T-000292-Ib for submit@debbugs.gnu.org; Thu, 27 Aug 2015 12:35:48 -0400 Original-Received: from mail-ig0-f171.google.com ([209.85.213.171]:38178) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV09R-00028u-8f for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 12:35:46 -0400 Original-Received: by ignq3 with SMTP id q3so13141724ign.1 for <21333@debbugs.gnu.org>; Thu, 27 Aug 2015 09:35:44 -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=qER95Oaz2fc1ftQRuphPpoeYxDykiQzBom5BcMoy65s=; b=z+e3vzhYnMX05h+W9/O56rBwJFoCGeE9PVKsktt9etgeKTDagV5deFJ0sSXTAxEC1e koxtS0Xvh0MEqQArZSugMHil/I85lvcvHkeDID702Toip4Yotr+xLs7vzFyCgBK5Vq/2 CMb2EYtEj6mLfL6AXp2mKlbcKylZI+aXRhBTVaj6Ipx4T1GTD7Onl16RNnt39WINwE+R kKyRtV5yP3/Q1/cI4MwmBBB8r5FetAVMDXxg6kKueRhX3yuC40Lj2G7ATqZqn4W/mMMW uGKmobEYNpEXyAEpstCY7I8dmW3EgZSiq26HVUG9ruzjSe8wpn3xolwEoNgbDKCiQz/X jglA== X-Received: by 10.50.120.9 with SMTP id ky9mr181269igb.61.1440693344749; Thu, 27 Aug 2015 09:35:44 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Thu, 27 Aug 2015 09:35:44 -0700 (PDT) In-Reply-To: <83bnds69e8.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:105879 Archived-At: --047d7b874bbe0b4f76051e4d8f67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 3:25 PM, Eli Zaretskii wrote: > > Date: Thu, 27 Aug 2015 09:59:04 +0200 > > From: martin rudalics > > CC: Eli Zaretskii , 21333@debbugs.gnu.org > > > > >>> - wishlist item: call pre-redisplay-function between > > >>> grow/shrink_mini_window and the actual X repaint, rather than befor= e. > > >> > > >> Are you sure? If prepare_menu_bars is called before auto-resizing t= he > > >> minibuffer window, then =E2=80=98window-size-change-functions=E2=80= =99 wouldn't catch > > >> those auto-resizes either. > > > > > > That's why I consider it "wishlist". My Christmas wish is to be told > > > whenever the X rectangle corresponding to my Emacs window has changed= , > just > > > before the X server is told about the change. > > > > I still don't understand: Do you mean that =E2=80=98pre-redisplay-funct= ion=E2=80=99 is > > called in the wrong place? Where else would you call it? > > I don't understand much more, it seems: the original wishlist > feature. > 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. Note that grow_mini_window is called by redisplay_internal, via resize_mini_window, not just by display_echo_area. 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=3D0x12676a0, delta=3D15, pixelwise=3Dtru= e) at window.c:4491 Breakpoint 12, redisplay_internal () at xdisp.c:13310 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. If I stop just before the second redisplay_internal and x_sync(), the screen will be in a mildly inconsistent state. 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. window-size-change-functions won't be called on the next redisplay, and it might not be called again for a very long time. > , 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. Breakpoint 14, redisplay_internal () at xdisp.c:13310 Breakpoint 10, prepare_menu_bars () at xdisp.c:11558 Breakpoint 11, grow_mini_window (w=3D0x12676a0, delta=3D15, pixelwise=3Dtru= e) at window.c:4491 Breakpoint 15, update_frame (f=3D0x319fa40, force_p=3Dfalse, inhibit_hairy_id_p=3Dfalse) at dispnew.c:3055 Breakpoint 15, update_frame (f=3D0x30a6070, force_p=3Dfalse, inhibit_hairy_id_p=3Dfalse) at dispnew.c:3055 Breakpoint 15, update_frame (f=3D0x313cc58, force_p=3Dfalse, inhibit_hairy_id_p=3Dfalse) at dispnew.c:3055 Breakpoint 15, update_frame (f=3D0x12ac950, force_p=3Dfalse, inhibit_hairy_id_p=3Dfalse) at dispnew.c:3055 Breakpoint 14, redisplay_internal () at xdisp.c:13310 > So it sounds like the wish has been granted already, no? If 1. I use pre-redisplay-function, not pre-redisplay-functions or window-size-change-functions 2. I ignore its arguments and check all windows 3. I don't mind that one X update has already happened with the new sizes immediately beforehand I get the behavior I want (modulo point 3). That's empirical, with the code that I posted that makes a window display its current size. > 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 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). --047d7b874bbe0b4f76051e4d8f67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 3:25 PM, Eli Zaretskii &= lt;eliz@gnu.org> wrote:
> Date= : Thu, 27 Aug 2015 09:59:04 +0200
> From: martin rudalics <rudalics@= gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org= >, 21333@debbugs.gnu.org >
> >>>=C2=A0 =C2=A0 - wishlist item: call pre-redisplay-function= between
> >>> grow/shrink_mini_window and the actual X repaint, rather = than before.
> >>
> >> Are you sure?=C2=A0 If prepare_menu_bars is called before aut= o-resizing the
> >> minibuffer window, then =E2=80=98window-size-change-functions= =E2=80=99 wouldn't catch
> >> those auto-resizes either.
> >
> > That's why I consider it "wishlist". My Christmas w= ish is to be told
> > whenever the X rectangle corresponding to my Emacs window has cha= nged, just
> > before the X server is told about the change.
>
> I still don't understand: Do you mean that =E2=80=98pre-redisplay-= function=E2=80=99 is
> called in the wrong place?=C2=A0 Where else would you call it?

I don't understand much more, it seems: the original wishlist feature.=C2=A0
=C2=A0
The call to grow/shrink_mini_window only recomputes dat= a
about 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 like= ly not do so again. Note that grow_mini_window is called by redisplay_inter= nal, via resize_mini_window, not just by display_echo_area.

If you s= et breakpoints on prepare_menu_bars, grow_mini_window, and redisplay_intern= al, the log is:

Breakpoint 12, redisplay_internal () at xdisp.c:1331= 0
Breakpoint 10, prepare_menu_bars () at xdisp.c:11558
Breakpoint 11,= grow_mini_window (w=3D0x12676a0, delta=3D15, pixelwise=3Dtrue) at window.c= :4491
Breakpoint 12, redisplay_internal () at xdisp.c:13310

The call order is that redisplay_internal calls prepare_me= nu_bars, then calls grow_mini_window, then performs the frame update. It do= esn't go back to calling prepare_menu_bars, but it does call update_fra= me, and that actually does its job. If I stop just before the second redisp= lay_internal and x_sync(), the screen will be in a mildly inconsistent stat= e.

and window-size-change-functions

No. Miniwindow resizes do not set the WINDOW_SIZES_CHANGED flag even = if they resize other windows. window-size-change-functions won't be cal= led on the next redisplay, and it might not be called again for a very long= time.
=C2=A0
, 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.

Breakpoint 14, redisplay_internal () at xdisp.c:13310<= br>Breakpoint 10, prepare_menu_bars () at xdisp.c:11558
Breakpoint 11, g= row_mini_window (w=3D0x12676a0, delta=3D15, pixelwise=3Dtrue) at window.c:4= 491
Breakpoint 15, update_frame (f=3D0x319fa40, force_p=3Dfalse, inhibit= _hairy_id_p=3Dfalse) at dispnew.c:3055
Breakpoint 15, update_frame (f=3D= 0x30a6070, force_p=3Dfalse, inhibit_hairy_id_p=3Dfalse) at dispnew.c:3055Breakpoint 15, update_frame (f=3D0x313cc58, force_p=3Dfalse, inhibit_hair= y_id_p=3Dfalse) at dispnew.c:3055
Breakpoint 15, update_frame (f=3D0x12a= c950, force_p=3Dfalse, inhibit_hairy_id_p=3Dfalse) at dispnew.c:3055
Bre= akpoint 14, redisplay_internal () at xdisp.c:13310
=C2=A0
So it sounds like the wish has= been granted already, no?

If
1. I use pre-= redisplay-function, not pre-redisplay-functions or window-size-change-funct= ions
2. I ignore its arguments and check all windows
3. I don't mind that one X update has already happened with the n= ew sizes immediately beforehand

I get the behavior I want= (modulo point 3). That's empirical, with the code that I posted that m= akes a window display its current size.
=C2=A0
=C2=A0 Moreover, the scenario wher= e "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 tho= se auto-resizes",
seems impossible.

I don't think it&= #39;s impossible, I think it's clearly happening to produce the breakpo= int order that I'm seeing. (This is speculation, but I think my call or= der only applies to minibuffer window resizes, as stated above, not echo ar= ea resizes triggered by message3. That might be wrong, though).
--047d7b874bbe0b4f76051e4d8f67--