From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 18:06:54 2015 Received: (at submit) by debbugs.gnu.org; 23 Aug 2015 22:06:54 +0000 Received: from localhost ([127.0.0.1]:36268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTdPh-0005um-KH for submit@debbugs.gnu.org; Sun, 23 Aug 2015 18:06:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47272) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTdPf-0005uc-J8 for submit@debbugs.gnu.org; Sun, 23 Aug 2015 18:06:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTdPd-0005hV-Sg for submit@debbugs.gnu.org; Sun, 23 Aug 2015 18:06:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTdPd-0005hR-QP for submit@debbugs.gnu.org; Sun, 23 Aug 2015 18:06:49 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTdPc-0000c6-Ct for bug-gnu-emacs@gnu.org; Sun, 23 Aug 2015 18:06:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTdPa-0005eq-Tu for bug-gnu-emacs@gnu.org; Sun, 23 Aug 2015 18:06:48 -0400 Received: from mail-ig0-x235.google.com ([2607:f8b0:4001:c05::235]:35714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTdPa-0005ea-Mj for bug-gnu-emacs@gnu.org; Sun, 23 Aug 2015 18:06:46 -0400 Received: by igbjg10 with SMTP id jg10so48073793igb.0 for ; Sun, 23 Aug 2015 15:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CzHsJZ/8yuaEM0OSZEKqqnhWpBcfGx2ODr9lwGzPFWA=; b=tnzRIRO0hFZ9e5r+1R3cS6MHiZKaOmkkvq6tO7+KtLsXjrZ+YaxHdZ/9s3wtAXOEVw dDfAGJ/8u0KpVYTzZL0b7J+b6DXQ+fYIFE9eHQwYRcECPDX1+mRxSWvjvCBa3D6J0913 6Lez8NYknGxxCyIK06wXKPaZP0U1SjqK+tQpdZ6NGTXG8kYclO05lB1DmZBP5YyLm8vN UOIT/Z7KqufqCSIfDASPbDHEIcleibH1MopjhA6P8hUIEbmi60yFWByrTGxu2PsJuheU Ng4I73MI1/LDA0tJIe/ZwJX/6bto06ZWRkPlk69Jjos4SRx0F3dqqooaixuOt91OTnBA mjNw== MIME-Version: 1.0 X-Received: by 10.50.62.193 with SMTP id a1mr11378495igs.61.1440367605900; Sun, 23 Aug 2015 15:06:45 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 23 Aug 2015 15:06:45 -0700 (PDT) Date: Sun, 23 Aug 2015 22:06:45 +0000 Message-ID: Subject: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary=047d7bd753707f1e2a051e01b78d X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7bd753707f1e2a051e01b78d Content-Type: text/plain; charset=UTF-8 This is possibly only a documentation issue. Recipe: eval (progn (push (lambda (&rest args) (message "window size changed")) window-size-change-functions) (message (make-string 3000 ?*))) Expected result: a "window size changed" message. Actual result: no such message. The symptom is that the window size change function is not run after a mini-window size change. So far, I can produce this behavior only when the minibuffer or echo area grows to several lines; when it shrinks afterwards, my window size change function is called. I cannot reproduce the behavior with other windows. Is this a bug? The documentation says: [...] to be called if the size of any window changes for any reason. Please correct me if I'm wrong, but when the minibuffer/echo area gets resized (and the windows on top of it, too), that counts as a change of size, I would say. If this is merely a documentation issue, the exception should be noted in the manual. Analysis: First, some warnings: - `window_resize_apply' and `Fwindow_resize_apply' (aka `window-resize-apply') are two different functions - `resize-mini-window' and `resize-mini-window-internal' are called only when the mini-window is explicitly resized by a Lisp call of `resize-mini-window'. Implicit resizes as a consequence of having too much text in the echo area do not appear to call it. The problem is that FRAME_WINDOW_SIZES_CHANGED (f) is not set to true after a mini-window resize. Fwindow_resize_apply would set this flag, but window_resize_apply does not. If this behavior is deliberate, I believe it is inconsistent to set FRAME_WINDOW_SIZES_CHANGED (f) in `resize-mini-window-internal'. Suggested solution: Trivial. Add FRAME_WINDOW_SIZES_CHANGED (f) = true to all callers of window_resize_apply. In GNU Emacs 25.0.50.51 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of 2015-08-23 on ... Repository revision: bfb06826feac9151877069590d5dc91b60337b6b Windowing system distributor `The X.Org Foundation', version 11.0.11702000 System Description: Debian GNU/Linux unstable (sid) Configured using: `configure 'CFLAGS=-O0 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr mail-utils misearch multi-isearch time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 81668 9633) (symbols 48 19040 0) (miscs 40 42 136) (strings 32 13288 4444) (string-bytes 1 380166) (vectors 16 11279) (vector-slots 8 414205 3702) (floats 8 131 186) (intervals 56 190 0) (buffers 976 11) (heap 1024 18666 1015)) --047d7bd753707f1e2a051e01b78d Content-Type: text/x-patch; charset=US-ASCII; name="0001-Call-window-size-change-functions-after-mini-window-.patch" Content-Disposition: attachment; filename="0001-Call-window-size-change-functions-after-mini-window-.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idp1mnsv0 RnJvbSAyNDNiZTcwMDU5MTk3OTU1NGU2MWJiZGZmMGYwMGYzMGNjMzg2ZjdiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFN1biwg MjMgQXVnIDIwMTUgMjE6NDY6NDIgKzAwMDAKU3ViamVjdDogW1BBVENIXSBDYWxsIGB3aW5kb3ct c2l6ZS1jaGFuZ2UtZnVuY3Rpb25zJyBhZnRlciBtaW5pLXdpbmRvdyBzaXplCiBjaGFuZ2VzLgoK CSogd2luZG93LmMgKHJlc2l6ZV9mcmFtZV93aW5kb3dzKTogU2V0CglGUkFNRV9XSU5ET1dfU0la RVNfQ0hBTkdFRCBmbGFnLiAgKGdyb3dfbWluaV93aW5kb3cpOgoJTGlrZXdpc2UuICAoc2hyaW5r X21pbmlfd2luZG93KTogTGlrZXdpc2UuCi0tLQogc3JjL3dpbmRvdy5jIHwgMyArKysKIDEgZmls ZSBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9zcmMvd2luZG93LmMgYi9z cmMvd2luZG93LmMKaW5kZXggODYzYTc5Mi4uNjhiYzllNSAxMDA2NDQKLS0tIGEvc3JjL3dpbmRv dy5jCisrKyBiL3NyYy93aW5kb3cuYwpAQCAtNDA5NCw2ICs0MDk0LDcgQEAgcmVzaXplX2ZyYW1l X3dpbmRvd3MgKHN0cnVjdCBmcmFtZSAqZiwgaW50IHNpemUsIGJvb2wgaG9yZmxhZywgYm9vbCBw aXhlbHdpc2UpCiAgICAgfQogCiAgIGZzZXRfcmVkaXNwbGF5IChmKTsKKyAgRlJBTUVfV0lORE9X X1NJWkVTX0NIQU5HRUQgKGYpID0gdHJ1ZTsKIH0KIAogCkBAIC00NTMxLDYgKzQ1MzIsNyBAQCBn cm93X21pbmlfd2luZG93IChzdHJ1Y3Qgd2luZG93ICp3LCBpbnQgZGVsdGEsIGJvb2wgcGl4ZWx3 aXNlKQogCSAgLyogRW5mb3JjZSBmdWxsIHJlZGlzcGxheSBvZiB0aGUgZnJhbWUuICAqLwogCSAg LyogRklYTUU6IFNob3VsZG4ndCB3aW5kb3ctLXJlc2l6ZS1yb290LXdpbmRvdy12ZXJ0aWNhbGx5 IGRvIGl0PyAgKi8KIAkgIGZzZXRfcmVkaXNwbGF5IChmKTsKKwkgIEZSQU1FX1dJTkRPV19TSVpF U19DSEFOR0VEIChmKSA9IHRydWU7CiAJICBhZGp1c3RfZnJhbWVfZ2x5cGhzIChmKTsKIAkgIHVu YmxvY2tfaW5wdXQgKCk7CiAJfQpAQCAtNDU3MCw2ICs0NTcyLDcgQEAgc2hyaW5rX21pbmlfd2lu ZG93IChzdHJ1Y3Qgd2luZG93ICp3LCBib29sIHBpeGVsd2lzZSkKIAkgIC8qIEVuZm9yY2UgZnVs bCByZWRpc3BsYXkgb2YgdGhlIGZyYW1lLiAgKi8KIAkgIC8qIEZJWE1FOiBTaG91bGRuJ3Qgd2lu ZG93LS1yZXNpemUtcm9vdC13aW5kb3ctdmVydGljYWxseSBkbyBpdD8gICovCiAJICBmc2V0X3Jl ZGlzcGxheSAoZik7CisJICBGUkFNRV9XSU5ET1dfU0laRVNfQ0hBTkdFRCAoZikgPSB0cnVlOwog CSAgYWRqdXN0X2ZyYW1lX2dseXBocyAoZik7CiAJICB1bmJsb2NrX2lucHV0ICgpOwogCX0KLS0g CjIuNS4wCgo= --047d7bd753707f1e2a051e01b78d-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 04:19:03 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 08:19:03 +0000 Received: from localhost ([127.0.0.1]:36483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTmy7-0004md-6m for submit@debbugs.gnu.org; Mon, 24 Aug 2015 04:19:03 -0400 Received: from mout.gmx.net ([212.227.15.18]:52113) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTmy5-0004mN-S5 for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 04:19:02 -0400 Received: from [62.47.255.61] ([62.47.255.61]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3AWN-1Ydc1L46aN-00swxx; Mon, 24 Aug 2015 10:19:01 +0200 Message-ID: <55DAD373.7070700@gmx.at> Date: Mon, 24 Aug 2015 10:18:59 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet , 21333@debbugs.gnu.org Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cXKemnAkoP/AqFXgrpE+OPyFlMGNypUFE4vyBg/jNOGSgCM+MgM Bq0wmh9iOh+tJxCYjV6nigq2TBHULt/t7AwwWrUhJHS3PK4cvYvnzJeHFYLj8+qHan+rILF sSYcjfToVMK5XZhpQ0sT72xmwOYlg5UI33HfgaKO+y5Sivn2xPNYgmGvFOjA7pFoinoeirL E43vtML+rAeACIWqJOPLw== X-UI-Out-Filterresults: notjunk:1;V01:K0:CGMWq+mNvq0=:RLDiXl3SX1dgp9pbBS0afD 1/29zYfOVfTIsOz9Qw1EWRF7zA1LFc7NEgtQ3nilEXPuVevGe+2Ojg4W3zIIcnFG97SZhbqan 0IeN/A6YasT+3N6TcvQuvr2rE8WZOVmlE9jucEMgsko9IcZzZF7J8TJWwlVs/JBMBc6ogCBR7 gFD4zjEesJrNTOv0fHP+JYiqhIZKkC+OzWt1R9x1VLzXRNbhzwOcaxbtfwGeGfxl5X0XdBfRY vSCglIbw728/EaMxb4BllZ+FpvTblFYKsVlBjHQDgNSkCDqnfOFwZWQVjsfYRVYST021tAnU3 GaAC6qLXNXL7Z654oYrE+e6qU2yeA0phIftU51DuT3Mi9I7ugxpJ0dTDE2uredxLe4qY8uKkf qXjuuqTVz4DezDlchAwshoWuNaAv0WPRHaaP3GdAx+nJY17Npvr5YRAwvZnNEal+Rs1KZb3L9 nEW5vLkr47bzjzGnGlgtaq1B2CzD8xM/nY/AmcRIeDbsRR0x53V6Gv4dL5H3IG6UZhDTKGH7j S2SAO2CxdlkXaDoLd8/eteqJkUtiD7aHhyiwCbQbbsKvNZCzKliT2/VDlO0/hACxwxoU/LMxD eItPx+D5WCl6fJBCU5qQ9Vene0xclM8RJp0elXEtsrAC5R0HNZLbZQutB76OFRn6giAOVBfTF byyMVNpM30E8uajN5xvpofjZ9clqyYdddPk4b3FRDBOu/ilqCOFQnlVCzzZ/U2rLpy3YLF9wf t6GNV932PpwmTutEBRYO+6hojr0l1ZSISPXWFA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > This is possibly only a documentation issue. > > Recipe: eval > (progn (push (lambda (&rest args) (message "window size changed")) > window-size-change-functions) > (message (make-string 3000 ?*))) > > Expected result: a "window size changed" message. > > Actual result: no such message. > > > The symptom is that the window size change function is not run after a > mini-window size change. > > So far, I can produce this behavior only when the minibuffer or echo > area grows to several lines; when it shrinks afterwards, my window size > change function is called. I cannot reproduce the behavior with other > windows. > > Is this a bug? The documentation says: > > [...] to be called if the size of any window changes for any reason. > > Please correct me if I'm wrong, but when the minibuffer/echo area gets > resized (and the windows on top of it, too), that counts as a change of > size, I would say. > > If this is merely a documentation issue, the exception should be noted > in the manual. Looks like bug #830 23.0.60; window-size-change-functions sometimes not called in action. > Analysis: > First, some warnings: > - `window_resize_apply' and `Fwindow_resize_apply' (aka > `window-resize-apply') are two different functions > - `resize-mini-window' and `resize-mini-window-internal' are called > only when the mini-window is explicitly resized by a Lisp call of > `resize-mini-window'. Implicit resizes as a consequence of having > too much text in the echo area do not appear to call it. > > The problem is that FRAME_WINDOW_SIZES_CHANGED (f) is not set to true > after a mini-window resize. Fwindow_resize_apply would set this flag, > but window_resize_apply does not. > > If this behavior is deliberate, I believe it is inconsistent to set > FRAME_WINDOW_SIZES_CHANGED (f) in `resize-mini-window-internal'. > > > Suggested solution: > > Trivial. Add FRAME_WINDOW_SIZES_CHANGED (f) = true to all callers of > window_resize_apply. Your patch looks fine to me. I'd suggest to postpone installing it until your paperwork is complete. OK? Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 07:08:20 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 11:08:20 +0000 Received: from localhost ([127.0.0.1]:36539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTpbv-0000EP-SV for submit@debbugs.gnu.org; Mon, 24 Aug 2015 07:08:20 -0400 Received: from mail-ig0-f196.google.com ([209.85.213.196]:34147) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTpbt-0000EH-No for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 07:08:18 -0400 Received: by igdx6 with SMTP id x6so7289356igd.1 for <21333@debbugs.gnu.org>; Mon, 24 Aug 2015 04:08:17 -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=vqyfaU0MT7alLxJxmrAOmHkxHGn9BhW29dxYhabXKME=; b=J5uh6kHU2EKx4I2miJw7hNFSTY3xWAEgriXoYlClRgEevvoY1jph/hT/WhpCuovA+4 1mOj79S6XYAYkapktQvMf5H9t3ZYkzVR74Y33YwL0rZOYSg9LDkQ1lKC4PNNR4QIDTof iUBI2r9KH7PaAptgfN4U7TY0Qlk1px1R0ZCxwmpwznVfAWrp3XzMVeickouE73zwseNf zMlO+vbOHCo8MAwRGHStnIsBpcrfrD0jBBpnjiv4bPuFrB7Ln6jWJWDE9bwIXEoczekO 4Y8gksAQiiCXqIGOrxyyhkMaYyz+4XuX/hvthAdV1/torDRSjTodQLcf3SKOfKA3b1fP NwzA== MIME-Version: 1.0 X-Received: by 10.50.62.193 with SMTP id a1mr12948733igs.61.1440414497329; Mon, 24 Aug 2015 04:08:17 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Mon, 24 Aug 2015 04:08:17 -0700 (PDT) In-Reply-To: <55DAD373.7070700@gmx.at> References: <55DAD373.7070700@gmx.at> Date: Mon, 24 Aug 2015 11:08:17 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Mon, Aug 24, 2015 at 8:18 AM, martin rudalics wrote: > Looks like bug #830 > > 23.0.60; window-size-change-functions sometimes not called > > in action. Agreed, that appears to be the same bug. (I appear to have searched for window-size-changed-functions when reporting this, not window-size-change-functions). I don't know what the Emacs policy is on merging bug reports, but we probably should. > Your patch looks fine to me. I'd suggest to postpone installing it until > your paperwork is complete. OK? Absolutely. I must admit I was expecting a discussion first, so I decided to send this right away to get it over with :-) Thank you, Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 08:11:18 2015 Received: (at control) by debbugs.gnu.org; 24 Aug 2015 12:11:18 +0000 Received: from localhost ([127.0.0.1]:36558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTqas-0003Cz-Ge for submit@debbugs.gnu.org; Mon, 24 Aug 2015 08:11:18 -0400 Received: from mout.gmx.net ([212.227.15.15]:55457) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTqaq-0003Cr-8A for control@debbugs.gnu.org; Mon, 24 Aug 2015 08:11:17 -0400 Received: from [178.190.19.2] ([178.190.19.2]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MAgzj-1ZZeHI10kF-00BrYT for ; Mon, 24 Aug 2015 14:11:15 +0200 Message-ID: <55DB09E1.8020500@gmx.at> Date: Mon, 24 Aug 2015 14:11:13 +0200 From: martin rudalics MIME-Version: 1.0 To: control@debbugs.gnu.org Subject: merge bugs 830 and 21333 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bbkfdkpSqWbq2+leNjAmkA7gg17wP+8j5UpzAkrDj1yAGFWqPrP 7o/2O09I+xnOF9avl7V8u9KUti5Rmtx94GdCHf2DQEUnEUgs8N6dO+NUpatyErHjgmDmMlP JduHyX0I1HhxSYBmZ8qQ4luP7WcvLgKSrt3v36AjTyzMYbdyMdJS+Lp3byE6k44mvrWgyNQ sUcPAvhEZcFtH/kFULseQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:+0UfpONyVcM=:ryQ73vLxTO6ieyuv4j5b3Y 8/TtKqey8ODjRirBxO3FpaPkVjj1b1Zv451v50dvE/cK6A66owbPRceExqAoaHty8lOQkNHwZ xLRIzlUPH8HxlujPZfy7UqDT4DdNErq33mI7l//lTdC2jFh8puVIbYWyybPNNEJznX55+XZOQ A3gc22L2KR/B8XyUxgnAvSJ0wycpS8T/abwJqAHOKerPl71AeTsMDfG7cHF3jKp15aEJqI+56 kqqrtQFSH+5xVAKx4G8wYW0gtS0tW9W7KUhcOLInUpeffXHzNQvDbJ3yH55Yg8tlEsF6OlWw0 bUNosaHJoGSbk5g+rysOL0XNSWP0RLdijS1aMm+gBYouKqxF+Tu/9bAwQAb3A2LmEQ7718M2k PvMhbJW9sHIwdoma0reokR2XeUMPcr7SbxVQFikaUUJHiP3grSDHey+LrEm0Pp9CEfett6ffV Wj0/mSpNvvNSSywWt9TiykN3magMBkcCGiNngkcL3kRLfgv8k24E/bzQhVyOIEQklusZxTh23 nwurD6RaGG5UyqDBMk0o6oA7Pod4c80TAQdeuAjuu3r6ZY7g/VlRJhQqP50TdrI49tLGFtWsk FmPNYjUUR5lmL0fhMC71p8cFjmO4CpBwKtUloK+C/bLvG3jHV+Z8JyugPfETYDGkosxf1AAXy +k/OTd2t4pa9jr1yFa72jGK/1TzGGzNlz1CA7TgV/Emcal+98A2WXv/IDrlK/8kPN7PK34Xmj nTv9g32SaJpvV+qNToiEbcsmP+6FVvzrGeimOw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) merge 830 21333 From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 08:41:17 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 12:41:17 +0000 Received: from localhost ([127.0.0.1]:36569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTr3s-0005RY-I8 for submit@debbugs.gnu.org; Mon, 24 Aug 2015 08:41:16 -0400 Received: from mout.gmx.net ([212.227.15.18]:59018) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTr3p-0005RP-OU for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 08:41:14 -0400 Received: from [178.190.19.2] ([178.190.19.2]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MCLcP-1ZcPlZ0RNZ-009CL8; Mon, 24 Aug 2015 14:41:12 +0200 Message-ID: <55DB10E5.4030200@gmx.at> Date: Mon, 24 Aug 2015 14:41:09 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <55DAD373.7070700@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:nRVeiTUkRA1tFMczdG3jl1ZcysLShm8uG18/nNZe5zuLCXIMb7c iWAmDrFYq4OcRUnxgJofeVZsv4sdkEY0ro7Rz4FeMdlwEUt4kL2ptoFJNhJSZrUZ9Q+iwPe igK3c1/mP5f62wZtONFCXI+NU5TdLMeuy5MzoplKP7Rx4/U6Qt65jkBnpHDlfBUcXcswNwx rUzaT4tOMXtRNfwHW2B5g== X-UI-Out-Filterresults: notjunk:1;V01:K0:QMHAGM7b6S0=:WUB4n4GGQxjD3uDEXJk1DX eHxkuSqO4kNcYMo6nuDJ+bDTNXF6a6KY8rwGmm7E0ETMunR02fQ3XHvAOUbwsjeLznizBYgUC Wanvjy7Ua2EZFVaqrfmA9YOLZLm+hSywOq0hQVilr/21PMtD+1Rovls0OsrLWYmQ756ZJZskF /Po9nacO/GOX83MWFfhjk/6eknS/85HpkDWgAkMqqJsrL1Y7oBNQPuL+L8qKChOb8gOFqB/O2 Abt93Eppva6UjgGnlyReHQ/rK1EqXoXTf3YGNjZFtPTJEOdVuzKISBqeTdQG8dMmEFLDXvn4i qQ4sujrGVK0GUHc/iuXr35yiIDpgBXc+5RSea25uDiwD2xAHsqPItRk8OcV1sVQZwkNbLoXWE QHZWvTInOeKdrR42MpQV8D/xJQlDHA7QzOkhYo+A5pdT2+0I6vFy8LEuSDFx5gI17ZvwShmgx HUJblNOl3z0mJ3B8eSgpaykEDIsqDg3Y71KQAqnbKU9oRfP0St3+Etfac0lh6x094eT4IuvUG Qwzsoh+UDQ3hl7njB4sWxNL6pvLfZMBH1Cq6mUs7T1pezB0SDw++kGzSSpPuKIJHHVnosBOdb QQAwk6AuSHlUbd+nyAwHvfa/H5vdLERLpFcHCP1FNfb6nAKt+6VzeMhTvsTfpGnyaBt3o0VH0 5bjIFSSwwKm4ggU/XtNdfWex8tj+yHF8ZqyRa3yCGZtcoB9k5DsaKxF9/PPP5INWuc/u8DRvL XbiKyj/p5tT/4+gnPNeAVI3sHFfOtaJZrLe8CQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Looks like bug #830 >> >> 23.0.60; window-size-change-functions sometimes not called >> >> in action. > > Agreed, that appears to be the same bug. (I appear to have searched > for window-size-changed-functions when reporting this, not > window-size-change-functions). I don't know what the Emacs policy is > on merging bug reports, but we probably should. I just merged them. `window-size-change-functions' is a Cinderella of our hooks. Nobody really knows when it should be used, me included. Markus considered it necessary for =E2=80=98linum-mode=E2=80=99 but appar= ently changed his mind later. The only "real" user is probably =E2=80=98follow-mode=E2= =80=99. >> Your patch looks fine to me. I'd suggest to postpone installing it u= ntil >> your paperwork is complete. OK? > > Absolutely. I must admit I was expecting a discussion first, so I > decided to send this right away to get it over with :-) It might be worth pursuing the simpler solution to set FRAME_WINDOW_SIZES_CHANGED "only" in window_resize_apply because conceptually _all_ window size changes "must" pass through that function. I never checked the truth of that "must" but am quite confident that anything else would result in a bug. There is one prominent exception from this rule - `delete-other-windows' when the sole remaining window is a leaf window. That was my last remedy when I tested the resize code and `window-resize-apply' failed for whatever reason. C-x 1 reliably got me out of that mess. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 10:37:01 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 14:37:02 +0000 Received: from localhost ([127.0.0.1]:37054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTsrs-0008Bt-TU for submit@debbugs.gnu.org; Mon, 24 Aug 2015 10:37:01 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:33498) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTsrp-0008Bj-V4 for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 10:36:59 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NTL00L00BYXWC00@mtaout24.012.net.il> for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 17:28:00 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTL00GTYC6OP660@mtaout24.012.net.il>; Mon, 24 Aug 2015 17:28:00 +0300 (IDT) Date: Mon, 24 Aug 2015 17:35:46 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83k2skhhz1.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 23 Aug 2015 22:06:45 +0000 > From: Pip Cet > > This is possibly only a documentation issue. Possibly. > Recipe: eval > (progn (push (lambda (&rest args) (message "window size changed")) > window-size-change-functions) > (message (make-string 3000 ?*))) > > Expected result: a "window size changed" message. > > Actual result: no such message. > > The symptom is that the window size change function is not run after a > mini-window size change. Note that resizing the mini-window involves resizing of at least one other window on the same frame. So this is not exactly about the mini-window. > So far, I can produce this behavior only when the minibuffer or echo > area grows to several lines; when it shrinks afterwards, my window size > change function is called. I don't see the message even when the mini-window shrinks back. Are you sure the message you see is not triggered by some other event? It's way too easy to trigger it, see below. > I cannot reproduce the behavior with other windows. See above: at least one other window is resized in this recipe, so the exemption is not about the mini-window itself, it's about any window involved in resizing in this particular scenario. > Is this a bug? The documentation says: > > [...] to be called if the size of any window changes for any reason. > > Please correct me if I'm wrong, but when the minibuffer/echo area gets > resized (and the windows on top of it, too), that counts as a change of > size, I would say. I believe the original reason for this is largely historical: window-size-change-functions exists since Emacs 19.29, whereas automatic resizing of mini-window was introduced in Emacs 21. Since Emacs before 21 didn't have the mini-window resizing functionality, Emacs 21 was careful not to gratuitously trigger these functions by something that is purely a new redisplay feature. That said, I wonder whether changing the code now to call these functions due to automatic resizing would make sense. What would be the real-life use cases for using that? I believe window-size-change-functions is meant for taking notice of resizes done by the user or some Lisp code, not for automated resizes whose sole purpose is to allow some message be read in its entirety. If you agree, then the current behavior will make sense to you. If anything, IMO we should _reduce_ the number of unrelated events that trigger a call to these functions. For example, currently any command that reads from the minibuffer will trigger it, because when read-from-minibuffer exits, it restores the window configuration by calling set-window-configuration, which is documented to trigger these functions. That just doesn't make any sense to me, since most reads from the minibuffer don't resize any windows! > If this is merely a documentation issue, the exception should be noted > in the manual. That's easy. Deciding what's TRT in this case is harder. > If this behavior is deliberate, I believe it is inconsistent to set > FRAME_WINDOW_SIZES_CHANGED (f) in `resize-mini-window-internal'. It's consistent if we adopt the POV that this feature only catches resizes from Lisp code. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 14:07:01 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 18:07:01 +0000 Received: from localhost ([127.0.0.1]:37199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTw96-0006Ae-UO for submit@debbugs.gnu.org; Mon, 24 Aug 2015 14:07:01 -0400 Received: from mout.gmx.net ([212.227.15.15]:54723) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTw94-0006AV-Hj for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 14:06:59 -0400 Received: from [178.190.22.16] ([178.190.22.16]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M0y8F-1YbGxi0XcN-00vC2Z; Mon, 24 Aug 2015 20:06:57 +0200 Message-ID: <55DB5D3E.1000706@gmx.at> Date: Mon, 24 Aug 2015 20:06:54 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> In-Reply-To: <83k2skhhz1.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:kePEsBxgBJ8zgOfNZZFvrmctNb8ewFjtmyRrxEMfsTchvOvmS97 FXc5wTpZGiWTAYTXV6mWGrgfNL3gZeHxEeUAitrZV2N5HRK6IqYVThLgVQobt9THCbhMIs0 0C4J/A6nRgVWi4sqIZ2tQJu0fQlHfU8tpKjRdXtxUv80ptydYsH6KzWsIX8MZ2eIIxtcREQ OV+za/hR1oAZoj5zyHJLw== X-UI-Out-Filterresults: notjunk:1;V01:K0:XyP7UgTlAAg=:hdwH36vt0xLeDL3NSVZC/S jElS34vWKxn4WLW9e0JYvRK/2Cf7kfpAYhLNw4m5c4aCAmYTAXWy9qEUN2C9fApjF8slsm1gx OCa2DqvMSsP3DfzZUBDTOgZEORiu3W2hEQKebvFkOKBkRKk3WehOFL/b+l8NGeqvvF7DX+bQf x7pzOIQMFyP33yCB/INHl8yG63jxPjnLx7YUGxpoT42I6CibFvHONsWycL2FRJPTqraPXU5DN ayWxnz4ZTBkprIyyP0O+oXTctV+Wwdjb2mrLPqN3QN5JHNjPbj1ON7nbkMM1m+NrQMbMFtYIL Jjn+ZcyQKDT2oUm5N3Jq6QmOSWm+r9AOEF7+bUfRzGGME5zFSiVAyx/6FTqbKVTPtSKXseSf2 eZhOf81zSdKne7qzF3l31wzSQLhiZJqCSt3J1l+H5agHRgNbpKNj77cORtIKAj213zYki8ImY +2eLVVGQ0e3sie4ormOqwvAONndzILp8x1auhpoaNOq5J+tklrlmgj2NB60oRaN+6lQin0qIs ijkLl8vPc3mh3M5FC3GMy8ovTvUunZ0b9++M3cymQ4BYQMpSBSO7VKpzA9EneNAkRQDRZ6ex2 Gll27Gq3WjpIsOIlZ10UZ5GvPkWtMQ9dDF27If55hZRJZnkolDev51RNYrgdwEsG8Qe5+MIsX zFR+Fm/ueV2IfAN5DnhElUEiaeas6PbQJGk2C4lsfyp1BMvMh4VSYdjGnKR9koS/+Mql4GcbM aRE4q0eSukgHBLVRzL4V2VwMPkVqUxUwz86LNg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > That said, I wonder whether changing the code now to call these > functions due to automatic resizing would make sense. What would be > the real-life use cases for using that? Naively spoken it's obvious that when you shrink the minibuffer you show more lines in the window above and =E2=80=98linum-mode=E2=80=99 has to ad= d numbers for those lines. And when you enlarge the minibuffer, =E2=80=98follow-mode=E2= =80=99 will lose some lines at the bottom of the left window and has to show them at the top of the right window. I don't know how these packages currently work around the problem that =E2=80=98window-size-change-functions=E2=80=99 is not called for automati= c minibuffer resizing. Maybe they use the =E2=80=98post-command-hook=E2=80=99 functio= n instead. > If anything, IMO we should _reduce_ the number of unrelated events > that trigger a call to these functions. For example, currently any > command that reads from the minibuffer will trigger it, because when > read-from-minibuffer exits, it restores the window configuration by > calling set-window-configuration, which is documented to trigger these= > functions. That just doesn't make any sense to me, since most reads > from the minibuffer don't resize any windows! This is, in fact, an abuse of =E2=80=98set-window-configuration=E2=80=99.= But how fix it? We'd need a hook, say =E2=80=98window-size-change-functions=E2=80=99= , that tracks, among other things, whether a window was resized due to a change of the minibuffer height and, if that happens, set a flag to indicate that the window configuration must be restored. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 14:13:35 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 18:13:35 +0000 Received: from localhost ([127.0.0.1]:37203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTwFR-0006Jg-Vk for submit@debbugs.gnu.org; Mon, 24 Aug 2015 14:13:35 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:36767) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTwFO-0006JV-9l for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 14:13:31 -0400 Received: by igcse8 with SMTP id se8so54078822igc.1 for <21333@debbugs.gnu.org>; Mon, 24 Aug 2015 11:13:29 -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=g2Jc43GBJvXckRC9mcnRJoOaWvIRDIau0fAKEnTL8pw=; b=B9OiE9fDcpkkOzOCyXvUwZzp+9L11C+IHVgFXApCuHwN2Bap9N8XAPYX9vzxzcVBJp 8fY7v+w17DoI6JIS+L2OXHjV4WsN3ccmYHzFLQgRuWU7wIkIEWVSz9voVN0jJm6nElKX EKpzuaYpi5TZRHnXt3BONwzAY96Cu/ocb7v1fg3cPV7ZBnVCj0KsVJw5yzCf74RtK1aj w5pggvkmIZc7fspXJfrUzfexfKZCGjqKqNkv7hSYLSH1ONjSTJGlUI44Xx0llOCVWmLi JJn2+8SSeU0DBZqvbMujHzAdHmb1kg1F1jPPtMhnW7A25EVMIv0lhAtUjMBZw7iHFOjv 8nRw== MIME-Version: 1.0 X-Received: by 10.50.17.9 with SMTP id k9mr16612964igd.93.1440440009817; Mon, 24 Aug 2015 11:13:29 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Mon, 24 Aug 2015 11:13:29 -0700 (PDT) In-Reply-To: <83k2skhhz1.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> Date: Mon, 24 Aug 2015 18:13:29 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: Eli Zaretskii Content-Type: multipart/mixed; boundary=089e01182a341b415e051e129359 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e01182a341b415e051e129359 Content-Type: text/plain; charset=UTF-8 Thank you for your response! Sorry this is a long email, but I really, really want the full-featured window-size-change-functions. I understand if you don't have time to read it all, so let me summarize: - Redisplay is so slow that it really doesn't matter that we call an extra bit of Lisp code before running it. - Doing it "my way" is cheap in terms of performance (I benchmarked), easy to implement, enables cool but not necessarily useful hacks, but requires very slow hook functions to rate-limit themselves in order to keep the minibuffer usable. - Doing it your way is even cheaper in terms of performance, not very hard to implement, requires those hacks to hook into pre-redisplay-functions instead, and has the questionable benefit of allowing badly-written non-rate-limiting hook functions to keep the minibuffer usable, but still break drag-resizing. On Mon, Aug 24, 2015 at 2:35 PM, Eli Zaretskii wrote: >> Recipe: eval >> (progn (push (lambda (&rest args) (message "window size changed")) >> window-size-change-functions) >> (message (make-string 3000 ?*))) >> >> Expected result: a "window size changed" message. >> >> Actual result: no such message. >> >> The symptom is that the window size change function is not run after a >> mini-window size change. > > Note that resizing the mini-window involves resizing of at least one > other window on the same frame. So this is not exactly about the > mini-window. Noted. >> So far, I can produce this behavior only when the minibuffer or echo >> area grows to several lines; when it shrinks afterwards, my window size >> change function is called. > > I don't see the message even when the mini-window shrinks back. Are > you sure the message you see is not triggered by some other event? No, I'm not sure, and that turns out to be correct. Thanks for helping to clarify that point. > It's way too easy to trigger it, see below. I'm going to go into this in more detail, but I think that point can be restated as "since it's called frequently, in most cases, the hook function should return immediately after checking that the event isn't interesting", and I agree with that. >> I cannot reproduce the behavior with other windows. > > See above: at least one other window is resized in this recipe, so the > exemption is not about the mini-window itself, it's about any window > involved in resizing in this particular scenario. I understand what's happening, but wanted to make clear that the mini-window involvement is the decisive factor. >> Is this a bug? The documentation says: >> >> [...] to be called if the size of any window changes for any reason. >> >> Please correct me if I'm wrong, but when the minibuffer/echo area gets >> resized (and the windows on top of it, too), that counts as a change of >> size, I would say. > > I believe the original reason for this is largely historical: > window-size-change-functions exists since Emacs 19.29, whereas > automatic resizing of mini-window was introduced in Emacs 21. Since > Emacs before 21 didn't have the mini-window resizing functionality, > Emacs 21 was careful not to gratuitously trigger these functions by > something that is purely a new redisplay feature. > > That said, I wonder whether changing the code now to call these > functions due to automatic resizing would make sense. What would be > the real-life use cases for using that? I am beginning to suspect I'm missing something here. Is there another way for windows to find out they're resized? There's pre-redisplay function, but I believe that is called far, far more often. The real-life use case I'm thinking of (which I'm not advocating as a good idea, but am advocating strongly as something that it should be possible to do) is EXWM, an X window manager written in Elisp that creates dummy buffers and dynamically maps X windows to cover their Emacs windows. But it seems to me every attempt to make an Emacs window's graphical representation fit in with its environment requires a way of knowing when that window is resized; and, if it wants to warp the mouse cursor (again, almost certainly not a good idea, but something that should be possible) it needs to know when its position within the frame changed, as well, since mouse coordinates are frame-relative. For example, I don't see another way to implement dynamic fit-image-to-window applications. What I would consider a valid use case is to call doc-view-fit-page-to-window if the window has been resized (of course, a practical implementation would ensure that such automatic resize operations would not cause a full re-rendering to happen upon every size change, but that's an implementation detail). I suspect you will object that in that case, there's no harm in the minibuffer temporarily hiding some of the document, but imagine reading the last line on a PDF page and, for some reason, deciding to type in some of that text into the minibuffer: the minibuffer would resize, obstructing the last line, and you could no longer see the text you're trying to type in. (Yes, it's somewhat far-fetched, but you're the one suggesting to change the documented behaviour of a feature to remove it once and for all, and I'm the conservative one arguing we should keep it.) For something that's less far-fetched, I'm thinking of accessibility and automation applications: if you want to point a screen reader to the right text to read, you're going to need its X coordinates, which might change due to a mini-window resize (either because you want the screen reader to read the mini-window contents, or because a window above the minibuffer is close to its minimum height and needs to move vertically to accomodate the growing mini-window). And if your accessibility utility is stupid (I understand most are) and only allows you to enter text by warping the mouse pointer and generating key press events, well, that's easy if you know how to update its idea of where to type. I can think of many X hacks that would probably be possible with or without window-size-change-functions, but much easier to implement with that hook: for example, while I doubt this could be made really secure (you'd have to synchronize with x11vnc), you could clip x11vnc to a given Emacs window without revealing the contents of the minibuffer to the remote viewer. Use cases: 1. X hacks. I want to do something with the Emacs X windows and need to know their coordinates to do so. EXWM, accessibility, compositing WM hacks (transparency, duplicating windows, rendering them upside-down, whatever), VNC clipping. Most of those are possible without a reliable w-s-c-f hook, but are much easier to implement with one. 2. automatic-resize applications. These, strictly speaking, need to know only the window size, not its frame-relative position. 3. things I'm too stupid to think of. I think this is the big one: let's leave the feature in and see what smart people come up with. > I believe window-size-change-functions is meant for taking notice of > resizes done by the user or some Lisp code, not for automated resizes > whose sole purpose is to allow some message be read in its entirety. I disagree with the notion that the possible applications of a software feature are limited to what I can think of beforehand :-) You appear to be arguing for considering the mini-window a temporary overlay that obstructs "real" windows while it exists and goes away when it's no longer needed. That's fine, you can have that: create a minibuffer-only frame and raise or lower it to your heart's content. I'm arguing that the mini-window should be treated like any other window. That's what Emacs has historically implemented, it's still clearly reflected in the code, and as you yourself point out, auto-resizing affects all windows, not just mini-windows. Let's also consider the potential harm done by both options: not calling the hook when I think it should be will result in something being done to the wrong buffer. That's potentially disastrous, either because information is revealed that shouldn't be (my minibuffer extended into the VNC-shared window) or not accessible when it should be (while I specifically want the last line of my PDF to be visible at all times, the "temporary" minibuffer has covered it). In the case of EXWM, the mini-window will resize so the top of it is hidden underneath another X window, rendering echo area messages unreadable. Calling the hook "too often" will result, well, for most users, in twenty lost CPU cycles as a variable is tested and found to be nil. That's negligible. Those users that do have hooks, and specifically only want to do work if the normal size of the window changed, need one "equal" call to detect that window-normal-size hasn't changed and no work needs to be done. That's not quite as negligible, but on today's machines I think it's acceptable overhead to add to what's most likely a user-triggered action. That leaves a third group, that of users who have hooks and want them to do work only after explicit resizes, but wrote buggy code and accidentally called window-size instead of window-normal-size. While I sympathize with everyone who writes buggy code, I do not think that third group should be accommodated. > If you agree, then the current behavior will make sense to you. I hope I've made it clear so far that I disagree. > If anything, IMO we should _reduce_ the number of unrelated events > that trigger a call to these functions. For example, currently any > command that reads from the minibuffer will trigger it, because when > read-from-minibuffer exits, it restores the window configuration by > calling set-window-configuration, which is documented to trigger these > functions. That just doesn't make any sense to me, since most reads > from the minibuffer don't resize any windows! I believe that's a separate issue. From my point of view, it makes sense to call our hook, since one window (the echo area) has been replaced by another (the minibuffer). I do not understand why you seem so loath to calling a rarely-used hook somewhat more often; I conjecture you might be overestimating the cost of checking whether a window's size has actually changed and returning if it hasn't. I've attached a test file that uses benchmark-run to time a million invocations of the test-and-return code, and it takes less than two seconds on this very old machine; IOW, to take up 1% of one CPU core, you'd need 5000 resize events per second. I can run `redisplay' 20,000 times per second, and that's only because those calls return without doing anything. It's cheap. >> If this is merely a documentation issue, the exception should be noted >> in the manual. > > That's easy. Deciding what's TRT in this case is harder. Let's go for doing what the documentation says. I'm thinking of your implied proposal as two changes: 1. rip out the current feature 2. implement a new, crippled feature that satisfies some users of the old feature but not all of them. That's not "extensible". It's not conservative either, IMHO. Maybe it would be useful to add to the documentation of the hook an example of how to test whether a frame's current mini-window is at what the manual calls its "normal size", and to suggest that expensive hook functions not be run if it isn't. The exact code that does that is left as an exercise to the reader (i.e. I haven't figured it out yet). >> If this behavior is deliberate, I believe it is inconsistent to set >> FRAME_WINDOW_SIZES_CHANGED (f) in `resize-mini-window-internal'. > > It's consistent if we adopt the POV that this feature only catches > resizes from Lisp code. And those from explicit user interaction, yes. That's a valid POV but not, I think, the one we should adopt. Let me repeat that what I understand your POV to be is already fully accommodated by minibuffer-only frames: they're temporary and obstruct what's underneath them, but leave the window sizes in the real frame alone. The converse does not hold: if we remove the feature/fail to fix it, there's no good way to implement my bad ideas. Let's go for "extensible" and "customizable" over "negligibly faster". Sorry, again, that this email has gotten so long. (This is a separate issue, but on first reading it, the pre-redisplay-function(s) code seems like it would be a much better candidate for optimization and elimination, though that might require rewriting some of the simple.el code in C). Thank you again for responding, Pip --089e01182a341b415e051e129359 Content-Type: text/x-emacs-lisp; charset=US-ASCII; name="emacs-benchmark-013.el" Content-Disposition: attachment; filename="emacs-benchmark-013.el" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idq8s1sr0 KGRlZnZhciBteS1mcmFtZSAoc2VsZWN0ZWQtZnJhbWUpKQooZGVmdmFyIG15LXdpbmRvdyAoc2Vs ZWN0ZWQtd2luZG93KSkKKGRlZnZhciBteS1zaXplIG5pbCkKCihkZWZ1biB3LXMtYy1mIChmcmFt ZSkKICAoYW5kIChlcSBmcmFtZSBteS1mcmFtZSkKICAgICAgIChub3QgKGVxdWFsIChjb25zICh3 aW5kb3ctc2l6ZSBteS13aW5kb3cpICh3aW5kb3ctc2l6ZSBteS13aW5kb3cgdCkpCgkJICAgbXkt c2l6ZSkpCiAgICAgICAoc2V0cSBteS1zaXplIChjb25zICh3aW5kb3ctc2l6ZSBteS13aW5kb3cp ICh3aW5kb3ctc2l6ZSBteS13aW5kb3cgdCkpKSkpCgooc2V0cSB3aW5kb3ctc2l6ZS1jaGFuZ2Ut ZnVuY3Rpb25zIG5pbCkKKHB1c2ggIyd3LXMtYy1mIHdpbmRvdy1zaXplLWNoYW5nZS1mdW5jdGlv bnMpCihiZW5jaG1hcmstcnVuIDEwMDAwMDAgKGRvbGlzdCAoZiB3aW5kb3ctc2l6ZS1jaGFuZ2Ut ZnVuY3Rpb25zKSAoZnVuY2FsbCBmIChzZWxlY3RlZC1mcmFtZSkpKSkK --089e01182a341b415e051e129359-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 14:30:46 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 18:30:46 +0000 Received: from localhost ([127.0.0.1]:37216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTwW6-0006jV-63 for submit@debbugs.gnu.org; Mon, 24 Aug 2015 14:30:46 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:42244) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTwW3-0006jL-Ss for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 14:30:44 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NTL00C00N9ZV500@a-mtaout23.012.net.il> for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 21:30:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTL00CTXNF6UY00@a-mtaout23.012.net.il>; Mon, 24 Aug 2015 21:30:42 +0300 (IDT) Date: Mon, 24 Aug 2015 21:30:30 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DB5D3E.1000706@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83vbc4fsjd.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 24 Aug 2015 20:06:54 +0200 > From: martin rudalics > CC: 21333@debbugs.gnu.org > > > That said, I wonder whether changing the code now to call these > > functions due to automatic resizing would make sense. What would be > > the real-life use cases for using that? > > Naively spoken it's obvious that when you shrink the minibuffer you show > more lines in the window above and ‘linum-mode’ has to add numbers for > those lines. And when you enlarge the minibuffer, ‘follow-mode’ will > lose some lines at the bottom of the left window and has to show them at > the top of the right window. In well-behaved modes this happens automatically, as part of redisplay. > Maybe they use the ‘post-command-hook’ function instead. Of course, they do! The flag of bad design. > > If anything, IMO we should _reduce_ the number of unrelated events > > that trigger a call to these functions. For example, currently any > > command that reads from the minibuffer will trigger it, because when > > read-from-minibuffer exits, it restores the window configuration by > > calling set-window-configuration, which is documented to trigger these > > functions. That just doesn't make any sense to me, since most reads > > from the minibuffer don't resize any windows! > > This is, in fact, an abuse of ‘set-window-configuration’. But how fix > it? We'd need a hook, say ‘window-size-change-functions’, that tracks, > among other things, whether a window was resized due to a change of the > minibuffer height and, if that happens, set a flag to indicate that the > window configuration must be restored. I'd say, don't set the "size changed" flag unless the size really changed. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 15:03:31 2015 Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 19:03:31 +0000 Received: from localhost ([127.0.0.1]:37237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTx1m-0007UK-65 for submit@debbugs.gnu.org; Mon, 24 Aug 2015 15:03:30 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:40377) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTx1j-0007U9-17 for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 15:03:28 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTL00700OPCX400@mtaout28.012.net.il> for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 22:03:19 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTL004H5OXJ4J40@mtaout28.012.net.il>; Mon, 24 Aug 2015 22:03:19 +0300 (IDT) Date: Mon, 24 Aug 2015 22:03:13 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83twrofr0u.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 24 Aug 2015 18:13:29 +0000 > From: Pip Cet > Cc: 21333@debbugs.gnu.org > > Sorry this is a long email There's long, and there's long. I mean, geeez.... > - Redisplay is so slow that it really doesn't matter that we call an > extra bit of Lisp code before running it. I'm not worried by performance aspects of this. And this hook doesn't slow down redisplay anyway, because redisplay just sets a flag. > - Doing it "my way" is cheap in terms of performance (I benchmarked), > easy to implement, enables cool but not necessarily useful hacks, but > requires very slow hook functions to rate-limit themselves in order to > keep the minibuffer usable. This is not about performance. It's about utility and complexity. Having to program for a system where your hook is called in umpteen unrelated situations makes your program much more complex and fragile than it could be if the hook was more accurate. > - Doing it your way is even cheaper in terms of performance, not very > hard to implement, requires those hacks to hook into > pre-redisplay-functions instead, and has the questionable benefit of > allowing badly-written non-rate-limiting hook functions to keep the > minibuffer usable, but still break drag-resizing. Once again, this is not about performance. > >> I cannot reproduce the behavior with other windows. > > > > See above: at least one other window is resized in this recipe, so the > > exemption is not about the mini-window itself, it's about any window > > involved in resizing in this particular scenario. > > I understand what's happening, but wanted to make clear that the > mini-window involvement is the decisive factor. No, it's not. The decisive factor is that the way this is implemented simply doesn't set the flag in this situation. IOW, the code to set it wasn't written. > > That said, I wonder whether changing the code now to call these > > functions due to automatic resizing would make sense. What would be > > the real-life use cases for using that? > > I am beginning to suspect I'm missing something here. Is there another > way for windows to find out they're resized? They are not resized, from my POV. > For example, I don't see another way to implement dynamic > fit-image-to-window applications. > > What I would consider a valid use case is to call > doc-view-fit-page-to-window if the window has been resized (of course, > a practical implementation would ensure that such automatic resize > operations would not cause a full re-rendering to happen upon every > size change, but that's an implementation detail). How is this different from something else, like a tooltip or a drop-down menu, temporarily obscuring a portion of the display? If you want to make the hook scroll the display when the minibuffer is resized, you will cause annoying jumpy display when some Lisp program repeatedly displays echo-area messages and clears the echo area -- for example, consider a Lisp compilation of a large buffer that produces many warnings. Moreover, you are worried by the last line of a PDF text, but what about the first one? When the window becomes smaller, some part will have to disappear from display, there's no way around that. Why should we care about the last portion more than about the first? > For something that's less far-fetched, I'm thinking of accessibility > and automation applications: if you want to point a screen reader to > the right text to read, you're going to need its X coordinates, which > might change due to a mini-window resize But the coordinates of the text that stays on screen don't change in such a resize. Some text is obscured, but what's left doesn't move. So I see no problem here. > Use cases: > 1. X hacks. I want to do something with the Emacs X windows and need > to know their coordinates to do so. EXWM, accessibility, compositing > WM hacks (transparency, duplicating windows, rendering them > upside-down, whatever), VNC clipping. Most of those are possible > without a reliable w-s-c-f hook, but are much easier to implement with > one. I'm not sure I understand the use case, but if I do, it's impossible: you need to have redisplay finish before you can ask Emacs about coordinates of some point. So this cannot be done while the minibuffer is being resized. > 2. automatic-resize applications. These, strictly speaking, need to > know only the window size, not its frame-relative position. Already covered above. I see no problems here that are specific to this particular resize. > 3. things I'm too stupid to think of. I think this is the big one: > let's leave the feature in and see what smart people come up with. That's not a use case. > You appear to be arguing for considering the mini-window a temporary > overlay that obstructs "real" windows while it exists and goes away > when it's no longer needed. That's fine, you can have that: create a > minibuffer-only frame and raise or lower it to your heart's content. > > I'm arguing that the mini-window should be treated like any other > window. I'm not special-casing the mini-window here. I'm special-casing this particular case of resizing the windows. > Let's also consider the potential harm done by both options: not > calling the hook when I think it should be will result in something > being done to the wrong buffer. I don't see why it should, not without a more detailed description. > Calling the hook "too often" will result, well, for most users, in > twenty lost CPU cycles as a variable is tested and found to be nil. Once again, this isn't about performance. > > If you agree, then the current behavior will make sense to you. > > I hope I've made it clear so far that I disagree. Then I guess we will have to agree to disagree. > > If anything, IMO we should _reduce_ the number of unrelated events > > that trigger a call to these functions. For example, currently any > > command that reads from the minibuffer will trigger it, because when > > read-from-minibuffer exits, it restores the window configuration by > > calling set-window-configuration, which is documented to trigger these > > functions. That just doesn't make any sense to me, since most reads > > from the minibuffer don't resize any windows! > > I believe that's a separate issue. No, it's not. It's the same issue: this hook is already called in situations where it shouldn't have been, and thus imposes on the programmers who use it complex ways of deciding whether there was or wasn't a change they should care about. You suggest to add one more situation in that class, something that most application that define this hook shouldn't and don't care. It's the complexity that worries me. > I do not understand why you seem so loath to calling a rarely-used > hook somewhat more often; I conjecture you might be overestimating the > cost of checking whether a window's size has actually changed and > returning if it hasn't. I've attached a test file that uses > benchmark-run to time a million invocations of the test-and-return > code, and it takes less than two seconds on this very old machine; > IOW, to take up 1% of one CPU core, you'd need 5000 resize events per > second. I can run `redisplay' 20,000 times per second, and that's only > because those calls return without doing anything. It's cheap. Once again, this is not about performance. Never was. It's about complexity, IMO gratuitous in this case. Emacs is already too complex for this kinds of job due to several hooks that are called indiscriminately, and leave it to the programmer to figure out whether some change really happened. Anyway, it's clear we disagree. I just wanted to voice my protest against such creeping featurism. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 03:25:19 2015 Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 07:25:19 +0000 Received: from localhost ([127.0.0.1]:37479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZU8be-0001FB-J7 for submit@debbugs.gnu.org; Tue, 25 Aug 2015 03:25:18 -0400 Received: from mout.gmx.net ([212.227.15.19]:49406) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZU8bc-0001F2-AQ for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 03:25:17 -0400 Received: from [188.22.234.133] ([188.22.234.133]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3j17-1Ydp8K2KIb-00rIWy; Tue, 25 Aug 2015 09:25:13 +0200 Message-ID: <55DC1856.7000501@gmx.at> Date: Tue, 25 Aug 2015 09:25:10 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> In-Reply-To: <83vbc4fsjd.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:j4mOTswNdPQ3WeuwB5HmO1KumjrZFufrutAhUPnJKmN1NQDy+j7 KIxLPafv9O1KaFNIFO9g3Skg/wkiyDXsXJkc8SEg70mh33dmKbNvtCY5O5HnhpcO4klcayB 5i+5oAVnNyl4BKPy/f4+/5rAQ+Af5Wkln7O50+Mknp/9qTXKY6iRSW/JEOQmrWokGyMTgxR xlumAq9Tf9z9OPY0sP/Xg== X-UI-Out-Filterresults: notjunk:1;V01:K0:CVJt/Sj8+8A=:1WO/NChasxsZfuwuwFWkLZ xgSi4U86M/CY+16KOzRQHiUf5x1dJY/zpYSCzSsxHtXY8Rk6Qf1Ety+5uuX9JHWMgG/KTpzpq XY/FFpleJXgZC5jqDUMuwJRSK6DN8FvawkJUaxnktC4dKbF19R4dw/S22Bp13XcjLTDCDCYGo M6Wkkl54meLUAExtidzU4jf746U5iBg2WPxCXPnUnhIMgns+Pm0FP9jQKK/s2nWJoDZy3L+r8 pquwsUk/iVzDQGD+0E1Zx2+l3ahyCQ+qwl5gM7bsmQ75MVnr878lno7EOivwE8sNuO2o44lbJ grAA/nZXp8vGHWWBkxnh/3L5A6USj0+fT5MJdACy6gSbg1UlxO+yp/Cl1vP38FOA6jrej8AZr lAcf7kw1j2EMQ3HV0YkSMRqiuR9rITjGSfwHz8SipqcjjMF47A+dV+keFKGVOpDwIRoha05qV LMeisS9r4Qd6ErxXnh7s/bZ9p2RqOccjqKOfhffZ4KrTUJ7+hdhf/u+wM1o3hbKQZawdgbneM DA7Gw2NXfjfTuBJ0EYGLX14fRirEr1U5YEomypWd+LYctlVxlTNlSYbZtvz/ideOBIEvtPR7k SocGLYKDdFgdr7BlCPXiWJVmekIp4hs+U0wHuFJnUbjnRZPEKfvDcP00y+jicU8m9qc6zNlAO FEKnBbUg3pTom/iWgz6YlDkvQT2cv2mLrNSjiQ8wTTNGU4ZgXyV1ancGiTjiCjBZ7ne6Nsunl zDmFbsWUYrl9aMAPbpQPlPkTiRTAWUIwbQTU0Q== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Naively spoken it's obvious that when you shrink the minibuffer you s= how >> more lines in the window above and =E2=80=98linum-mode=E2=80=99 has t= o add numbers for >> those lines. And when you enlarge the minibuffer, =E2=80=98follow-mo= de=E2=80=99 will >> lose some lines at the bottom of the left window and has to show them= at >> the top of the right window. > > In well-behaved modes this happens automatically, as part of > redisplay. Via =E2=80=98pre-redisplay-function=E2=80=99? How does a well-behaved mo= de detect whether it has to make "this happen automatically"? By walking all windows and checking whether their sizes, start and end positions changed, I suppose. >> Maybe they use the =E2=80=98post-command-hook=E2=80=99 function inste= ad. > > Of course, they do! The flag of bad design. IIUC they didn't have another choice before =E2=80=98pre-redisplay-functi= on=E2=80=99 was added. >> This is, in fact, an abuse of =E2=80=98set-window-configuration=E2=80= =99. But how fix >> it? We'd need a hook, say =E2=80=98window-size-change-functions=E2=80= =99, that tracks, >> among other things, whether a window was resized due to a change of t= he >> minibuffer height and, if that happens, set a flag to indicate that t= he >> window configuration must be restored. > > I'd say, don't set the "size changed" flag unless the size really > changed. Sure. Nevertheless we would have to also track changes due to automatic minibuffer resizing. Alternatively, Fset_window_configuration could run a modified version of =E2=80=98compare-window-configurations=E2=80=99 to compare the current co= nfiguration with the one to be restored and restore the old configuration iff these differ. I'm not sure whether this would be any cheaper, especially when the configuration does change frequently. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 03:25:20 2015 Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 07:25:20 +0000 Received: from localhost ([127.0.0.1]:37482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZU8bg-0001FQ-8Z for submit@debbugs.gnu.org; Tue, 25 Aug 2015 03:25:20 -0400 Received: from mout.gmx.net ([212.227.15.15]:57254) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZU8be-0001FA-Oj for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 03:25:19 -0400 Received: from [188.22.234.133] ([188.22.234.133]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LqQzp-1YqwAO3jKT-00e5CU; Tue, 25 Aug 2015 09:25:18 +0200 Message-ID: <55DC185A.4080101@gmx.at> Date: Tue, 25 Aug 2015 09:25:14 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> In-Reply-To: <83twrofr0u.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:0rfelxuQOurzpeg9l4ToIgcJvwaiiJjFdQNoGAaimYmZh6SuXFL gtiqp2zOrFQlDQbG6rgsbtAUAngSnt9WVD837DG4dPBO+8oKhMs0vqWKNf0iqnN63lGszZy cb+EhgSkmJ2d2l0TDFaZkPPK8pM63uSUhTrNd+DI5yndOeaF1q0EMX5ia3R2n+oQfqrm8uA +oiHdVy5vqizrmcpAKmdQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:MUqt02ocsq4=:STYRk59ZvF56xuwIP8Q187 KKO7eX+dFfJ6+MwcmsEqk+PRmaz6JKBUhLD+9uWzfPubdok74RqgYXi1LkmERJ0SxlRgPQrs8 TF8fXsdlYP0hNj2MQ9yA46NIWA8mgJ2Ymq+vCNxUNPko/8W9aYEoQpq8fP5RLUCudHOVgZYBq P3R0RDZ4eoQJ8lbasvKpOELUGPUhcmU5IPVq+SwbwI+5dNBjUkWutP9TjpJ2SNdOKt4KcfcvT By24f1iTCL7wYk3iYAZp/1kSF41/jKaRQe4AnIqfBCKDQekb0VX8P1fI56GetUWldtSI76ZcC lIAag1TTuFbKjjCUaZmP3pNobiK6xesmFFD9aF5ffqtC1kxoSX8CopmXZF4fLjp0Gnryu8dUv lUTLueFthIjIVLiPCWVbEG6gP5zHW2BJjMW7SMySCGH3he4bGUI+vVrAKGLGZzN9Ofmju1huc nWV3/4RI7tNZyrt+klBcUcqWgqubJC9W3PyhyT4hVBAQAL+CDSG+DsbLRzuRcM2t/ZtrIRZMe d/xUqKVbdiYY21VoP6i9WXyKC0hdjUDSlHm2RWSVnt18CNXG7n/gu8voGQnlAjJsXshLfysmp qeVhmP7x/djv87PaNTzzhnTJ4Dk0YYxCjkATTAl+XieIcXjO9nLgVBcp5MlQ94L9f6nMK6vMy WqZlDQT/4oUDvrrMd+UAw57D18Ojr171zfMdSKkbz0zv3sh+rnhVoVeuvWqf/inDScNsCgnY7 yrfd2CAFXQ5GvNBllCkyUhHZzQcFuVWLDLeeQA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > But the coordinates of the text that stays on screen don't change in > such a resize. Some text is obscured, but what's left doesn't move. > So I see no problem here. I'm not sure what you mean here: When the minibuffer resizes and point is near the bottom of the window above, the window above will scroll and stick to the new window start position even after the minibuffer gets sized back. When the window above the minibuffer is a one line window or fixed-size, the window above that window will be subject to those changes. > No, it's not. It's the same issue: this hook is already called in > situations where it shouldn't have been, and thus imposes on the > programmers who use it complex ways of deciding whether there was or > wasn't a change they should care about. You suggest to add one more > situation in that class, something that most application that define > this hook shouldn't and don't care. It's the complexity that worries > me. You mean when =E2=80=98set-window-configuration=E2=80=99 doesn't change t= he size of a single window the hook shouldn't be called? Ideally it shouldn't but this is a problem similar to that of indenting a paragraph changing the buffer modified state although in reality nothing changed. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 06:34:27 2015 Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 10:34:27 +0000 Received: from localhost ([127.0.0.1]:37589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUBYg-0005n9-Qb for submit@debbugs.gnu.org; Tue, 25 Aug 2015 06:34:27 -0400 Received: from mail-io0-f173.google.com ([209.85.223.173]:33094) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUBYe-0005n0-FO for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 06:34:25 -0400 Received: by iods203 with SMTP id s203so181010189iod.0 for <21333@debbugs.gnu.org>; Tue, 25 Aug 2015 03:34:23 -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=3a/P/B1mgS06Ki13yU3vikwgXlZ7hrTCFILKeG15nR4=; b=Weun/fkoIB6kCo92coyLgk1XnRlZJPqmyBPvwZQrMWfEU8WzgDDwzMdStdWG64jZUr 8YgKpWjyyXjzI4nbGZlkeCTaLpNqDV5QUXDcg5cZCLKx97Ez5MFQiI0Xv6yRjvyx08iw BMKwrgUznmrDFzT9lsWp0k58a+MC/xTHfCbEHnw83T446a+ywMtevp4fyGkeT1+UeJKB B7w+eLyXj73khu7BY+OPJQP7v3nA/nRnmWnIOEWZUS7ZRvOGpDyAyASiKDAF0Jz7euYZ IHcHIlPgojRXHF2Tb4Qbf0kZYYJmiPeQ2GNaXLMYpDaMIBkELRDPZxjyQcvMVvPPS6k9 NDXQ== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr17264213ioo.136.1440498863504; Tue, 25 Aug 2015 03:34:23 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Tue, 25 Aug 2015 03:34:23 -0700 (PDT) In-Reply-To: <55DC1856.7000501@gmx.at> References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> Date: Tue, 25 Aug 2015 10:34:23 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: martin rudalics Content-Type: multipart/mixed; boundary=001a1144ac340f2b4a051e2047d9 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1144ac340f2b4a051e2047d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 25, 2015 at 7:25 AM, martin rudalics wrote: >>> Naively spoken it's obvious that when you shrink the minibuffer you sho= w >>> more lines in the window above and =E2=80=98linum-mode=E2=80=99 has to = add numbers for >>> those lines. And when you enlarge the minibuffer, =E2=80=98follow-mode= =E2=80=99 will >>> lose some lines at the bottom of the left window and has to show them a= t >>> the top of the right window. >> >> In well-behaved modes this happens automatically, as part of >> redisplay. > > Via =E2=80=98pre-redisplay-function=E2=80=99? Well, we have `pre-redisplay-functions', with an s, defined in simple.el, and I've attached some (trivial) code that takes things a little further and calls a normal hook when a window's size changed. > How does a well-behaved mode detect > whether it has to make "this happen automatically"? By walking all > windows and checking whether their sizes, start and end positions > changed, I suppose. That's what my code does. I thought I could get away with using the arguments passed to pre-redisplay-function to limit which windows to check, but that doesn't work when we "goto retry" and re-run pre-redisplay-function. I will study the code in xdisp.c further and see whether I can understand what the purpose of must_finish is. >> I'd say, don't set the "size changed" flag unless the size really >> changed. > > Sure. Patch attached (no news on the paperwork so far). I'm not sure precisely which properties should be checked for change, though. I do think it would be best not to use set-window-configuration in restoring state after exiting the minibuffer at all. > Alternatively, Fset_window_configuration could run a modified version of > =E2=80=98compare-window-configurations=E2=80=99 to compare the current co= nfiguration > with the one to be restored and restore the old configuration iff these > differ. I'm not sure whether this would be any cheaper, especially when > the configuration does change frequently. I think it would be better to do this explicitly, even if we have to compare all properties. Thanks again to both of you, Pip --001a1144ac340f2b4a051e2047d9 Content-Type: text/x-emacs-lisp; charset=US-ASCII; name="emacs-via-redisplay-014.el" Content-Disposition: attachment; filename="emacs-via-redisplay-014.el" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idr7rhsx0 OzsgZ2VuZXJpYyBjb2RlOgooZGVmdmFyIHByZWRpc3BsYXktaG9vayBuaWwKICAiTm9ybWFsIGhv b2sgcnVuIGJlZm9yZSBwcmVkaXNwbGF5LiIpCihkZWZ2YXIgd2luZG93LWNoYW5nZWQtc2l6ZS1o b29rIG5pbAogICJOb3JtYWwgaG9vayBydW4gd2hlbiBhIHdpbmRvdyBkaXNwbGF5aW5nIHRoaXMg YnVmZmVyIGNoYW5nZWQgc2l6ZS4iKQooZGVmdmFyIHByZWRpc3BsYXktc2l6ZXMgKG1ha2UtaGFz aC10YWJsZSA6d2Vha25lc3MgJ2tleSA6dGVzdCAnZXEpCiAgIkhhc2ggdGFibGUgb2Ygb2xkIHdp bmRvdyBzaXplcyB0byBkZXRlY3Qgc2l6ZSBjaGFuZ2VzLiIpCgooZGVmdW4gcHJlZGlzcGxheS1j aGVjay13aW5kb3cgKCkKICAiUnVuIGluIGhvb2sgYHByZWRpc3BsYXktaG9vaycgdG8gZGV0ZXJt aW5lIHdoaWNoIHdpbmRvd3MgY2hhbmdlZCBzaXplLiIKICAobGV0KiAoKHcgKHNlbGVjdGVkLXdp bmRvdykpCgkgKG9sZC1zaXplIChnZXRoYXNoIHcgcHJlZGlzcGxheS1zaXplcykpCgkgKG5ldy1z aXplIChjb25zICh3aW5kb3ctcGl4ZWwtd2lkdGggdykKCQkJICh3aW5kb3ctcGl4ZWwtaGVpZ2h0 IHcpKSkpCiAgICAodW5sZXNzIChlcXVhbCBvbGQtc2l6ZSBuZXctc2l6ZSkKICAgICAgKHJ1bi1o b29rcyAnd2luZG93LWNoYW5nZWQtc2l6ZS1ob29rKQogICAgICAocHV0aGFzaCB3IG5ldy1zaXpl IHByZWRpc3BsYXktc2l6ZXMpKSkpCgooYWRkLWhvb2sgJ3ByZWRpc3BsYXktaG9vayAjJ3ByZWRp c3BsYXktY2hlY2std2luZG93KQoKKGRlZnVuIHByZWRpc3BsYXktZnVuY3Rpb24gKCZyZXN0IGFy Z3MpCiAgKGRvbGlzdCAodyAod2luZG93LWxpc3QtMSBuaWwgdCB0KSkKICAgICh3aXRoLXNlbGVj dGVkLXdpbmRvdyB3CiAgICAgIChydW4taG9va3MgJ3ByZWRpc3BsYXktaG9vaykpKSkKCihhZGQt ZnVuY3Rpb24gOmJlZm9yZSBwcmUtcmVkaXNwbGF5LWZ1bmN0aW9uCiAgICAgICAgICAgICAgIydw cmVkaXNwbGF5LWZ1bmN0aW9uKQo7OyBkZW1vbnN0cmF0aW9uIGNvZGU6CihkZWZ1biBteS13aW5k b3ctY2hhbmdlZC1zaXplICgpCiAgKGluc2VydCAoZm9ybWF0ICIlZHglZFxuIiAod2luZG93LXBp eGVsLXdpZHRoIChzZWxlY3RlZC13aW5kb3cpKQogICAgICAgICAgICAgICAgICAod2luZG93LXBp eGVsLWhlaWdodCAoc2VsZWN0ZWQtd2luZG93KSkpKSkKCihkZWZ1biBkaXNwbGF5LWR5bmFtaWMt c2l6ZSAoKQogIChhZGQtaG9vayAnd2luZG93LWNoYW5nZWQtc2l6ZS1ob29rICMnbXktd2luZG93 LWNoYW5nZWQtc2l6ZSBuaWwgdCkpCgo7OyBkZWFkIGNvZGU6Cgo7OyBJIHRob3VnaHQgdGhpcyB3 b3VsZCB3b3JrLCBidXQgaXQgZG9lc24ndCwgZm9yIHJlYXNvbnMgSSBiZWxpZXZlCjs7IEVsaSBk ZXNjcmliZWQuCgo7OyAoZGVmdW4gcHJlZGlzcGxheS1ydW4taG9vayAod2luZG93KQo7OyAgICh3 aXRoLXNlbGVjdGVkLXdpbmRvdyB3aW5kb3cKOzsgICAgIChydW4taG9va3MgJ3ByZWRpc3BsYXkt aG9vaykpKQoKOzsgKHB1c2ggIydwcmVkaXNwbGF5LXJ1bi1ob29rIHByZS1yZWRpc3BsYXktZnVu Y3Rpb25zKQoK --001a1144ac340f2b4a051e2047d9 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Only-set-FRAME_WINDOW_SIZES_CHANGED-if-necessary-213.patch" Content-Disposition: attachment; filename="0001-Only-set-FRAME_WINDOW_SIZES_CHANGED-if-necessary-213.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idr7rlhg1 RnJvbSA5NGJhMGE4ZWQxMjdkYzE0N2ViNjhiZjAxOWExZTgzNzA2MjJjNzQwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg MjUgQXVnIDIwMTUgMTA6MjE6MTggKzAwMDAKU3ViamVjdDogW1BBVENIXSBPbmx5IHNldCBGUkFN RV9XSU5ET1dfU0laRVNfQ0hBTkdFRCBpZiBuZWNlc3NhcnkgKCMyMTMzMykKCi0tLQogc3JjL3dp bmRvdy5jIHwgOCArKysrKysrLQogMSBmaWxlIGNoYW5nZWQsIDcgaW5zZXJ0aW9ucygrKSwgMSBk ZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL3NyYy93aW5kb3cuYyBiL3NyYy93aW5kb3cuYwppbmRl eCA2OGJjOWU1Li42YmMwOTgyIDEwMDY0NAotLS0gYS9zcmMvd2luZG93LmMKKysrIGIvc3JjL3dp bmRvdy5jCkBAIC02MDc1LDcgKzYwNzUsNiBAQCB0aGUgcmV0dXJuIHZhbHVlIGlzIG5pbC4gIE90 aGVyd2lzZSB0aGUgdmFsdWUgaXMgdC4gICovKQogCX0KIAogICAgICAgZnNldF9yZWRpc3BsYXkg KGYpOwotICAgICAgRlJBTUVfV0lORE9XX1NJWkVTX0NIQU5HRUQgKGYpID0gdHJ1ZTsKIAogICAg ICAgLyogUHJvYmxlbTogRnJlZWluZyBhbGwgbWF0cmljZXMgYW5kIGxhdGVyIGFsbG9jYXRpbmcg dGhlbSBhZ2FpbgogCSBpcyBhIHNlcmlvdXMgcmVkaXNwbGF5IGZsaWNrZXJpbmcgcHJvYmxlbS4g IFdoYXQgd2Ugd291bGQKQEAgLTYxMjcsNiArNjEyNiwxMyBAQCB0aGUgcmV0dXJuIHZhbHVlIGlz IG5pbC4gIE90aGVyd2lzZSB0aGUgdmFsdWUgaXMgdC4gICovKQogCSAgLyogSWYgd2Ugc3F1aXJy ZWxlZCBhd2F5IHRoZSBidWZmZXIsIHJlc3RvcmUgaXQgbm93LiAgKi8KIAkgIGlmIChCVUZGRVJQ ICh3LT5jb21iaW5hdGlvbl9saW1pdCkpCiAJICAgIHdzZXRfYnVmZmVyICh3LCB3LT5jb21iaW5h dGlvbl9saW1pdCk7CisgICAgICAgICAgaWYgKCFGUkFNRV9XSU5ET1dfU0laRVNfQ0hBTkdFRCAo ZikpIHsKKyAgICAgICAgICAgIGlmICh3LT5waXhlbF9sZWZ0ICE9IFhGQVNUSU5UIChwLT5waXhl bF9sZWZ0KSB8fAorICAgICAgICAgICAgICAgIHctPnBpeGVsX3RvcCAhPSBYRkFTVElOVCAocC0+ cGl4ZWxfdG9wKSB8fAorICAgICAgICAgICAgICAgIHctPnBpeGVsX3dpZHRoICE9IFhGQVNUSU5U IChwLT5waXhlbF93aWR0aCkgfHwKKyAgICAgICAgICAgICAgICB3LT5waXhlbF9oZWlnaHQgIT0g WEZBU1RJTlQgKHAtPnBpeGVsX2hlaWdodCkpCisgICAgICAgICAgICAgIEZSQU1FX1dJTkRPV19T SVpFU19DSEFOR0VEIChmKSA9IHRydWU7CisgICAgICAgICAgfQogCSAgdy0+cGl4ZWxfbGVmdCA9 IFhGQVNUSU5UIChwLT5waXhlbF9sZWZ0KTsKIAkgIHctPnBpeGVsX3RvcCA9IFhGQVNUSU5UIChw LT5waXhlbF90b3ApOwogCSAgdy0+cGl4ZWxfd2lkdGggPSBYRkFTVElOVCAocC0+cGl4ZWxfd2lk dGgpOwotLSAKMi41LjAKCg== --001a1144ac340f2b4a051e2047d9-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 11:12:01 2015 Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 15:12:01 +0000 Received: from localhost ([127.0.0.1]:38165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFtI-0005IB-Jy for submit@debbugs.gnu.org; Tue, 25 Aug 2015 11:12:01 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:48004) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFtG-0005I1-6S for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 11:11:59 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NTN008008CPEW00@a-mtaout20.012.net.il> for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 18:11:56 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTN008WS8VWF410@a-mtaout20.012.net.il>; Tue, 25 Aug 2015 18:11:56 +0300 (IDT) Date: Tue, 25 Aug 2015 18:11:46 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DC1856.7000501@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83pp2bfln1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 25 Aug 2015 09:25:10 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org Before I respond to your comments, let me just clarify that what I say about this should not be interpreted as a veto of some kind. You are our window-management czar: if you think my objections should be overruled, by all means go ahead and make the changes. > >> Naively spoken it's obvious that when you shrink the minibuffer you show > >> more lines in the window above and ‘linum-mode’ has to add numbers for > >> those lines. And when you enlarge the minibuffer, ‘follow-mode’ will > >> lose some lines at the bottom of the left window and has to show them at > >> the top of the right window. > > > > In well-behaved modes this happens automatically, as part of > > redisplay. > > Via ‘pre-redisplay-function’? No, by arranging the buffer contents and letting redisplay do its job. Problems of this kind happen only when a mode changes buffer contents and related data structures (such as properties and overlays) in response to redisplay, something that is bad idea to begin with, because at the very least it immediately triggers another redisplay cycle, and kills many redisplay optimizations. > >> Maybe they use the ‘post-command-hook’ function instead. > > > > Of course, they do! The flag of bad design. > > IIUC they didn't have another choice before ‘pre-redisplay-function’ was > added. IMO, lack of infrastructure is not an excuse for bad design. Either the missing infrastructure should be added, or the design changed (if possible) to some better-behaving alternative. In extreme cases, the whole idea should be dropped as unworkable. > >> This is, in fact, an abuse of ‘set-window-configuration’. But how fix > >> it? We'd need a hook, say ‘window-size-change-functions’, that tracks, > >> among other things, whether a window was resized due to a change of the > >> minibuffer height and, if that happens, set a flag to indicate that the > >> window configuration must be restored. > > > > I'd say, don't set the "size changed" flag unless the size really > > changed. > > Sure. Nevertheless we would have to also track changes due to automatic > minibuffer resizing. As an option, perhaps. And it should be opt-in IMO, because most use cases shouldn't care about automatic resizing such as this one. > Alternatively, Fset_window_configuration could run a modified version of > ‘compare-window-configurations’ to compare the current configuration > with the one to be restored and restore the old configuration iff these > differ. I'm not sure whether this would be any cheaper, especially when > the configuration does change frequently. As I said too many times in this thread, performance is the last thing I care about in this respect. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 11:12:54 2015 Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 15:12:55 +0000 Received: from localhost ([127.0.0.1]:38169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFuA-0005Jf-94 for submit@debbugs.gnu.org; Tue, 25 Aug 2015 11:12:54 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:33493) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFu7-0005JV-Fe for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 11:12:52 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NTN001008QJIG00@a-mtaout22.012.net.il> for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 18:12:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTN001VO8XDBB30@a-mtaout22.012.net.il>; Tue, 25 Aug 2015 18:12:50 +0300 (IDT) Date: Tue, 25 Aug 2015 18:12:39 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DC185A.4080101@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83oahvfllk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 25 Aug 2015 09:25:14 +0200 > From: martin rudalics > CC: 21333@debbugs.gnu.org > > > But the coordinates of the text that stays on screen don't change in > > such a resize. Some text is obscured, but what's left doesn't move. > > So I see no problem here. > > I'm not sure what you mean here: When the minibuffer resizes and point > is near the bottom of the window above, the window above will scroll and > stick to the new window start position even after the minibuffer gets > sized back. When the window above the minibuffer is a one line window > or fixed-size, the window above that window will be subject to those > changes. In these two cases, yes. In all the others (which are vast majority), no. And I'm still not sure I understand the relevance. How exactly knowing about the automatic resize will help with coordinates in this case? If the Lisp program recomputes coordinates inside the hook, it will get the same results in most cases (when point is not in the obscured lines). So an alternative that doesn't need any hook is simply to recompute the coordinates every time they are needed. It's not like this calculation is expensive, is it? > > No, it's not. It's the same issue: this hook is already called in > > situations where it shouldn't have been, and thus imposes on the > > programmers who use it complex ways of deciding whether there was or > > wasn't a change they should care about. You suggest to add one more > > situation in that class, something that most application that define > > this hook shouldn't and don't care. It's the complexity that worries > > me. > > You mean when ‘set-window-configuration’ doesn't change the size of a > single window the hook shouldn't be called? Yes, of course. > Ideally it shouldn't but this is a problem similar to that of > indenting a paragraph changing the buffer modified state although in > reality nothing changed. And we get regular complaints about that as well. Moreover, the setting of the modified status by fill-paragraph is just an annoyance that doesn't cost anyone any extra complexity, whereas the situation with this and similar hooks costs us quite a lot in that aspect. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 11:19:31 2015 Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 15:19:31 +0000 Received: from localhost ([127.0.0.1]:38174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUG0Z-0005TS-Cy for submit@debbugs.gnu.org; Tue, 25 Aug 2015 11:19:31 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:42712) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUG0W-0005TH-A2 for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 11:19:29 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NTN001008QYM300@mtaout25.012.net.il> for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 18:15:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTN002GL92LR000@mtaout25.012.net.il>; Tue, 25 Aug 2015 18:15:58 +0300 (IDT) Date: Tue, 25 Aug 2015 18:19:16 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83mvxfflaj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 25 Aug 2015 10:34:23 +0000 > From: Pip Cet > Cc: Eli Zaretskii , 21333@debbugs.gnu.org > > > Via ‘pre-redisplay-function’? > > Well, we have `pre-redisplay-functions', with an s, defined in > simple.el That's a Lisp-level trick, but the variable used by the display engine is pre-redisplay-function, without an s. > That's what my code does. I thought I could get away with using the > arguments passed to pre-redisplay-function to limit which windows to > check, but that doesn't work when we "goto retry" and re-run > pre-redisplay-function. Not sure I understand why it wouldn't work. Can you elaborate? The way I see it, the windows passed to pre-redisplay-function are those that needed redisplay, so if the list is different on the second call, the rest of the windows were already redisplayed, and your hook shouldn't care about them, because you already processed them on the previous call. > I will study the code in xdisp.c further and see whether I can > understand what the purpose of must_finish is. We have "goto retry" in redisplay_internal in more than one place, and only one of them is conditioned by must_finish. In general must_finish is true when we must complete the redisplay cycle by calling update_frame. But I'm not sure this answers your question in full. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 03:08:54 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 07:08:54 +0000 Received: from localhost ([127.0.0.1]:38533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUUpK-0002YQ-Df for submit@debbugs.gnu.org; Wed, 26 Aug 2015 03:08:54 -0400 Received: from mout.gmx.net ([212.227.17.20]:64955) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUUpI-0002YH-CV for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 03:08:52 -0400 Received: from [194.166.87.107] ([194.166.87.107]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MCOdh-1ZczHm0uwr-009Bvq; Wed, 26 Aug 2015 09:08:51 +0200 Message-ID: <55DD65FD.1000206@gmx.at> Date: Wed, 26 Aug 2015 09:08:45 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:lDyZqoaOtJVTyPkv/49kJDysJ1R+pmtA/PTne11nv/SiHs6kEaW 8BVRV7Z9CIFnjNJcWaHxXrFzQRtvLCLodabj+m4L8zKRgt5abH9uwQ54yGZrtCRCPOmSEPN MIdmj7ShJ1vqX6DU4YzmienBH/UbDQIACk3IDqpBH6yKoPNPnNe+xEBHgMalOY1rvYS/cnP qWAicrWzLXe5st2wWmtqw== X-UI-Out-Filterresults: notjunk:1;V01:K0:hqHHEu3X15k=:df7YRe+FzZCWUkVAMEyZKE vg5hCpXg4k1GVZ9aP7Tkz+CnqxgzSAU7qD+7SjKfOq5VVKAgM9xg5N4uD4DsQvUKYQa1sf4LY 8mer6ROy94+2/STuEvi0bObkrjk7DvlJGToDjFFxhkUKKuRhB5LYREgywvMxenpNh0E2mT7ew EZVTQojiFn/Om+tUFYCwlmYNf2GyzMZ306dvQroE/B6TPfsAQmH6NowHDMT2VIdAU9jJEYjL8 njT93SqPNXmV4Kn8+xUCNEj/WyJRPsQpyyEHDLaTcqXizJOTxhiM4xXeaCKvIGuJ92HRPZT6k sInaB0M/XSrXeEiXi3gfMSZttxet1YwIRvLxgeq4oQYC+6oeu5GPjDVUvxMlvBD4CbFmRR99d 89fEVFZYS1eXQP2USAe/l58Tc3bAGA8h2/AjEnYtDU7XWWQtvD3DhDTpDdol88eSiMqoLfAKg h+nVoQ95vgWsLu3g5O8WlNuI4AV5wDTzAVOKWK9M5mB+U9UsI6vZUiRR2A3G6+JkVZl6oO/XV zQd0h3ulVn5JKs+fqBO9dRUDuut8ejSyUQfKIxmW6DGZXaz42xOlmcOrwzjDK1c/bBqcFVMi6 sfp7tALzRhSmaZLeGb65Ue0c6sj+i4b6fh7XV1iv+S6kR0DSLzG5LfJo51IYNQFyjc94xjcLg gI/MHUOXHnOQ0JdL+yEy6iafDlydFKL+ZFQOMKi03LRP+6zcnGhXxtTMXf9ZKykYT5DiorS3H A9k32f+OXHGoUX6PNhfnzqOZOcH+cxil4np7dg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I do think it would be best not to use set-window-configuration in > restoring state after exiting the minibuffer at all. I profoundly dislike window configurations but in this particular case they are needed. If the minibuffer gets enlarged, a window above it shrinks and as a consequence that window's start position changes to keep point on screen, it's important to restore the previous start position of that window. Everything else would be disconcerting. >> Alternatively, Fset_window_configuration could run a modified version= of >> =91compare-window-configurations=92 to compare the current configurat= ion >> with the one to be restored and restore the old configuration iff the= se >> differ. I'm not sure whether this would be any cheaper, especially w= hen >> the configuration does change frequently. > > I think it would be better to do this explicitly, even if we have to > compare all properties. You mean to compare the properties one can get by walking all windows on the frame with those of the configuration that shall be restored? Note that looking into a window configuration is not entirely trivial. > + if (!FRAME_WINDOW_SIZES_CHANGED (f)) { For consistency, please don't use hanging braces. > + if (w->pixel_left !=3D XFASTINT (p->pixel_left) || > + w->pixel_top !=3D XFASTINT (p->pixel_top) || Why do you think we need to check these? martin From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 03:09:39 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 07:09:39 +0000 Received: from localhost ([127.0.0.1]:38537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUUq2-0002Zk-U9 for submit@debbugs.gnu.org; Wed, 26 Aug 2015 03:09:39 -0400 Received: from mout.gmx.net ([212.227.17.22]:57013) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUUq0-0002Zb-8m for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 03:09:36 -0400 Received: from [194.166.87.107] ([194.166.87.107]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M5Z5A-1YXCBb2UA4-00xeOE; Wed, 26 Aug 2015 09:09:35 +0200 Message-ID: <55DD662A.8080201@gmx.at> Date: Wed, 26 Aug 2015 09:09:30 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> In-Reply-To: <83pp2bfln1.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:V9/VGocsvd0akLDF5wtiH9JSukNQ7AaVDoj+upXl4uWUjKUSyaS nuPJzYZcSpYMz3si6fnG2MiODgxtRJhp6DwR45B6XrKgclcI/rLQcEItdW/sWjxIGO+4FqH 9RVGKQ6IO/QDrYA9d+/TeFdIcf3B+yEe22lGKhObpCwh8OFe53H1ueC4m3vxqpktjVRCFsK GjohhyKtSv4z34NakhNOw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Mcrb5GBpWqo=:ETzvwZ3ki7DpsrRhau0bJf ZVR6h2XsfRxiX9qRQevq6dpSescazKt4a7vysW0yH9U7bdi5NJe9qlqde03t45Wxg3DH5DjKk mawSvL+LkfvdXGlSxZVqSIwl8pRzyGVdzaeX0ZEg99hcrg2gctUwNjlSO0GTdn5iWI/51l+4p gyjWT2WtnIWF7SRPz0Crqbmu+4MAnDCmrDU+zzIUsYaHE/+p3zFJ5/cgE2PoAmf1NdHzxtkyF h2pJD8xiFQgwNMhpCufesiT9iE5zFQCtvTmbUD4A8+F3TaFRUUEor+Rzf271HkkF8y4aEZJAP yHMj3/q770uSQtEk5cZEZZ/Z3TwoPCG+HZhQWZtoJ04KMgCPsxOcX9bfR3I6em8OoEIgcGFsn +PYnm34EfLsA4Fmuu7sclxyrKcw5soTLPWIMnz0hMVHrlL5kaZgowyh/apSRAP5GPCLufGN79 HlglIbSjoksEGxrqVZBWGyJZXkxMoKMTsJqFKWKle5sdXjlVOknQ17oWKg91XxDayBaGxS6qh fLIH4uX0Iuh0onm19H8ZzCduDDeQDrVuILcu9LVyFm01fpLxtCmu1q+LhGyVCycgluG/hmnmT d+8JI/LcATWirJRjZw1B9CxA7FthfAiirXanWhxLwWILEl5rMXedzZFTI+P2kaYUaCk1oMa0M NQrtQJdA7T/UydU0j76EsZsnrwgZPo0iCtfZC2cuR7ZmU39AaZVcTQ5BpmDGgKN3IGLm0bxZ/ QFw3p3Os+Zp+tiWwxqdmR/DmvlISLP9jAcK/0g== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > You are > our window-management czar: A carpenter, at best. > No, by arranging the buffer contents and letting redisplay do its > job. Problems of this kind happen only when a mode changes buffer > contents and related data structures (such as properties and overlays)= > in response to redisplay, something that is bad idea to begin with, > because at the very least it immediately triggers another redisplay > cycle, and kills many redisplay optimizations. =E2=80=98follow-mode=E2=80=99, to stick to one of the examples I cited ea= rlier, uses neither properties nor overlays. It must, however, know the exact =E2=80=98window-end=E2=80=99 position of any window that could be followe= d by another. This also means that a correct implementation of =E2=80=98follow-mode=E2=80= =99 should be allowed to specify the order in which windows are redisplayed. So ideally, redisplay would be able to process each window separately, tell us its new start and end positions and allow modes to react properly. > IMO, lack of infrastructure is not an excuse for bad design. Either > the missing infrastructure should be added, or the design changed (if > possible) to some better-behaving alternative. In extreme cases, the > whole idea should be dropped as unworkable. I'm convinced that the current version of =E2=80=98linum-mode=E2=80=99 do= esn't behave well and line numbers should be calculated and written by the display engine. But I'm too lazy to do that (probably because I don't use line numbers myself). > As an option, perhaps. And it should be opt-in IMO, because most use > cases shouldn't care about automatic resizing such as this one. So let's provide an option for this. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 03:09:58 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 07:09:58 +0000 Received: from localhost ([127.0.0.1]:38540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUUqM-0002aH-CO for submit@debbugs.gnu.org; Wed, 26 Aug 2015 03:09:58 -0400 Received: from mout.gmx.net ([212.227.17.22]:61981) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUUqJ-0002aB-Sm for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 03:09:56 -0400 Received: from [194.166.87.107] ([194.166.87.107]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lwnem-1YfxbV39nE-016Pig; Wed, 26 Aug 2015 09:09:53 +0200 Message-ID: <55DD663C.4040504@gmx.at> Date: Wed, 26 Aug 2015 09:09:48 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> In-Reply-To: <83oahvfllk.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:/nGZCEhJTKqwWbfGj0jjyIij4GrYa/55JsJ3xjLUWNtmGlhUdft SRmWfhIBA1laUrBbync0K64Ysc7n09ex5UTroeHiumnnDDZ7r/3Sn6QB9ouiUQhS+AKeXbN QWu/0vc9yjpmediSwgzO1ko1q41h7y4T5aqdDxI2wLZvZpm0CsYCheE7zGjIOyPeZT/4yyy knQqYKqaGzo6jFIwC/3tA== X-UI-Out-Filterresults: notjunk:1;V01:K0:LnSHH581uMU=:TaG3h1+YsT1GEC3Kzv0UQf jocYqjj9p1ZQ2vmeqT0mzfuRu5BUiCIUqProbKuYZ2R+DVY94AE6yqgvtoLKzVv0TGzg/81KJ ej85glQfgmFi7o/htbXOUqH4xhNKaBG8MBFoMnzDNxJPCJ0jaMp4K97EMSSjxXbNCvLz4LSW8 WjD7bNdIJa5Z4OFi9tLUX4ppTN9K1DRGHhiMvyBuQLFGNY7jxghNolzrkQA7lp42JZZUxcz41 6U6My5Z41Ch4k56+QchmSMfLKqRJsUZwNHzh++sbv32A6tGptHViLoq4BcH1oC/+xz+aJ66uY EmVUQZg9yhTSzyEfZOpLKMdUftIWyNOul/hi48OL7KtX5U7uiMt6EeqrCdqXNP5y6MBFqTYLc VV8M7954wMoioCwvV6WDUNg1WGHFes6B6/SS5jdp5W76eoRMsS73tSMduo39XGlI0wIFjYI9N 8IKaa0Tpwkuabz17DEg2gQfNUBMhInTNS6alIWoXREWfFkoWyi1VIVU7FIEQgHgYga/JvnJ7W WPAkJBVeU/Ym0aKDucmmc5rnS6Fuu4rmEu6FOU1z90u3kNCcJfHRX1xNFai37wC8LFx6o9JWE cHuwAAKg3l6SXSreA0lYV/K6HLA3pbYR5Z2uOmmAjHZ5SSUIEtVLZmHOVeyxa0ip618ClU2uK Bb4kbXAdpl79Eka50QqZjW4l8b6wpMRzzZpjldL0HjeZH64PsNR9xfNy5eQAoHbxGHWFnHc8q vRPjNMaeZj4bqK9R8jD08CtDCQUldlvs+dTgnw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > And I'm still not sure I understand the relevance. How exactly > knowing about the automatic resize will help with coordinates in this > case? If the Lisp program recomputes coordinates inside the hook, it > will get the same results in most cases (when point is not in the > obscured lines). So an alternative that doesn't need any hook is > simply to recompute the coordinates every time they are needed. It's > not like this calculation is expensive, is it? Correct. So =E2=80=98window-size-change-functions=E2=80=99 is dispensabl= e. > And we get regular complaints about that as well. Moreover, the > setting of the modified status by fill-paragraph is just an annoyance > that doesn't cost anyone any extra complexity, whereas the situation > with this and similar hooks costs us quite a lot in that aspect. But you don't worry about performance anyway. OTOH for the person who writes the function on the hook it might hardly matter whether some window size really changed. The more important case might be to not miss one single case where the size really changes. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 06:07:35 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 10:07:35 +0000 Received: from localhost ([127.0.0.1]:38566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUXcE-0006dm-5F for submit@debbugs.gnu.org; Wed, 26 Aug 2015 06:07:35 -0400 Received: from mail-ig0-f194.google.com ([209.85.213.194]:36587) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUXc9-0006da-4i for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 06:07:30 -0400 Received: by igcwe12 with SMTP id we12so1026620igc.3 for <21333@debbugs.gnu.org>; Wed, 26 Aug 2015 03:07:28 -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=DmwoU1aayO3hgpgYHGcAx+i/Z/A/dHi5oTENKie4cxI=; b=h1zFS+k1zJNef7lz7bmNgBXUxccgyygS0DP/BeSfzRvHW7dJky1sROd8DbMVs3teQi ptbqIKRJq/6UhvGqh9WzWr8eSFkzwMFXboPVxeWrzVM5IfBXHoesNfLnAow/SPDZGnPH SIMsHNy72u67XmT2PdrhhPPHJpU9H+BGDHhgDKI0QFiIo3tGIbonImJ/B4+9sCDfygpB SRPb54phcq/PygEeJupUdzTf9vjYQIueP6cE1Lbc0XlM5jTvMdUfjUZ19IwXXel+2N9o dqaJC2+nfRhk+x8oLdwPBw+Lbta04Y+2+ecuTYw3kUKPK8tsLzzbI2sGmR+v9w3FfH8+ GdKA== MIME-Version: 1.0 X-Received: by 10.50.17.9 with SMTP id k9mr2445548igd.93.1440583648667; Wed, 26 Aug 2015 03:07:28 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Wed, 26 Aug 2015 03:07:28 -0700 (PDT) In-Reply-To: <55DD663C.4040504@gmx.at> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> Date: Wed, 26 Aug 2015 10:07:28 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: martin rudalics Content-Type: multipart/mixed; boundary=089e01182a34a60eb7051e34048a X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e01182a34a60eb7051e34048a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2015 at 7:09 AM, martin rudalics wrote: >> So an alternative that doesn't need any hook is >> simply to recompute the coordinates every time they are needed. It's >> not like this calculation is expensive, is it? > > Correct. I disagree, if I understand correctly. The coordinates might be passed to another program, for example, and then we simply don't know when that program decides to use them, so we still need a way to update our (and its) idea of what the window size and position is, in my opinion. > So =E2=80=98window-size-change-functions=E2=80=99 is dispensable. Iff we keep/fix pre-redisplay-function, I agree. I had, wrongly, assumed that pre-redisplay-function is run many times per redisplay call, but that appears to be incorrect. The huge majority of redisplays call it just once, and that makes the overhead negligible. So what's the way forward, assuming my paperwork ever gets here? - document window-size-change-functions aren't called for mini-window resi= zes - document window-configuration-change-hook isn't called for mini-window resizes - document set-window-configuration doesn't call window-size-change-functions if nothing changed - fix set_window_configuration not to set the window size change flag unless there was an actual size change - wishlist item: call pre-redisplay-function between grow/shrink_mini_window and the actual X repaint, rather than before. - mark window-size-change-functions as obsolete and see whether anyone complains? > OTOH for the person who > writes the function on the hook it might hardly matter whether some > window size really changed. The more important case might be to not > miss one single case where the size really changes. Precisely. --089e01182a34a60eb7051e34048a Content-Type: text/x-patch; charset=US-ASCII; name="0001-Document-and-fix-behavior-of-window-pre-redisplay-ho.patch" Content-Disposition: attachment; filename="0001-Document-and-fix-behavior-of-window-pre-redisplay-ho.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idsmaw6o0 RnJvbSBiZjBjMDYxNTM5MmI3Zjc5NmMyMzY5MGUxMDYyMGUyMWE1OTI2YWQ0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFdlZCwg MjYgQXVnIDIwMTUgMDk6MzQ6MTIgKzAwMDAKU3ViamVjdDogW1BBVENIXSBEb2N1bWVudCBhbmQg Zml4IGJlaGF2aW9yIG9mIHdpbmRvdy9wcmUtcmVkaXNwbGF5IGhvb2tzLgoKICAgICAgICAqIHhk aXNwLmMgKHJlZGlzcGxheV9pbnRlcm5hbCk6IENhbGwgYHByZS1yZWRpc3BsYXktZnVuY3Rpb24n CglhZnRlciByZXNpemluZyBtaW5pLXdpbmRvd3MgcmF0aGVyIHRoYW4gYmVmb3JlLgoJKiB3aW5k b3cuYyAoRnNldF93aW5kb3dfY29uZmlndXJhdGlvbik6IE9ubHkgc2V0IHRoZSB3aW5kb3cgc2l6 ZQoJY2hhbmdlIGZsYWcgaWYgYSB3aW5kb3cgYWN0dWFsbHkgY2hhbmdlZCBzaXplLgogICAgICAg CSogd2luZG93cy50ZXhpIChXaW5kb3cgQ29uZmlndXJhdGlvbnMpOiBEb2N1bWVudAoJYHdpbmRv dy1zaXplLWNoYW5nZS1mdW5jdGlvbnMnIGlzbid0IGNhbGxlZCBmb3IgbWluaS13aW5kb3cKCXJl c2l6ZXMuCgkoV2luZG93IEhvb2tzKTogTGlrZXdpc2UsIGxpa2V3aXNlIGZvcgoJYHdpbmRvdy1j b25maWd1cmF0aW9uLWNoYW5nZS1ob29rJy4KLS0tCiBkb2MvbGlzcHJlZi93aW5kb3dzLnRleGkg fCAzNCArKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tCiBzcmMvd2luZG93LmMgICAg ICAgICAgICAgfCAgOCArKysrKysrLQogc3JjL3hkaXNwLmMgICAgICAgICAgICAgIHwgNDYgKysr KysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0tLQogMyBmaWxlcyBjaGFu Z2VkLCA0OCBpbnNlcnRpb25zKCspLCA0MCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kb2Mv bGlzcHJlZi93aW5kb3dzLnRleGkgYi9kb2MvbGlzcHJlZi93aW5kb3dzLnRleGkKaW5kZXggNDY1 NjkzOC4uYmI5YTVkMiAxMDA2NDQKLS0tIGEvZG9jL2xpc3ByZWYvd2luZG93cy50ZXhpCisrKyBi L2RvYy9saXNwcmVmL3dpbmRvd3MudGV4aQpAQCAtMzk3MSwxMSArMzk3MSw3IEBAIHdhcyBjcmVh dGVkIGZvci4KIFRoZSBhcmd1bWVudCBAdmFye2NvbmZpZ3VyYXRpb259IG11c3QgYmUgYSB2YWx1 ZSB0aGF0IHdhcyBwcmV2aW91c2x5CiByZXR1cm5lZCBieSBAY29kZXtjdXJyZW50LXdpbmRvdy1j b25maWd1cmF0aW9ufS4gIFRoZSBjb25maWd1cmF0aW9uIGlzCiByZXN0b3JlZCBpbiB0aGUgZnJh bWUgZnJvbSB3aGljaCBAdmFye2NvbmZpZ3VyYXRpb259IHdhcyBtYWRlLCB3aGV0aGVyCi10aGF0 IGZyYW1lIGlzIHNlbGVjdGVkIG9yIG5vdC4gIFRoaXMgYWx3YXlzIGNvdW50cyBhcyBhIHdpbmRv dyBzaXplCi1jaGFuZ2UgYW5kIHRyaWdnZXJzIGV4ZWN1dGlvbiBvZiB0aGUgQGNvZGV7d2luZG93 LXNpemUtY2hhbmdlLWZ1bmN0aW9uc30KLShAcHhyZWZ7V2luZG93IEhvb2tzfSksIGJlY2F1c2Ug QGNvZGV7c2V0LXdpbmRvdy1jb25maWd1cmF0aW9ufSBkb2Vzbid0Ci1rbm93IGhvdyB0byB0ZWxs IHdoZXRoZXIgdGhlIG5ldyBjb25maWd1cmF0aW9uIGFjdHVhbGx5IGRpZmZlcnMgZnJvbSB0aGUK LW9sZCBvbmUuCit0aGF0IGZyYW1lIGlzIHNlbGVjdGVkIG9yIG5vdC4KIAogSWYgdGhlIGZyYW1l IGZyb20gd2hpY2ggQHZhcntjb25maWd1cmF0aW9ufSB3YXMgc2F2ZWQgaXMgZGVhZCwgYWxsIHRo aXMKIGZ1bmN0aW9uIGRvZXMgaXMgcmVzdG9yZSB0aGUgdGhyZWUgdmFyaWFibGVzIEBjb2Rle3dp bmRvdy1taW4taGVpZ2h0fSwKQEAgLTQwMTAsOCArNDAwNiw4IEBAIHdpbmRvd3MgbWlnaHQgYmUg b3BlbmVkIGluIG90aGVyIGZyYW1lcyAoQHB4cmVme0Nob29zaW5nIFdpbmRvd30pLCBhbmQKIGNv bmZpZ3VyYXRpb24gb24gdGhlIGN1cnJlbnQgZnJhbWUuCiAKIERvIG5vdCB1c2UgdGhpcyBtYWNy byBpbiBAY29kZXt3aW5kb3ctc2l6ZS1jaGFuZ2UtZnVuY3Rpb25zfTsgZXhpdGluZwotdGhlIG1h Y3JvIHRyaWdnZXJzIGV4ZWN1dGlvbiBvZiBAY29kZXt3aW5kb3ctc2l6ZS1jaGFuZ2UtZnVuY3Rp b25zfSwKLWxlYWRpbmcgdG8gYW4gZW5kbGVzcyBsb29wLgordGhlIG1hY3JvIGNhbiB0cmlnZ2Vy IGV4ZWN1dGlvbiBvZgorQGNvZGV7d2luZG93LXNpemUtY2hhbmdlLWZ1bmN0aW9uc30sIGxlYWRp bmcgdG8gYW4gZW5kbGVzcyBsb29wLgogQGVuZCBkZWZtYWMKIAogQGRlZnVuIHdpbmRvdy1jb25m aWd1cmF0aW9uLXAgb2JqZWN0CkBAIC00MjYyLDEwICs0MjU4LDkgQEAgd29yay4KIEBlbmQgZGVm dmFyCiAKIEBkZWZ2YXIgd2luZG93LXNpemUtY2hhbmdlLWZ1bmN0aW9ucwotVGhpcyB2YXJpYWJs ZSBob2xkcyBhIGxpc3Qgb2YgZnVuY3Rpb25zIHRvIGJlIGNhbGxlZCBpZiB0aGUgc2l6ZSBvZiBh bnkKLXdpbmRvdyBjaGFuZ2VzIGZvciBhbnkgcmVhc29uLiAgVGhlIGZ1bmN0aW9ucyBhcmUgY2Fs bGVkIGp1c3Qgb25jZSBwZXIKLXJlZGlzcGxheSwgYW5kIGp1c3Qgb25jZSBmb3IgZWFjaCBmcmFt ZSBvbiB3aGljaCBzaXplIGNoYW5nZXMgaGF2ZQotb2NjdXJyZWQuCitUaGlzIHZhcmlhYmxlIGhv bGRzIGEgbGlzdCBvZiBmdW5jdGlvbnMgdG8gYmUgY2FsbGVkIGlmIHRoZSBzaXplIG9mCithbnkg d2luZG93IGNoYW5nZXMuICBUaGUgZnVuY3Rpb25zIGFyZSBjYWxsZWQganVzdCBvbmNlIHBlciBy ZWRpc3BsYXksCithbmQganVzdCBvbmNlIGZvciBlYWNoIGZyYW1lIG9uIHdoaWNoIHNpemUgY2hh bmdlcyBoYXZlIG9jY3VycmVkLgogCiBFYWNoIGZ1bmN0aW9uIHJlY2VpdmVzIHRoZSBmcmFtZSBh cyBpdHMgc29sZSBhcmd1bWVudC4gIFRoZXJlIGlzIG5vCiBkaXJlY3Qgd2F5IHRvIGZpbmQgb3V0 IHdoaWNoIHdpbmRvd3Mgb24gdGhhdCBmcmFtZSBoYXZlIGNoYW5nZWQgc2l6ZSwgb3IKQEAgLTQy NzUsMjAgKzQyNzAsMjMgQEAgcHJlc2VudCBzaXplcyBhbmQgdGhlIHByZXZpb3VzIHNpemVzLgog CiBDcmVhdGluZyBvciBkZWxldGluZyB3aW5kb3dzIGNvdW50cyBhcyBhIHNpemUgY2hhbmdlLCBh bmQgdGhlcmVmb3JlCiBjYXVzZXMgdGhlc2UgZnVuY3Rpb25zIHRvIGJlIGNhbGxlZC4gIENoYW5n aW5nIHRoZSBmcmFtZSBzaXplIGFsc28KLWNvdW50cywgYmVjYXVzZSBpdCBjaGFuZ2VzIHRoZSBz aXplcyBvZiB0aGUgZXhpc3Rpbmcgd2luZG93cy4KK2NvdW50cywgYmVjYXVzZSBpdCBjaGFuZ2Vz IHRoZSBzaXplcyBvZiB0aGUgZXhpc3Rpbmcgd2luZG93cy4gIFdoZW4KK3RoZSBtaW5pYnVmZmVy IG9yIGVjaG8gYXJlYSBncm93cyBvciBzaHJpbmtzLCB0aGVzZSBmdW5jdGlvbnMgYXJlIG5vdAor Y2FsbGVkLgogCiBZb3UgbWF5IHVzZSBAY29kZXtzYXZlLXNlbGVjdGVkLXdpbmRvd30gaW4gdGhl c2UgZnVuY3Rpb25zCiAoQHB4cmVme1NlbGVjdGluZyBXaW5kb3dzfSkuICBIb3dldmVyLCBkbyBu b3QgdXNlCiBAY29kZXtzYXZlLXdpbmRvdy1leGN1cnNpb259IChAcHhyZWZ7V2luZG93IENvbmZp Z3VyYXRpb25zfSk7IGV4aXRpbmcKLXRoYXQgbWFjcm8gY291bnRzIGFzIGEgc2l6ZSBjaGFuZ2Us IHdoaWNoIHdvdWxkIGNhdXNlIHRoZXNlIGZ1bmN0aW9ucwotdG8gYmUgY2FsbGVkIG92ZXIgYW5k IG92ZXIuCit0aGF0IG1hY3JvIGNhbiBjb3VudCBhcyBhIHNpemUgY2hhbmdlLCB3aGljaCB3b3Vs ZCBjYXVzZSB0aGVzZQorZnVuY3Rpb25zIHRvIGJlIGNhbGxlZCBvdmVyIGFuZCBvdmVyLgogQGVu ZCBkZWZ2YXIKIAogQGRlZnZhciB3aW5kb3ctY29uZmlndXJhdGlvbi1jaGFuZ2UtaG9vawotQSBu b3JtYWwgaG9vayB0aGF0IGlzIHJ1biBldmVyeSB0aW1lIHlvdSBjaGFuZ2UgdGhlIHdpbmRvdyBj b25maWd1cmF0aW9uCi1vZiBhbiBleGlzdGluZyBmcmFtZS4gIFRoaXMgaW5jbHVkZXMgc3BsaXR0 aW5nIG9yIGRlbGV0aW5nIHdpbmRvd3MsCi1jaGFuZ2luZyB0aGUgc2l6ZXMgb2Ygd2luZG93cywg b3IgZGlzcGxheWluZyBhIGRpZmZlcmVudCBidWZmZXIgaW4gYQotd2luZG93LgorQSBub3JtYWwg aG9vayB0aGF0IGlzIHJ1biBldmVyeSB0aW1lIHlvdSBjaGFuZ2UgdGhlIHdpbmRvdworY29uZmln dXJhdGlvbiBvZiBhbiBleGlzdGluZyBmcmFtZS4gIFRoaXMgaW5jbHVkZXMgc3BsaXR0aW5nIG9y CitkZWxldGluZyB3aW5kb3dzLCBjaGFuZ2luZyB0aGUgc2l6ZXMgb2Ygd2luZG93cywgb3IgZGlz cGxheWluZyBhCitkaWZmZXJlbnQgYnVmZmVyIGluIGEgd2luZG93LiBIb3dldmVyLCB0aGlzIGhv b2sgaXMgbm90IHJ1biBmb3IgYSBzaXplCitjaGFuZ2UgdGhhdCBpcyBzb2xlbHkgZHVlIHRvIGEg cmVzaXplZCBtaW5pYnVmZmVyIG9yIGVjaG8gYXJlYS4KIAogVGhlIGJ1ZmZlci1sb2NhbCBwYXJ0 IG9mIHRoaXMgaG9vayBpcyBydW4gb25jZSBmb3IgZWFjaCB3aW5kb3cgb24gdGhlCiBhZmZlY3Rl ZCBmcmFtZSwgd2l0aCB0aGUgcmVsZXZhbnQgd2luZG93IHNlbGVjdGVkIGFuZCBpdHMgYnVmZmVy CmRpZmYgLS1naXQgYS9zcmMvd2luZG93LmMgYi9zcmMvd2luZG93LmMKaW5kZXggODYzYTc5Mi4u YmUxNjkzYyAxMDA2NDQKLS0tIGEvc3JjL3dpbmRvdy5jCisrKyBiL3NyYy93aW5kb3cuYwpAQCAt NjA3Miw3ICs2MDcyLDYgQEAgdGhlIHJldHVybiB2YWx1ZSBpcyBuaWwuICBPdGhlcndpc2UgdGhl IHZhbHVlIGlzIHQuICAqLykKIAl9CiAKICAgICAgIGZzZXRfcmVkaXNwbGF5IChmKTsKLSAgICAg IEZSQU1FX1dJTkRPV19TSVpFU19DSEFOR0VEIChmKSA9IHRydWU7CiAKICAgICAgIC8qIFByb2Js ZW06IEZyZWVpbmcgYWxsIG1hdHJpY2VzIGFuZCBsYXRlciBhbGxvY2F0aW5nIHRoZW0gYWdhaW4K IAkgaXMgYSBzZXJpb3VzIHJlZGlzcGxheSBmbGlja2VyaW5nIHByb2JsZW0uICBXaGF0IHdlIHdv dWxkCkBAIC02MTI0LDYgKzYxMjMsMTMgQEAgdGhlIHJldHVybiB2YWx1ZSBpcyBuaWwuICBPdGhl cndpc2UgdGhlIHZhbHVlIGlzIHQuICAqLykKIAkgIC8qIElmIHdlIHNxdWlycmVsZWQgYXdheSB0 aGUgYnVmZmVyLCByZXN0b3JlIGl0IG5vdy4gICovCiAJICBpZiAoQlVGRkVSUCAody0+Y29tYmlu YXRpb25fbGltaXQpKQogCSAgICB3c2V0X2J1ZmZlciAodywgdy0+Y29tYmluYXRpb25fbGltaXQp OworICAgICAgICAgIGlmICghRlJBTUVfV0lORE9XX1NJWkVTX0NIQU5HRUQgKGYpKSB7CisgICAg ICAgICAgICBpZiAody0+cGl4ZWxfbGVmdCAhPSBYRkFTVElOVCAocC0+cGl4ZWxfbGVmdCkgfHwK KyAgICAgICAgICAgICAgICB3LT5waXhlbF90b3AgIT0gWEZBU1RJTlQgKHAtPnBpeGVsX3RvcCkg fHwKKyAgICAgICAgICAgICAgICB3LT5waXhlbF93aWR0aCAhPSBYRkFTVElOVCAocC0+cGl4ZWxf d2lkdGgpIHx8CisgICAgICAgICAgICAgICAgdy0+cGl4ZWxfaGVpZ2h0ICE9IFhGQVNUSU5UIChw LT5waXhlbF9oZWlnaHQpKQorICAgICAgICAgICAgICBGUkFNRV9XSU5ET1dfU0laRVNfQ0hBTkdF RCAoZikgPSB0cnVlOworICAgICAgICAgIH0KIAkgIHctPnBpeGVsX2xlZnQgPSBYRkFTVElOVCAo cC0+cGl4ZWxfbGVmdCk7CiAJICB3LT5waXhlbF90b3AgPSBYRkFTVElOVCAocC0+cGl4ZWxfdG9w KTsKIAkgIHctPnBpeGVsX3dpZHRoID0gWEZBU1RJTlQgKHAtPnBpeGVsX3dpZHRoKTsKZGlmZiAt LWdpdCBhL3NyYy94ZGlzcC5jIGIvc3JjL3hkaXNwLmMKaW5kZXggOGJlNzQ5Ny4uOTdmYzBkOCAx MDA2NDQKLS0tIGEvc3JjL3hkaXNwLmMKKysrIGIvc3JjL3hkaXNwLmMKQEAgLTExNTY2LDI3ICsx MTU2Niw2IEBAIHByZXBhcmVfbWVudV9iYXJzICh2b2lkKQogICB0b29sdGlwX2ZyYW1lID0gUW5p bDsKICNlbmRpZgogCi0gIGlmIChGVU5DVElPTlAgKFZwcmVfcmVkaXNwbGF5X2Z1bmN0aW9uKSkK LSAgICB7Ci0gICAgICBMaXNwX09iamVjdCB3aW5kb3dzID0gYWxsX3dpbmRvd3MgPyBRdCA6IFFu aWw7Ci0gICAgICBpZiAoYWxsX3dpbmRvd3MgJiYgc29tZV93aW5kb3dzKQotCXsKLQkgIExpc3Bf T2JqZWN0IHdzID0gd2luZG93X2xpc3QgKCk7Ci0JICBmb3IgKHdpbmRvd3MgPSBRbmlsOyBDT05T UCAod3MpOyB3cyA9IFhDRFIgKHdzKSkKLQkgICAgewotCSAgICAgIExpc3BfT2JqZWN0IHRoaXMg PSBYQ0FSICh3cyk7Ci0JICAgICAgc3RydWN0IHdpbmRvdyAqdyA9IFhXSU5ET1cgKHRoaXMpOwot CSAgICAgIGlmICh3LT5yZWRpc3BsYXkKLQkJICB8fCBYRlJBTUUgKHctPmZyYW1lKS0+cmVkaXNw bGF5Ci0JCSAgfHwgWEJVRkZFUiAody0+Y29udGVudHMpLT50ZXh0LT5yZWRpc3BsYXkpCi0JCXsK LQkJICB3aW5kb3dzID0gRmNvbnMgKHRoaXMsIHdpbmRvd3MpOwotCQl9Ci0JICAgIH0KLQl9Ci0g ICAgICBzYWZlX19jYWxsMSAodHJ1ZSwgVnByZV9yZWRpc3BsYXlfZnVuY3Rpb24sIHdpbmRvd3Mp OwotICAgIH0KLQogICAvKiBVcGRhdGUgYWxsIGZyYW1lIHRpdGxlcyBiYXNlZCBvbiB0aGVpciBi dWZmZXIgbmFtZXMsIGV0Yy4gIFdlIGRvCiAgICAgIHRoaXMgYmVmb3JlIHRoZSBtZW51IGJhcnMg c28gdGhhdCB0aGUgYnVmZmVyLW1lbnUgd2lsbCBzaG93IHRoZQogICAgICB1cC10by1kYXRlIGZy YW1lIHRpdGxlcy4gICovCkBAIC0xMzUxNCw2ICsxMzQ5MywzMSBAQCByZWRpc3BsYXlfaW50ZXJu YWwgKHZvaWQpCiAgICAgICBjbGVhcl9nYXJiYWdlZF9mcmFtZXMgKCk7CiAgICAgfQogCisgIGlm IChGVU5DVElPTlAgKFZwcmVfcmVkaXNwbGF5X2Z1bmN0aW9uKSkKKyAgICB7CisgICAgICBib29s IGFsbF93aW5kb3dzID0gd2luZG93c19vcl9idWZmZXJzX2NoYW5nZWQgfHwgdXBkYXRlX21vZGVf bGluZXM7CisgICAgICBib29sIHNvbWVfd2luZG93cyA9IFJFRElTUExBWV9TT01FX1AgKCk7Cisg ICAgICBMaXNwX09iamVjdCB3aW5kb3dzID0gYWxsX3dpbmRvd3MgPyBRdCA6IFFuaWw7CisKKyAg ICAgIGlmIChhbGxfd2luZG93cyAmJiBzb21lX3dpbmRvd3MpCisJeworCSAgTGlzcF9PYmplY3Qg d3MgPSB3aW5kb3dfbGlzdCAoKTsKKwkgIGZvciAod2luZG93cyA9IFFuaWw7IENPTlNQICh3cyk7 IHdzID0gWENEUiAod3MpKQorCSAgICB7CisJICAgICAgTGlzcF9PYmplY3QgdGhpcyA9IFhDQVIg KHdzKTsKKwkgICAgICBzdHJ1Y3Qgd2luZG93ICp3ID0gWFdJTkRPVyAodGhpcyk7CisJICAgICAg aWYgKHctPnJlZGlzcGxheQorCQkgIHx8IFhGUkFNRSAody0+ZnJhbWUpLT5yZWRpc3BsYXkKKwkJ ICB8fCBYQlVGRkVSICh3LT5jb250ZW50cyktPnRleHQtPnJlZGlzcGxheSkKKwkJeworCQkgIHdp bmRvd3MgPSBGY29ucyAodGhpcywgd2luZG93cyk7CisJCX0KKwkgICAgfQorCX0KKyAgICAgIHNh ZmVfX2NhbGwxICh0cnVlLCBWcHJlX3JlZGlzcGxheV9mdW5jdGlvbiwgd2luZG93cyk7CisgICAg fQorCisKICAgaWYgKHdpbmRvd3Nfb3JfYnVmZmVyc19jaGFuZ2VkICYmICF1cGRhdGVfbW9kZV9s aW5lcykKICAgICAvKiBDb2RlIHRoYXQgc2V0cyB3aW5kb3dzX29yX2J1ZmZlcnNfY2hhbmdlZCBk b2Vzbid0IGRpc3Rpbmd1aXNoIHdoZXRoZXIKICAgICAgICBvbmx5IHRoZSB3aW5kb3dzJ3MgY29u dGVudHMgbmVlZHMgdG8gYmUgcmVmcmVzaGVkLCBvciB3aGV0aGVyIHRoZQotLSAKMi41LjAKCg== --089e01182a34a60eb7051e34048a-- From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 09:01:34 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 13:01:34 +0000 Received: from localhost ([127.0.0.1]:38654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUaKc-0003fz-7v for submit@debbugs.gnu.org; Wed, 26 Aug 2015 09:01:34 -0400 Received: from mout.gmx.net ([212.227.15.18]:58133) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUaKZ-0003fq-J9 for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 09:01:32 -0400 Received: from [62.47.255.145] ([62.47.255.145]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MaJPk-1ZAqYZ3KXI-00JvW6; Wed, 26 Aug 2015 15:01:27 +0200 Message-ID: <55DDB8A2.8020606@gmx.at> Date: Wed, 26 Aug 2015 15:01:22 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:1zA3r3tgh3hVoYQXPV6TMwWhQ4pO8TWkqE88JeKJMt25PTU69Fy pj0RayDlX3X35UtQRcBLeO4kpD/DkIik/YRAm2aLHzXhe4sLX7o0FR25R2uROuoGjfFNAAs MB7MJ3qlaHllgybemus0Vsll54/LtIYt0T+oelPCDhJHIEpSFy4E7TlryUa6HGdRKrtkCTT +PMa70nyGNBOK2ghJ+l0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:Dh3P8fLWkFI=:6YR9Erl1J3Wn6j35RS17bO z6cwDcVj0ObdBgdPKiTpWfRnCS1flLmAOcQKxWdkpTxYQ582mDL//MmIob7pRD1KDRcPbic/T k88PqYMzEeQTv7wl+TVTeWh8MLJin3Ul1v/oXk2mJLq4ZzOYQlL+Nqsr7NIyosW8kbInyHp0E GayDo/zqyBYTTK9/XufXYNfIU0QqB2lw40xOL9zna/RPcGtWHfR/M0AzJAK9QMHGRUdt1Fjbf 562qaiYu3BS3gX/W7iRIuzaLoZbghPPIo92IVm2GdTgzNbZtk8PmtphKPpjqyqhvzFte04NwS Hx6RuvRha9Wyn5bnzt6OZgmmOKs3gAJR/SJa1VoHxohGO+tsvC9UAj+YZtlW28O21Fjz55iJJ tNrz7YkmRm9ZjcEvSEcEGwVx4oVW91Irj7r/sdVmypC9dPRBpQ0aIXz26nq7twq3GbsWhQOl0 2DCD5t0HYdhgXT+RjhAFSVMEHQcHTfa/m5S3EitBuO2HHtjw76qc/IZBeOjPU2WqU5+rEv8at z1rnaNQrHJarf/BoEYxmsNnjJ+fj4jW428QMb570vMmZPp2gReLCdVhvsgDEkaADrNHynfYlv WZPwImIUhXsurEbk6hXhDLHuziVx5b651JTz6FPGsPcyOp74jww6budtQJWGT3udTBtGHdFJI hUV5zzeT3uDhgihifte7K9kThynDSj1leGZ/2weKj3WAsRJ013o66M5SxRxxrxvQkzwVQKiE7 h0WqUdfI3RzYws3mrC4Q3dcpN5tuRQk7DtrRSQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>> So an alternative that doesn't need any hook is >>> simply to recompute the coordinates every time they are needed. It'= s >>> not like this calculation is expensive, is it? >> >> Correct. > > I disagree, if I understand correctly. My "correct" referred to Eli's "It's not like this calculation is expensive, is it?". I suppose we all agree on that. > The coordinates might be passed > to another program, for example, and then we simply don't know when > that program decides to use them, so we still need a way to update our= > (and its) idea of what the window size and position is, in my opinion.= I don't understand you here. IIUC Eli means that any application can store the old coordinates somewhere and easily compare them to the current ones in order to detect whether window sizes have changed. Even simpler: We could store the sizes in the window structure. This way prepare_menu_bars would simply walk the window tree of each frame to detect whether the size of any window has changed, call the functions on =91window-size-change-functions=92 and afterwards (better when redisplay completed) store the current size values into the old ones. The functions on the hook, OTOH, could check for each window individually whether and how its size changed. The advantage of this approach is that we never accumulate any fake size changes. >> So =91window-size-change-functions=92 is dispensable. > > Iff we keep/fix pre-redisplay-function, I agree. I had, wrongly, > assumed that pre-redisplay-function is run many times per redisplay > call, but that appears to be incorrect. The huge majority of > redisplays call it just once, and that makes the overhead negligible. We can declare =91window-size-change-functions=92 obsolete and suggest to= use =91pre-redisplay-function=92 instead. Still we'd have to support it = for quite some time. > So what's the way forward, assuming my paperwork ever gets here? > - document window-size-change-functions aren't called for mini-windo= w resizes =2E.. and maybe neither when the menu or tool bar wrap. Yes (if we decide to not change anything else). > - document window-configuration-change-hook isn't called for > mini-window resizes No (because we nowhere say that `window-configuration-change-hook' is called for resize operations). > - document set-window-configuration doesn't call > window-size-change-functions if nothing changed No (because IIRC we never document fixed bugs). > - fix set_window_configuration not to set the window size change fla= g > unless there was an actual size change Unless we decide to move that check to prepare_menu_bars as I sketched above. > - wishlist item: call pre-redisplay-function between > grow/shrink_mini_window and the actual X repaint, rather than before. Are you sure? If prepare_menu_bars is called before auto-resizing the minibuffer window, then =91window-size-change-functions=92 wouldn't catch= those auto-resizes either. > - mark window-size-change-functions as obsolete and see whether > anyone complains? This will happen if we don't provide a good subsitute. > + if (w->pixel_left !=3D XFASTINT (p->pixel_left) || > + w->pixel_top !=3D XFASTINT (p->pixel_top) || > + w->pixel_width !=3D XFASTINT (p->pixel_width) || > + w->pixel_height !=3D XFASTINT (p->pixel_height)) You still didn't explain why you find it necessary to compare the pixel_left and pixel_top values. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 11:31:38 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 15:31:38 +0000 Received: from localhost ([127.0.0.1]:38930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUcfq-0007Dk-7K for submit@debbugs.gnu.org; Wed, 26 Aug 2015 11:31:38 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:33124) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUcfm-0007DZ-QU for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 11:31:36 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NTP00H0046LYJ00@a-mtaout21.012.net.il> for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 18:29:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTP00HNC4D4VS70@a-mtaout21.012.net.il>; Wed, 26 Aug 2015 18:29:29 +0300 (IDT) Date: Wed, 26 Aug 2015 18:29:28 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DD662A.8080201@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83si765aqv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 26 Aug 2015 09:09:30 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org > > > You are our window-management czar: > > A carpenter, at best. I see no contradiction here. > > No, by arranging the buffer contents and letting redisplay do its > > job. Problems of this kind happen only when a mode changes buffer > > contents and related data structures (such as properties and overlays) > > in response to redisplay, something that is bad idea to begin with, > > because at the very least it immediately triggers another redisplay > > cycle, and kills many redisplay optimizations. > > ‘follow-mode’, to stick to one of the examples I cited earlier, uses > neither properties nor overlays. It must, however, know the exact > ‘window-end’ position of any window that could be followed by another. > This also means that a correct implementation of ‘follow-mode’ should be > allowed to specify the order in which windows are redisplayed. So > ideally, redisplay would be able to process each window separately, tell > us its new start and end positions and allow modes to react properly. OK, but if you want to stick to this example, please explain how is mini-window resizing relevant to follow-mode, because I think it isn't. I think follow-mode should not care at all about this automatic resizing. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 11:32:20 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 15:32:20 +0000 Received: from localhost ([127.0.0.1]:38934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUcgV-0007F6-Ku for submit@debbugs.gnu.org; Wed, 26 Aug 2015 11:32:19 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:44893) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUcgS-0007Ew-QL for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 11:32:17 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NTP009004BXLU00@mtaout29.012.net.il> for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 18:32:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTP0048C4I1CB60@mtaout29.012.net.il>; Wed, 26 Aug 2015 18:32:25 +0300 (IDT) Date: Wed, 26 Aug 2015 18:32:14 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DD663C.4040504@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83pp2a5am9.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 26 Aug 2015 09:09:48 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org > > > And we get regular complaints about that as well. Moreover, the > > setting of the modified status by fill-paragraph is just an annoyance > > that doesn't cost anyone any extra complexity, whereas the situation > > with this and similar hooks costs us quite a lot in that aspect. > > But you don't worry about performance anyway. I said "complexity". A hook function for a hook that calls you indiscriminately can be very cheap performance-wise, but its complexity could be overwhelming, and the result could easily be fragile. > OTOH for the person who writes the function on the hook it might > hardly matter whether some window size really changed. The more > important case might be to not miss one single case where the size > really changes. Inaccurate hooks make this task very hard and prone to breakage with each new release. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 11:36:31 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 15:36:31 +0000 Received: from localhost ([127.0.0.1]:38942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUckY-0007LU-Us for submit@debbugs.gnu.org; Wed, 26 Aug 2015 11:36:31 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:53645) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUckW-0007LF-Ld for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 11:36:29 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NTP00L0049PT700@mtaout25.012.net.il> for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 18:32:59 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTP00MTR4IZ6300@mtaout25.012.net.il>; Wed, 26 Aug 2015 18:32:59 +0300 (IDT) Date: Wed, 26 Aug 2015 18:36:26 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83mvxe5af9.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 26 Aug 2015 10:07:28 +0000 > From: Pip Cet > Cc: Eli Zaretskii , 21333@debbugs.gnu.org > > >> So an alternative that doesn't need any hook is > >> simply to recompute the coordinates every time they are needed. It's > >> not like this calculation is expensive, is it? > > > > Correct. > > I disagree, if I understand correctly. The coordinates might be passed > to another program, for example, and then we simply don't know when > that program decides to use them, so we still need a way to update our > (and its) idea of what the window size and position is, in my opinion. If we don't know enough about that imaginary program, how do we know it is interested in ephemeral resizes such as the one being discussed? More generally, it is impossible to reason about a theoretical use case whose details are not revealed, while you alone keep the right to introduce additional traits that help you make your point, without describing the whole picture. A problem should be solved top-down, by starting with an overall description. It cannot be solved bottom up, one detail at a time. > > So ‘window-size-change-functions’ is dispensable. > > Iff we keep/fix pre-redisplay-function, I agree. There are no plans to retire it any time soon. Quite the contrary, I'd say. > > OTOH for the person who > > writes the function on the hook it might hardly matter whether some > > window size really changed. The more important case might be to not > > miss one single case where the size really changes. > > Precisely. There are simpler ways not to miss those events, using much simpler hooks. Like post-command-hook, for example. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 26 12:00:22 2015 Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 16:00:22 +0000 Received: from localhost ([127.0.0.1]:38968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUd7c-0007wd-SR for submit@debbugs.gnu.org; Wed, 26 Aug 2015 12:00:22 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:36952) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUd7Z-0007wT-Ny for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 12:00:19 -0400 Received: by igui7 with SMTP id i7so15304834igu.0 for <21333@debbugs.gnu.org>; Wed, 26 Aug 2015 09:00:17 -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=EIyuvhF0Yn/Hg+tKw7U7i8IkKHL16A2aqWKYWt92JhU=; b=rNuMEp5c+F6lIo6P3aaG1L+Szs3MvkhHCvYNBajpmJzTv8KaRG25jGQXx2KrY/rNGT r0i9uZBBstkVgczxWNeEzVybQ4u8M3Ml8hkIqqNgYuS5q1e4mNCxLjrdwskgVhtpneNL ltiTTQHVW0tFSTvUWYOyyK54xm56ZAjcDyXzIX5fv5tFpuQf5DLfi0lDcehV7Ywaa0/W cQM/JStuZnJb2vbBJdSPf4/9GNvhttLjKecFrC9hRxiG52XywvMTnnldBSFMEcV/8dnp NG1voWxO/eEmFuM3aSRZ6rjEKxCHaCpqSvhuIfgzIAdK9aP0xlxl3YXwjl6LlXB0bGU4 W94Q== MIME-Version: 1.0 X-Received: by 10.50.28.70 with SMTP id z6mr11330132igg.61.1440604816889; Wed, 26 Aug 2015 09:00:16 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Wed, 26 Aug 2015 09:00:16 -0700 (PDT) In-Reply-To: <55DDB8A2.8020606@gmx.at> 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> Date: Wed, 26 Aug 2015 16:00:16 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: martin rudalics Content-Type: multipart/alternative; boundary=089e0158b2ce5f5dd0051e38f243 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0158b2ce5f5dd0051e38f243 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2015 at 1:01 PM, martin rudalics wrote: >>>> So an alternative that doesn't need any hook is >>>> simply to recompute the coordinates every time they are needed. It's >>>> not like this calculation is expensive, is it? >>> >>> Correct. >> >> I disagree, if I understand correctly. > > My "correct" referred to Eli's "It's not like this calculation is > expensive, is it?". I suppose we all agree on that. We do. >> The coordinates might be passed >> to another program, for example, and then we simply don't know when >> that program decides to use them, so we still need a way to update our >> (and its) idea of what the window size and position is, in my opinion. > > I don't understand you here. IIUC Eli means that any application can > store the old coordinates somewhere and easily compare them to the > current ones in order to detect whether window sizes have changed. I understood Eli differently. If I'm not misquoting him, his suggestion was to "simply recompute the coordinates every time they are needed". My objection to that is that in many applications, you don't know when the coordinates will be needed without changing other programs. > Even simpler: We could store the sizes in the window structure. This > way prepare_menu_bars would simply walk the window tree of each frame to > detect whether the size of any window has changed, call the functions on > =E2=80=98window-size-change-functions=E2=80=99 and afterwards (better whe= n redisplay > completed) store the current size values into the old ones. Would (window-size) return the old or the new size values? > The > functions on the hook, OTOH, could check for each window individually > whether and how its size changed. The advantage of this approach is > that we never accumulate any fake size changes. Agreed. >>> So =E2=80=98window-size-change-functions=E2=80=99 is dispensable. >> >> Iff we keep/fix pre-redisplay-function, I agree. I had, wrongly, >> assumed that pre-redisplay-function is run many times per redisplay >> call, but that appears to be incorrect. The huge majority of >> redisplays call it just once, and that makes the overhead negligible. > > We can declare =E2=80=98window-size-change-functions=E2=80=99 obsolete an= d suggest to > use =E2=80=98pre-redisplay-function=E2=80=99 instead. Still we'd have to= support it for > quite some time. Is there consensus for keeping pre-redisplay-function? >> So what's the way forward, assuming my paperwork ever gets here? >> - document window-size-change-functions aren't called for mini-window >> resizes > > ... and maybe neither when the menu or tool bar wrap. > > Yes (if we decide to not change anything else). > >> - document window-configuration-change-hook isn't called for >> mini-window resizes > > No (because we nowhere say that `window-configuration-change-hook' is > called for resize operations). windows.texi: @defvar window-configuration-change-hook A normal hook that is run every time you change the window configuration of an existing frame. This includes splitting or deleting windows, *changing the sizes of windows*, or displaying a different buffer in a window. I think it's at least possible to read that as applying to window resize operations. >> - document set-window-configuration doesn't call >> window-size-change-functions if nothing changed > > No (because IIRC we never document fixed bugs). Are you sure? It occurs to me I should have said "remove the bit in the documentation that says window-size-change-functions is always called by set-window-configuration". It's not about documenting the bugfix, but undocumenting the old bug. >> - fix set_window_configuration not to set the window size change flag >> unless there was an actual size change > > Unless we decide to move that check to prepare_menu_bars as I sketched > above. And get rid of the window size change flag entirely. That's a good idea. >> - wishlist item: call pre-redisplay-function between >> grow/shrink_mini_window and the actual X repaint, rather than before. > > Are you sure? If prepare_menu_bars is called before auto-resizing the > minibuffer window, then =E2=80=98window-size-change-functions=E2=80=99 wo= uldn'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. Should that be impossible? As far as I can tell, the documentation reads like it should be possible. At least some people make use of it, if in ways you probably think useless. I consider the documentation to be more authoritative than current behavior: if a feature should work according to the documentation, but doesn't, I think the right thing to do is almost always to fix the feature and then, afterwards, discuss whether it should be removed. >> - mark window-size-change-functions as obsolete and see whether >> anyone complains? > > This will happen if we don't provide a good subsitute. Wait, don't you mean that will happen if we do provide a good substitute? >> + if (w->pixel_left !=3D XFASTINT (p->pixel_left) || >> + w->pixel_top !=3D XFASTINT (p->pixel_top) || >> + w->pixel_width !=3D XFASTINT (p->pixel_width) || >> + w->pixel_height !=3D XFASTINT (p->pixel_height)) > > You still didn't explain why you find it necessary to compare the > pixel_left and pixel_top values. (Sorry, I missed that email initially! And thanks for pointing out my coding style typo, I'll try to be more careful in future.) I no longer do so. I think pre-redisplay-function, but not window-size-change-functions, should be told about a change in those values, so let's remove those checks. Reasons for calling pre-redisplay-function in these cases: Mouseover, if you need more than text properties give you. Cursor warping. X hacks. It's what the previous code did, so I didn't dare change it. One thing it occurs to me might be useful is an option to warp the mouse cursor when the echo area is resized, so you don't end up clicking the wrong link when the resize happens precisely at the wrong moment. An option I could live with, though it's not my preference, is to add a hook especially for mini-window resizes. Thank you again for spending so much time on this, Pip --089e0158b2ce5f5dd0051e38f243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 26, 2015 at 1:01 PM, martin rudalics <= rudalics@gmx.at>= ; wrote:
>>>> So an alternative that doesn't need any ho= ok is
>>>> simply to recompute the coordinates every time th= ey are needed.=C2=A0 It's
>>>> not like this calculation= is expensive, is it?
>>>
>>> Correct.
>><= br>>> I disagree, if I understand correctly.
>
> My "= ;correct" referred to Eli's "It's not like this calculati= on is
> expensive, is it?".=C2=A0 I suppose we all agree on that= .

We do.

>> The coordinates might be passed
>>= to another program, for example, and then we simply don't know when>> that program decides to use them, so we still need a way to updat= e our
>> (and its) idea of what the window size and position is, i= n my opinion.
>
> I don't understand you here.=C2=A0 IIUC E= li means that any application can
> store the old coordinates somewhe= re and easily compare them to the
> current ones in order to detect w= hether window sizes have changed.

I understood Eli differently. If I= 'm not misquoting him, his suggestion was to "simply recompute the= coordinates every time they are needed". My objection to that is that= in many applications, you don't know when the coordinates will be need= ed without changing other programs.

> Even simpler: We could stor= e the sizes in the window structure.=C2=A0 This
> way prepare_menu_ba= rs would simply walk the window tree of each frame to
> detect whethe= r the size of any window has changed, call the functions on
> =E2=80= =98window-size-change-functions=E2=80=99 and afterwards (better when redisp= lay
> completed) store the current size values into the old ones.
=
Would (window-size) return the old or the new size values?

> = =C2=A0The
> functions on the hook, OTOH, could check for each window = individually
> whether and how its size changed.=C2=A0 The advantage = of this approach is
> that we never accumulate any fake size changes.=

Agreed.

>>> So =E2=80=98window-size-change-function= s=E2=80=99 is dispensable.
>>
>> Iff we keep/fix pre-redi= splay-function, I agree. I had, wrongly,
>> assumed that pre-redis= play-function is run many times per redisplay
>> call, but that ap= pears to be incorrect. The huge majority of
>> redisplays call it = just once, and that makes the overhead negligible.
>
> We can d= eclare =E2=80=98window-size-change-functions=E2=80=99 obsolete and suggest = to
> use =E2=80=98pre-redisplay-function=E2=80=99 instead.=C2=A0 Stil= l we'd have to support it for
> quite some time.

Is there consensus for keeping pre-redisplay-function?

= >> So what's the way forward, assuming my paperwork ever gets her= e?
>> =C2=A0 - document window-size-change-functions aren't ca= lled for mini-window
>> resizes
>
> ... and maybe neit= her when the menu or tool bar wrap.
>
> Yes (if we decide to no= t change anything else).
>
>> =C2=A0 - document window-confi= guration-change-hook isn't called for
>> mini-window resizes>
> No (because we nowhere say that `window-configuration-change= -hook' is
> called for resize operations).

windows.texi:@defvar window-configuration-change-hook
A normal hook that is r= un every time you change the window configuration
of an existing frame.= =C2=A0 This includes splitting or deleting windows,
*changing the sizes = of windows*, or displaying a different buffer in a
window.

I think it's at least possible to read = that as applying to window resize operations.

>> =C2=A0 -= document set-window-configuration doesn't call
>> window-size= -change-functions if nothing changed
>
> No (because IIRC we ne= ver document fixed bugs).

Are you sure? It occurs to me I= should have said "remove the bit in the documentation that says windo= w-size-change-functions is always called by set-window-configuration".= It's not about documenting the bugfix, but undocumenting the old bug.<= br>

>> =C2=A0 - fix set_window_configuration not to set= the window size change flag
>> unless there was an actual size ch= ange
>
> Unless we decide to move that check to prepare_menu_ba= rs as I sketched
> above.

And get rid of the window= size change flag entirely. That's a good idea.

>&= gt; =C2=A0 - wishlist item: call pre-redisplay-function between
>>= grow/shrink_mini_window and the actual X repaint, rather than before.
&= gt;
> Are you sure?=C2=A0 If prepare_menu_bars is called before auto-= resizing the
> minibuffer window, then =E2=80=98window-size-change-fu= nctions=E2=80=99 wouldn't catch
> those auto-resizes either.
<= br>
That's why I consider it "wishlist". My Christmas wi= sh 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.
Should that be impossible? As far as I can tell, the documentat= ion reads like it should be possible. At least some people make use of it, = if in ways you probably think useless.

I consider the doc= umentation to be more authoritative than current behavior: if a feature sho= uld work according to the documentation, but doesn't, I think the right= thing to do is almost always to fix the feature and then, afterwards, disc= uss whether it should be removed.

>> =C2=A0 - mark = window-size-change-functions as obsolete and see whether
>> anyone= complains?
>
> This will happen if we don't provide a good= subsitute.

Wait, don't you mean that will happen if = we do provide a good substitute?

>> + =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0if (w->pixel_left !=3D XFASTINT (p->pixel= _left) ||
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0w->pixel_top !=3D XFASTINT (p->pixel_top) ||
>> + =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0w->pixel_width !=3D = XFASTINT (p->pixel_width) ||
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0w->pixel_height !=3D XFASTINT (p->pixel_he= ight))
>
> You still didn't explain why you find it necessa= ry to compare the
> pixel_left and pixel_top values.
(Sorry, I missed that email initially! And thanks for pointing= out my coding style typo, I'll try to be more careful in future.)
<= /div>

I no longer do so. I think pre-redisplay-function,= but not window-size-change-functions, should be told about a change in tho= se values, so let's remove those checks.

Reasons for = calling pre-redisplay-function in these cases: Mouseover, if you need more = than text properties give you. Cursor warping. X hacks. It's what the p= revious code did, so I didn't dare change it.

One thi= ng it occurs to me might be useful is an option to warp the mouse cursor wh= en the echo area is resized, so you don't end up clicking the wrong lin= k when the resize happens precisely at the wrong moment.

= An option I could live with, though it's not my preference, is to add a= hook especially for mini-window resizes.

Than= k you again for spending so much time on this,
Pip
<= /div> --089e0158b2ce5f5dd0051e38f243-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 03:57:26 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 07:57:26 +0000 Received: from localhost ([127.0.0.1]:39607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs3q-000385-Dc for submit@debbugs.gnu.org; Thu, 27 Aug 2015 03:57:26 -0400 Received: from mout.gmx.net ([212.227.17.22]:63425) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs3o-00037w-NT for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 03:57:25 -0400 Received: from [62.46.213.30] ([62.46.213.30]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MVZuV-1ZE5j30iBb-00Z0DF; Thu, 27 Aug 2015 09:57:22 +0200 Message-ID: <55DEC2DB.9080800@gmx.at> Date: Thu, 27 Aug 2015 09:57:15 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> In-Reply-To: <83si765aqv.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:N7pdop7NBiIGbKyK9/Oomdb9auNPSk0Vsr94nioelSSUDh70IMM +Klx+mRnJCqwl3ZTb5CXVWo5RbT0std3C0/riYXMoZcEZ52mCYIIxuQz5yeaDzUGTvngzlY J15sYJex6dxXhZsS6Fgs56220w/vb3ED57gBqos0DOaKz3PsHYbDYOJ/eqp9/8cO316pAQv g8ZdzZub7DSOQUOu8VOtw== X-UI-Out-Filterresults: notjunk:1;V01:K0:cY6AiUfMtTY=:4qwkkQhsVXQaekE4PL9t45 i3KgJ3BMhzbaMjJ886gK+CIzsgEU8/slhNztDjOQX/SsUQ+aBKU1rcX282+Q4Td3e5qAXClRp gCn8zou1sWFqJHDbgF6XhvP6W81FD9hhf3Pz57fN740AynytC5G8aGhPy5ejcEOXZHrX4obyW Es5ldLcdfKgTVGIFDzCV0Nozzq8zJ8rqYAXqBAbmcaGmhWQtJJNv9MQiGbYO5f3GVUoMpwSBt gAHWbBKn0Gs2DjLTrno1xqRShDpCC0Rq21UvYCu7jw6VJ4hN4SM7YiQKUrjm0faHvITlIWhSl 2rXGnaIXoi0jNa0p09YeR2xkWwx+2aEOf99dDjPn07ayLxXQHQ0EWZXafuj8wmJqvTylGfxAP ogs79uMzLk0pcY16C5NFboM0oVjWg/+YJwdhiOUGQ9YGSx9V4jmSTLYad++9T4WEOfEzqbuRC ovOEsOjkwTM9a+ScRIURRJKmkItxjSiE6GULycNQYB56z7LDcqJiNrLLjJus9dLN2MoPkeldV oVeRGZtUcQHz7cQqNnFTfjP/2GCn386mV1DdnGrKqGWQM3hkIy+PbZVBQt6iKzxml2pzP35hE oKH08Vwvp2op/P/I/T60KPSZ6gTROY0DCaPYHBcxnRlvoYuwaNqd7zFDJuObMhxzhe7j3skwX pcEd9rx49UYih2vz5g9i9E0VSXO2Md9qHgT7fTi4UWz3YqyChIlFcqnQeeAyhoB/e24Tu8RZX CeVt+S3Yklkg+TZ0ujVk1noqZbSiyl8f8J5VgA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > OK, but if you want to stick to this example, please explain how is > mini-window resizing relevant to follow-mode, because I think it > isn't. I think follow-mode should not care at all about this > automatic resizing. `follow-mode' has to synchronize the =E2=80=98window-end=E2=80=99 of one = window with the =E2=80=98window-start=E2=80=99 of another. Since mini-window resizing ca= n persistently change the end position of the first of these windows, =E2=80=98follow-mo= de=E2=80=99 eventually has to react even if might dismiss the temporary effect that the enlarged mini-window obscures the bottom of the first window. OT1H we do care about point being visible when its window is partially obscured by the mini-window and deliberately scroll the window in that case. OTOH we'd say that `follow-mode' should not care about keeping its text coherent in that case. Is that fair? martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 03:57:50 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 07:57:50 +0000 Received: from localhost ([127.0.0.1]:39610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs4D-00038e-OP for submit@debbugs.gnu.org; Thu, 27 Aug 2015 03:57:49 -0400 Received: from mout.gmx.net ([212.227.17.21]:52538) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs4C-00038X-Ba for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 03:57:48 -0400 Received: from [62.46.213.30] ([62.46.213.30]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MRocn-1ZK7bH24pF-00Sy4w; Thu, 27 Aug 2015 09:57:46 +0200 Message-ID: <55DEC2F4.80308@gmx.at> Date: Thu, 27 Aug 2015 09:57:40 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83pp2a5am9.fsf@gnu.org> In-Reply-To: <83pp2a5am9.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lTOo8fMwzZhrotOjzVW/oLcCRqlw5jn0LjTcpDb0K6a559dFrgS Q73Qcjs82NnL07u3CQzGtSbBXJF5HhAfVzhBKuyEGykTItBj7jUVqiJGhNX5V0cyJMRkwtm usrmH6tymmzkKPVylPy2TI1UmDXTCu5D164BKA64+tQYmlz6OjZ5e55Rrc7Ju6zQP4sIYCd WCWKib1NiOUjFj9Nnk7yA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ITi9bpfH1Q8=:tmy8Y+0skVwR6TF9OkT+8Q PcCJeZ7psPC+mku6PfyymrfEqw5DX5/A49HrFtfpXnPqtbwKC0lK/FhlknGNNe9JFvHubHREL t8HeqKN18MBokSXyxARer9/P6iC2NtaGZTk3PsyYLz65y82y7V3E0j9ASIvmAThUSDBh448M0 6lMK9b59fWjHMxzX1HTDE8daU3fE/p9DQgyjpuMKZSeG28zAjTsjQUjx9GJ5md2ZqXV1FUW8+ NCjoblzUNGEKI0ymIMVAu7ngiiiq/aDl6xqtZAXDThBi8e8ICoCQ0C147uJEah7XaKJtapn8Y q8Blus6lBMa1gXq3BaU8apTzdvGL0yKz18L3GjBnLhbzfXsS4jQLTpytjH7gIsMDcPOBtQpqh XIxjNY9svwGM0vFUueKOfxMmv1YduxyjnR1DGPWNBlgHxoh3pXrocBpzEv6rre25FZa0azBNz HheRQVfSGcyuC5Ze6+Gyi0KaHft+YGzX4VwB6LhktBoPAC7MQvDo4hKk3JJfQ9HmVZfM7MzO2 lU+wyYmLJjkYZcEvtAz+pTIH4oYsOpbDXAsBRI3k/psMOU7b7R714lXP68Q+FVPXn+poFyI1v GZdMoN7vdVz3fU17mDAysHhCxa9AUCko8DTB32RpDOQZD3VGTH+LHptfkA47mWEAInQExyJAV pQaJ98QheD3+K6jWZoRHSKFSIAmjtJfq+RI3d+plSE0bBulgYhwsHqDnjT+vmjCOriLUa0Kbx Fos0hMx6yioQer10PV0vdDeELQH7e5OtbyVVxw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I said "complexity". A hook function for a hook that calls you > indiscriminately can be very cheap performance-wise, but its > complexity could be overwhelming, and the result could easily be > fragile. ... > Inaccurate hooks make this task very hard and prone to breakage with > each new release. We agree. And we are currently trying to become more discriminative. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 03:58:17 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 07:58:18 +0000 Received: from localhost ([127.0.0.1]:39618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs4f-0003A2-En for submit@debbugs.gnu.org; Thu, 27 Aug 2015 03:58:17 -0400 Received: from mout.gmx.net ([212.227.17.21]:63070) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs4d-00039v-JQ for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 03:58:15 -0400 Received: from [62.46.213.30] ([62.46.213.30]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LvlWS-1Yf28v1vbg-017WIb; Thu, 27 Aug 2015 09:58:13 +0200 Message-ID: <55DEC310.5050408@gmx.at> Date: Thu, 27 Aug 2015 09:58:08 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> In-Reply-To: <83mvxe5af9.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fI3XtXHOAsYf9Tmo4T1yTlA/TSZOfCwR+js/3g5OM55km1xnjY+ WV/ABk3eHDPqBKg2OABdbzYnK6dX+HNmxSrH4EubYuvW5JoLKyIHWftOUlcO8Zwuj2Udo1a rhjlMk4nPVACnsbD1Q2M1tkByYxNMhupRA725tWc3rCEiwNSrHTbvUhd/iAYKA8aozQGT1U u7ZBAIZuv8RjnzBfXzGyw== X-UI-Out-Filterresults: notjunk:1;V01:K0:A7lOYgOODgQ=:6Z53KNS6Pd65KwjnHYtdl6 eL8KKAdXoNIp2Y9fur5133deBrk9yzFbQdgLgQ9q6mwXi3QMtcHwxz3tX/O8LJACnPSgaW2dw JUi81b+aU8E0GunNc/ENIeXpwfIvNUe397RdEzFbos+tJYXNXLXkLbm8XFYXADOjU7chfuJQT bveo01ARHf+2aMA5Ou5ZWwXk1WNxBmRWOjOim2TmoIV5TBvvTKzrab3799/Igm9sHTRtmPyIk jqDDCFGZcPbwXDMt+OLrsTxqleQBCVbcCMAqsFkNLrJfzh6kqmopAFdl5U9qZLaterPN+sXAn HzQncx1yqZPjSyocEsxg2y6EQefppn2dhTHY15kDqBst3Javu1qLYBMc7JCfOf3Wmi0LhtiKC mN3yzmjn0ozGi6oJX69qUtQqWufUvI1iOk9OIQ4toIgMzQ+GLb4mxdsZTr04YvXF0vRE8ZmSa 37ujDyciv/aSqfdA2e2/wEUb/kPWx+4wMWnJzjRlnPcmpCnXw0ZCqzQL3AkzZzy/S3rG6khLu RE7KU+lvXWfFuUHK2VGR176DhgI7a3qyeLHWp9XMqhQ45sfn8sLoywM2tWtRrbpbii0ta8JhP b+CBvtfEuhIPd0Q7f0KJtjtzEWKxKeoHhpQpdhgnvA9F2IrxhzFZSwtDT80jqnNmZ87oDc8Mo J+wNAqu8nHhix2+Z7IymuKY7sjsJRSQDpkV9yxw0XHqpzFS5qKk6b6CEPOVVJ7Mgl851diLzE bFl4SBntOl3paXo+minv1uiGdjtw3e+nNDoqDQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > There are simpler ways not to miss those events, using much simpler > hooks. Like post-command-hook, for example. A window's size might also change when input arrives. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 03:59:15 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 07:59:15 +0000 Received: from localhost ([127.0.0.1]:39623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs5a-0003Bn-Vz for submit@debbugs.gnu.org; Thu, 27 Aug 2015 03:59:15 -0400 Received: from mout.gmx.net ([212.227.17.21]:51252) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs5Y-0003Bf-Jy for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 03:59:13 -0400 Received: from [62.46.213.30] ([62.46.213.30]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MHso5-1ZRrHP1fYr-003dPn; Thu, 27 Aug 2015 09:59:10 +0200 Message-ID: <55DEC348.8080306@gmx.at> Date: Thu, 27 Aug 2015 09:59:04 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:UNIYLgL7u/wRgrTZy+oO/9JCXELJbyrRAz3GGo0xTODD3g6cwrW L9c/VPun6wqfDPBkKoHfZ0n22Ny8mix9uGF6k9aLYrdehxW2XrcELRRCYec3lfQvtQTXywV kAII+pXOiUyKhEwIFbyE5nsNpo/VgriNeL175umkif8uq0XgspfGM2NW3Gvuq9dAZXOXc0i 0u/ffAUB8TXUuEDnGRRUw== X-UI-Out-Filterresults: notjunk:1;V01:K0:tAhelhIorxI=:mXXAI6QyokOeFAM1deS16x KtyBCvoXo55uHCCLUVOfLUqh2pMP2iD9fR2y8fo7NZNjgAhbbeirnruERpo/sLiT8t+NmJfuG APlaUeH6DU4YY9xmzRdawwvtFzxVVqHyz3NyUHEc4aRrPNkQiM00DiwawVEctBnR+w5bwUsKY mL3Ak3RCJh0srvsA4Luk+2P0gNJZif/cpUqfyKrP7ail02xyav/5hkUJdcNWVCZTKM4yDoHb2 aL0tJ2EBa8KPG5yZ7usiAno/SMqCjpNxAsDlsdvRLbnD4LXIxXCk5VTYrOO4Qvd5xMkgoF4+h 5bvt+MK0KeIqtEpP0LdTRAnjMPlAmP8uzD9L/m3rsYhRa+OykOl3NWFzld1t9Rl66x+IwyDau 2cuuEG0RfETI1z2ZExRqQDwKRKpUOG5RuX1UFPsWwqpqNOsegP+LwUJvAKL4Ag1Rp+vqSdehH cWs9HiNBfka3L654DgYqGKmfA6bBZTxzXJuzS3g+Ezu4EV/XODEbXK+AQD+OSfn4oTxfgaOnR OhyT7CqejwPmyExXaHfX78AQDcvIOnYRNTD/biU2ZVlgS751Ih9eVwfAW1fDgLLeKh7ucaNoW fRhl4OFoEgwvApH3zWUsi57jYIFhm7DmAB5BkcSXnZ6Vq8AdOnlIpHOxjEw3VxGLqWJfXyzbz wK75pSz1aoFF6fhwnjbr3V/sDstBkxUIxONqsg26Jx3+d862VGdwhWAm/Rm8eYHVjCPbzAYYC lsOrzFNBaOk3HI9ACORAV6MxzW2kyXXGsKLe+g== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I understood Eli differently. If I'm not misquoting him, his suggestio= n was > to "simply recompute the coordinates every time they are needed". My > objection to that is that in many applications, you don't know when th= e > coordinates will be needed without changing other programs. There's no need to ever recompute coordinates. They are here all the time. What's needed is to record previous coordinates and to compare them with the actual ones. >> Even simpler: We could store the sizes in the window structure. This= >> way prepare_menu_bars would simply walk the window tree of each frame= to >> detect whether the size of any window has changed, call the functions= on >> =E2=80=98window-size-change-functions=E2=80=99 and afterwards (better= when redisplay >> completed) store the current size values into the old ones. > > Would (window-size) return the old or the new size values? All existing functions (like =E2=80=98window-size=E2=80=99) would obvious= ly remain unchanged. We would provide a new function, say =E2=80=98window-old-size= =E2=80=99, to return the width or height of a window at the time the last redisplay finished. > Is there consensus for keeping pre-redisplay-function? Sure. It's been only added in 2013. > windows.texi: > @defvar window-configuration-change-hook > A normal hook that is run every time you change the window configurati= on > of an existing frame. This includes splitting or deleting windows, > *changing the sizes of windows*, or displaying a different buffer in a= > window. Damn. > I think it's at least possible to read that as applying to window resi= ze > operations. At least. >>> - document set-window-configuration doesn't call >>> window-size-change-functions if nothing changed >> >> No (because IIRC we never document fixed bugs). > > Are you sure? It occurs to me I should have said "remove the bit in th= e > documentation that says window-size-change-functions is always called = by > set-window-configuration". It's not about documenting the bugfix, but > undocumenting the old bug. You're right again. I suppose that what we wanted to say there is that we always call =E2=80=98window-configuration-change-hook=E2=80=99. >>> - wishlist item: call pre-redisplay-function between >>> grow/shrink_mini_window and the actual X repaint, rather than before= =2E >> >> Are you sure? If prepare_menu_bars is called before auto-resizing th= e >> 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-functio= n=E2=80=99 is called in the wrong place? Where else would you call it? > Should that be impossible? As far as I can tell, the documentation rea= ds > like it should be possible. At least some people make use of it, if in= ways > you probably think useless. > > I consider the documentation to be more authoritative than current > behavior: if a feature should work according to the documentation, but= > doesn't, I think the right thing to do is almost always to fix the fea= ture > and then, afterwards, discuss whether it should be removed. If we can fix the feature, yes. >>> - mark window-size-change-functions as obsolete and see whether >>> anyone complains? >> >> This will happen if we don't provide a good subsitute. > > Wait, don't you mean that will happen if we do provide a good substitu= te? If =E2=80=98pre-redisplay-function=E2=80=99 can do the job it's a good su= bstitute. >>> + if (w->pixel_left !=3D XFASTINT (p->pixel_left) || >>> + w->pixel_top !=3D XFASTINT (p->pixel_top) || >>> + w->pixel_width !=3D XFASTINT (p->pixel_width) || >>> + w->pixel_height !=3D XFASTINT (p->pixel_height)) >> >> You still didn't explain why you find it necessary to compare the >> pixel_left and pixel_top values. =2E.. > Reasons for calling pre-redisplay-function in these cases: Mouseover, = if > you need more than text properties give you. Cursor warping. X hacks. = It's > what the previous code did, so I didn't dare change it. But this would imply that we also had to care about the case where a window's body width or height changes. Discriminating that is pretty difficult since we don't store that in a window configuration. And even the body width remains unchanged when I move a window's scroll bar from the left to the right. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 11:24:18 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 15:24:19 +0000 Received: from localhost ([127.0.0.1]:40427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUz2H-0000JB-Rv for submit@debbugs.gnu.org; Thu, 27 Aug 2015 11:24:18 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:51078) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUz2E-0000J1-8V for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 11:24:15 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTQ00H00YJSCQ00@mtaout28.012.net.il> for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 18:24:05 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTQ00DJJYS57N40@mtaout28.012.net.il>; Thu, 27 Aug 2015 18:24:05 +0300 (IDT) Date: Thu, 27 Aug 2015 18:24:14 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DEC310.5050408@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83d1y869gh.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 27 Aug 2015 09:58:08 +0200 > From: martin rudalics > CC: 21333@debbugs.gnu.org > > > There are simpler ways not to miss those events, using much simpler > > hooks. Like post-command-hook, for example. > > A window's size might also change when input arrives. In what way? I thought it can only change as part of redisplay, which always happens after some command finishes. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 11:25:40 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 15:25:41 +0000 Received: from localhost ([127.0.0.1]:40431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUz3b-0000LN-8x for submit@debbugs.gnu.org; Thu, 27 Aug 2015 11:25:40 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:41107) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUz3X-0000LD-CV for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 11:25:36 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NTQ00400YP88P00@a-mtaout20.012.net.il> for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 18:25:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTQ003PCYULX890@a-mtaout20.012.net.il>; Thu, 27 Aug 2015 18:25:34 +0300 (IDT) Date: Thu, 27 Aug 2015 18:25:35 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DEC348.8080306@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83bnds69e8.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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 before. > >> > >> Are you sure? If prepare_menu_bars is called before auto-resizing the > >> minibuffer window, then ‘window-size-change-functions’ 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 ‘pre-redisplay-function’ 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. When that next cycle comes, it will first call pre-redisplay-function and window-size-change-functions, from prepare_menu_bars, and then, after the rest of redisplay finishes, actually perform the X repaint, by calling update_frame. So it sounds like the wish has been granted already, no? 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. If that's not what is being wished, please tell more about the issue. Likewise if I'm missing something here. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 11:29:31 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 15:29:31 +0000 Received: from localhost ([127.0.0.1]:40436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUz7K-0000RJ-Vh for submit@debbugs.gnu.org; Thu, 27 Aug 2015 11:29:31 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:43171) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUz7H-0000R8-RB for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 11:29:28 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NTQ00M00YHVK700@a-mtaout22.012.net.il> for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 18:29:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTQ00MXPZ0MBK50@a-mtaout22.012.net.il>; Thu, 27 Aug 2015 18:29:10 +0300 (IDT) Date: Thu, 27 Aug 2015 18:29:11 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DEC2DB.9080800@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83a8tc6988.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 27 Aug 2015 09:57:15 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org > > > OK, but if you want to stick to this example, please explain how is > > mini-window resizing relevant to follow-mode, because I think it > > isn't. I think follow-mode should not care at all about this > > automatic resizing. > > `follow-mode' has to synchronize the ‘window-end’ of one window with the > ‘window-start’ of another. Not when one of them is temporarily obscured by a resized mini-window, IMO. > Since mini-window resizing can persistently > change the end position of the first of these windows Any command that clears the echo area will resize it back, AFAIK. So it's not persistent. > OT1H we do care about point being visible when its window is partially > obscured by the mini-window and deliberately scroll the window in that > case. OTOH we'd say that `follow-mode' should not care about keeping > its text coherent in that case. Is that fair? Yes. In that situation, the user most probably reads the mini-window text anyway, and if not, then she reads the text at point. The probability that she is reading the text that will be scrolled out of view as result of the mini-window resize is IMO minuscule. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 12:35:48 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 16:35:48 +0000 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 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 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== MIME-Version: 1.0 X-Received: by 10.50.120.9 with SMTP id ky9mr181269igb.61.1440693344749; Thu, 27 Aug 2015 09:35:44 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Thu, 27 Aug 2015 09:35:44 -0700 (PDT) In-Reply-To: <83bnds69e8.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> Date: Thu, 27 Aug 2015 16:35:44 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=047d7b874bbe0b4f76051e4d8f67 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: martin rudalics , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --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-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 13:05:42 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 17:05:42 +0000 Received: from localhost ([127.0.0.1]:40464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV0cQ-0002px-0S for submit@debbugs.gnu.org; Thu, 27 Aug 2015 13:05:42 -0400 Received: from mail-yk0-f169.google.com ([209.85.160.169]:36326) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV0cK-0002pl-Lc for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 13:05:37 -0400 Received: by ykfw73 with SMTP id w73so26782676ykf.3 for <21333@debbugs.gnu.org>; Thu, 27 Aug 2015 10:05:36 -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=3J2m1MOR49b4Cu+wrscdMAsKvLV910YL+0UKh656OSE=; b=LutNvQQ4HAj/CCkoAOwOfSRZqoUKiFM+Jd3ekM/Eo6tNf+xDDZH1oj0+6BKqF5JbVX n35kn0IaVWCLx1aZkBJXsmetPlwsMF6xs2cud4uz49V+7FL7e+X3xgOtAdmndKu0ptaO MKWapkyoCptKnKXORy+qquxY8s5w5TvDY03O2u/L1JMR1hsEy7sAF9xSrkbN0uol7My8 RqMU/NRia1DRstfDNgMU2ZPo5glbna5NetKE6NtA++Z2pQ++awiXq6NbjYac1iF+nn2K 4NK1CtfiLYDU2KhYsBeBzbCFcGR0mTkmQSsGLnZdHVaPBxkyZTiTWm6W5XArojuIkqfI aUUg== MIME-Version: 1.0 X-Received: by 10.13.220.131 with SMTP id f125mr2694640ywe.65.1440695135928; Thu, 27 Aug 2015 10:05:35 -0700 (PDT) Received: by 10.37.74.200 with HTTP; Thu, 27 Aug 2015 10:05:35 -0700 (PDT) In-Reply-To: <83a8tc6988.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> Date: Thu, 27 Aug 2015 17:05:35 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=94eb2c08095ece9ed3051e4df971 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: martin rudalics , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --94eb2c08095ece9ed3051e4df971 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 3:29 PM, Eli Zaretskii wrote: > > `follow-mode' has to synchronize the =E2=80=98window-end=E2=80=99 of on= e window with the > > =E2=80=98window-start=E2=80=99 of another. > > Not when one of them is temporarily obscured by a resized mini-window, > IMO. > I think that is indeed a matter of opinion (and should thus be subject to customization), but I don't think we should assume that recursive editing invocations or long message scenarios are always short-lived. > Since mini-window resizing can persistently > > change the end position of the first of these windows > > Any command that clears the echo area will resize it back, AFAIK. So > it's not persistent. > That's not what I'm seeing here. When I run: (progn (run-with-timer 2 nil (lambda () (message "hi"))) (run-with-timer 3 nil (lambda () (message ""))) (read-from-minibuffer (make-string 3000 ?*))) The minibuffer resizes once, when the read-from-minibuffer prompt makes it grow to its maximal size; it then stays at that size as the short message is being displayed, then restores the long minibuffer prompt without changing size again when the echo area is cleared. > > OT1H we do care about point being visible when its window is partially > > obscured by the mini-window and deliberately scroll the window in that > > case. OTOH we'd say that `follow-mode' should not care about keeping > > its text coherent in that case. Is that fair? > > Yes. In that situation, the user most probably reads the mini-window > text anyway, and if not, then she reads the text at point. The > probability that she is reading the text that will be scrolled out of > view as result of the mini-window resize is IMO minuscule. > So if, for whatever reason, I have a timer function that displays a two-line message once a second (so the echo area never goes back to its single-line state), my follow-mode buffer will be and remain in an inconsistent state until I manually resize a window, when it will go back to a consistent state, but then if I cancel the timer (and the mini-window shrinks) it'll be in an inconsistent state again, and the only way out of that one is another manual window resize? I think that last case is something we haven't considered yet: if I resize windows manually while the mini-window is enlarged, they will be in an inconsistent state when it goes back to normal, right? --94eb2c08095ece9ed3051e4df971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 3:29 PM, Eli Zaretskii <eliz@gnu.org>= wrote:
> `fo= llow-mode' has to synchronize the =E2=80=98window-end=E2=80=99 of one w= indow with the
> =E2=80=98window-start=E2=80=99 of another.

Not when one of them is temporarily obscured by a resized mini-windo= w,
IMO.

I think that is indeed a matter of= opinion (and should thus be subject to customization), but I don't thi= nk we should assume that recursive editing invocations or long message scen= arios are always short-lived.

> Since mini-window resizing can persistently
> change the end position of the first of these windows

Any command that clears the echo area will resize it back, AFAIK.=C2= =A0 So
it's not persistent.

That's not= what I'm seeing here. When I run:

(progn
=C2=A0 (run-with-ti= mer 2 nil (lambda () (message "hi")))
=C2=A0 (run-with-timer 3= nil (lambda () (message "")))
=C2=A0 (read-from-minibuffer (m= ake-string 3000 ?*)))

The minibuffer resizes once, when t= he read-from-minibuffer prompt makes it grow to its maximal size; it then s= tays at that size as the short message is being displayed, then restores th= e long minibuffer prompt without changing size again when the echo area is = cleared.
=C2=A0
> OT1H we do care about point being visible when its window is partially=
> obscured by the mini-window and deliberately scroll the window in that=
> case.=C2=A0 OTOH we'd say that `follow-mode' should not care a= bout keeping
> its text coherent in that case.=C2=A0 Is that fair?

Yes.=C2=A0 In that situation, the user most probably reads the mini-= window
text anyway, and if not, then she reads the text at point.=C2=A0 The
probability that she is reading the text that will be scrolled out of
view as result of the mini-window resize is IMO minuscule.

So if, for whatever= reason, I have a timer function that displays a two-line message once a se= cond (so the echo area never goes back to its single-line state), my follow= -mode buffer will be and remain in an inconsistent state until I manually r= esize a window, when it will go back to a consistent state, but then if I c= ancel the timer (and the mini-window shrinks) it'll be in an inconsiste= nt state again, and the only way out of that one is another manual window r= esize?

I think that last case is so= mething we haven't considered yet: if I resize windows manually while t= he mini-window is enlarged, they will be in an inconsistent state when it g= oes back to normal, right?
--94eb2c08095ece9ed3051e4df971-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 13:58:50 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 17:58:50 +0000 Received: from localhost ([127.0.0.1]:40506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1Rq-0005do-9J for submit@debbugs.gnu.org; Thu, 27 Aug 2015 13:58:50 -0400 Received: from mout.gmx.net ([212.227.15.19]:58444) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1Ro-0005dg-Lc for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 13:58:49 -0400 Received: from [62.46.211.251] ([62.46.211.251]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MF4eJ-1ZWRA60Nel-00GIkH; Thu, 27 Aug 2015 19:58:45 +0200 Message-ID: <55DF4FCD.9000104@gmx.at> Date: Thu, 27 Aug 2015 19:58:37 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> In-Reply-To: <83d1y869gh.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8rL99L3yr3d+FiqG0lo1wah5ZAKtJc0NR7dm3LZtBWmUBkmVNG3 Jy/AeWkm4bGfgbPXkS7k2ayNUH8D277CokOvaPWdsg/ajPejvJl2PFD35gpbLxRW33v+7DN IM9RbgahypvlB3MAhmk5x5Sxm9cZo3MNWXRRHTx4M0KreXV0D515NaeZs9EjkJrGUQWPI8V JK8TeqfL5BfwefZx3KaUQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:LZNOC6Ppn4M=:6fzUa4KGqG7b4Kd66Cflhb dKTK6iB6R5IGaYjkpgot/+8hQjYGLyjsU2L4SNpIuYv1tSVLoC39BO4NYTQnRJ8mCUths1k4e ARMO9CxDgFb6MgJDp5nOiG9iMZ7xctUvEGsGUX+POhUlqyhgIcPbT1j4LU+wHYRhj57fP6F/L x9+nID8TZwhGwcYUmDS9KLJF1lohtzOx1sSGtDzddnjuGP2EGsM9hNGNsLeBTYhF+diocgUq0 WhH71RWfPNVHVOY90Wdp3x2MmgjHIh7iLWIfvfrvXAf0+K3bRiWH05Kk5iqLnCNX/hHuILbqW qbeZhRkiujfakiSoc9l/LsZz4+buYrpAFO21o+uXmMeXcdbiIDFcWgVBmc6GgHA0T19POd5ef 3jKdaONMmSlmOXVfkLnaN2lE1vVRL9s5PzqoqebR9bZy2vHGdVRNZZoDuWQ+RViNLCquXZBTP FIaMvLrE97mhHUBooa0ir1GlqDVn3C7pRCByysyDCip99w83fJ3JRXSy0U8SAgMywcoqkzbqX x3XGIBUnXr7Rz0PrLbgvg1/GoER+AbT1DuoeKxWVBTjlBd3TyO7u4ir4aLy5gMDaocyiftmxW 7FDZrHfIzFQnCp7F+P672aKTbNXspW8ExsfZQVcsH1vBIMennBHFBQFP4dsCFWrIunbqorhsC hv71pOExVTSbO6+DY4DE8nihePzQ74J/wm/gk2wvRsqjoAFZJOcu5S4nc/ozK/zR+II5poQS3 1zKrrKwuNGfe93nfUbBaJAy9rXFYWqjAkr3KBg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> A window's size might also change when input arrives. > > In what way? I thought it can only change as part of redisplay, which > always happens after some command finishes. Always but not only. IIUC redisplay can also happen when running a timer or upon receiving input. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 13:59:08 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 17:59:08 +0000 Received: from localhost ([127.0.0.1]:40510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1S8-0005ei-Ie for submit@debbugs.gnu.org; Thu, 27 Aug 2015 13:59:08 -0400 Received: from mout.gmx.net ([212.227.15.15]:52649) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1S6-0005ea-SW for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 13:59:07 -0400 Received: from [62.46.211.251] ([62.46.211.251]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Mfn88-1Z7rrw1f2y-00N8Fj; Thu, 27 Aug 2015 19:59:04 +0200 Message-ID: <55DF4FE1.9010709@gmx.at> Date: Thu, 27 Aug 2015 19:58:57 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> In-Reply-To: <83a8tc6988.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:v5V3m26VlsMKYeqyrPDIme3tMCogcLYK/qpeLhxn/+GuSrQJg9l ru2/rk+thE0b9XMaPrRnEk4X/N9zI0wKumBOMDI4g4IkEkwnOYP2w1MhlN0KjXm1imWEMMG zmxYkvJeFuoMn/+Kk/sS0XbuPuyFlTL8hSWXs3Yl8qV6zCamRadAsq1lKqGZvaNbu4HDRPN w7FM9NMieegN7oNPHsFQA== X-UI-Out-Filterresults: notjunk:1;V01:K0:objFOqDLt5Q=:8bsWRZXkO/kWLmGLKaR6uB vkzCrYDO1gkT8Aq4lt0FV03zVIh4Lsjl3FHPi1bkZW7Z2I/NH91D27yk15ne5GebWCv+jNGmt iqWKeh+ZcwrW80paq2tQx/jM8DTUG+Q0qgz8/BSmqfFYCtziQ9vGj3+nL+33BxtNsoMCfMVTL 8L2G9t+P6Vlukp0rN078zPKVSPL3rVw+RSbSGfZSegHtXYtcEB+49z9Tlak911rbv4BL743s2 Ali3xFpmu/ddgZsv9zw1JJEVHlLLhucvDleTx2sBMPOTKvHziMVOy+zRsqghblxMsPVAnwUxq WzUPOAOhIWHUdRb01ts4eKWlTpw/d0/ynztfjMTiPK47dK7fB/7eNkN3xyEqgUJngAs8NvXGt 2lO8WibdXijR6CUozxjvUW8fI8XluV4rIAOwTRBEMbTG11x1KB+KSBDDDwhGVuH2zi/jNmEu/ sVAg09LVe/E43YqoYFhO8A6L5TfHtFxDayyDRv4lbvsqhkkemiSjEgVZu0KuAtn0JXOVJN/8f Pd77pwq0gefaS1DeNqP51FtPGtCDR8+2Ket2xY7igmgnhR1WtiAJdDI1qV2SypkIB1PmWrq4s A0sseMih7Mbzk+MpZvbUwxIj0amgXd+Eoqw+LvouS5cYCF+8O87oSsh9MupVtrFuIEiYlv5rH xRZ7zq6ZoTPAPo/hstUN38TKiuDTKHZkdFVrZOuzA0aRt2BATs4JWJzg9pPP0KpuVBIr4ItiB SoveSvgN0/vQVGNJrrv7vVXkrkWTs4Ys5VgFfQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Any command that clears the echo area will resize it back, AFAIK. So > it's not persistent. I was talking about the changed window-start position. That one _is_ persistent, that is, not restored. Maybe that case can be handled via =E2=80=98window-scroll-functions=E2=80=99 but that's not immediately clea= r to me. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 13:59:20 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 17:59:20 +0000 Received: from localhost ([127.0.0.1]:40513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1SJ-0005f6-Sn for submit@debbugs.gnu.org; Thu, 27 Aug 2015 13:59:20 -0400 Received: from mout.gmx.net ([212.227.15.15]:55491) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1SH-0005ey-P9 for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 13:59:18 -0400 Received: from [62.46.211.251] ([62.46.211.251]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTBsk-1ZKX2Y18Q2-00S3Ex; Thu, 27 Aug 2015 19:59:16 +0200 Message-ID: <55DF4FED.5040009@gmx.at> Date: Thu, 27 Aug 2015 19:59:09 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet , Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:Dt6mKMQvaDWWByYeu3nJ3trTxqP52EpuiuZWedy+6ldMOSZhI4l n16sXoVS/JuK0kU38PnuytedEck50vfe7pFvnNdsLMgjnF8C3iRqj61AuNcOgtKriIhUd9T lKd7cNg03PYqivpRGsqG/3YDqFI7lxlxTEHfdUFnV+yvmjYo9WOpghyPgwEvSxpf7AHE08d tG1dOOl4j+wuFN+lg+FXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:0qUpcWI0g/o=:/yA7sVWa8B9HGfYwSJHFCg +je8UFOnubaNKnkAegI0oidpscvU0N4l2dhe3BT4gN58b/auSNqaF6I0YuWEvHoVkJ1H4MtVt UP+BAAjIrkx8gW1rnOXJR1/CU3UdtfV7/QAssLKd03dc0ZTXMpuHDZ4pKWgoW8efQV9gFfBpm psNnnbwhW0zZ7ywPCyAUk1jGgSKPhU+uoFhpX31y4urZpkysnTOVf0ldJXwLNfjE85qPuzhtr QeIKr8BJciByCXSH2QAbxABUa1VQf2ai8q9yxCqs1l5kO2RKLOIbWTU5kZCpK9DaL/ACRpcfq 4a6J36DSyUfZEhtrc6ZQKYMVmF1fQH8kwzxagxiGAleC8llA2QeJdDfowLoiFwlbg5k+Jbnew hKEqWudAD8IDYvW9ytuvMEATIhh47zyxAlltZk65xwCJrxLnVbgCNEn0yut+G4Oy56Jz4MFS3 Zr0ptG65i/w/XrdkDFx0O9CiUVkG306HPDl/qgq7hyEGA36fN136DSavA1iCP/8IOkKbTE59F hrTm0eC8fgDzPPnla+zHSrE8+99dPXEpCBY5U6DgyVCnNkowJBGYSLIEn5U4kp1Yp2wtl+gkB lEhVDUzZDpRJMEvu3HfiBF7jnO+11LecbIxQUd3ZC6Bv27gKw9j87VCwiWWyCsKo50ncBJl3B HgCA3cCMrh+SJZVbRVen5b+vP635TSkwlNUp2sL/ix5YEetM0ozPjJ6iTE8VCqb/vnDLCZzMA xDTAoPZRVKIuTm1z8BqDITY48kBq1Y64H8JufA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > 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 = back > to calling prepare_menu_bars, ... But this also means that your initial patch wouldn't help anyway. Even if we set WINDOW_SIZES_CHANGED in grow_/shrink_mini_window, =E2=80=98window-size-change-functions=E2=80=99 won't be called any more i= n the present cycle. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 13:59:25 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 17:59:25 +0000 Received: from localhost ([127.0.0.1]:40516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1SP-0005fO-Cy for submit@debbugs.gnu.org; Thu, 27 Aug 2015 13:59:25 -0400 Received: from mout.gmx.net ([212.227.15.19]:50950) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1SN-0005fG-L3 for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 13:59:24 -0400 Received: from [62.46.211.251] ([62.46.211.251]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7YF5-1YXykX0sjP-00xKGy; Thu, 27 Aug 2015 19:59:22 +0200 Message-ID: <55DF4FF3.1020603@gmx.at> Date: Thu, 27 Aug 2015 19:59:15 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet , Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uT6r1wlW6rOGJaf8/tAUOePodKboexPFqA0Ad3gRDp7ZtWz+d3r RMaYHxXClwZ7A3FsqQQIVjcdVQog0sUlGEQGc5gELD1vtym80RX/WrPDv3UIvC+l9+b7jBx Mv0y/m4AI1H9Qwr8JBCsL/uXq6BwUWj7gXfXePNHY4OLR7Hfr9Z734KJsSMbQ4XSJxhWCYW sCB7HOuagF8N+mfxQmcSw== X-UI-Out-Filterresults: notjunk:1;V01:K0:EDvvrTtMwUc=:uZhyhveWiV/32wUOh0mMe0 Bf9hoCTiODq3G0i9PWabRHlRsMQwHku0UyertTZvhl2UrX7WYxuGXvvE1tcH4ZcJ+piSu+RjV oFYGGsUUOZnQK9i5fSnrKabimC5Fuc4NsilSdzRAYstwWGH6UqRxlSKS/kASEZTCNFRXDumG6 4IEuANiayqK6JcdbcrpXjmdparjAbmNU5xfaXvK3uEG/obXqClqCMAj/TFxA/M9aUUUdtulUN SG4czWSaCZOPV6uVCNAKDjV6XWmgD9U9KTtO/Qt+iNooxsEXjlEAXygQYqniAsB6+5XFrqHie UX4Xcozj7lZ1XlzjLJQUVPjHTihEnvshiNnslpSzTnB01vFAL89MNtncMpCauoqVz6i3ipTls 8YaLY9gSmhR17wR9ltm8eF7afIEfBgKd2Mcr4X32woZTPelKkNcEVL7UUAEInC9uqDT1P4RjC 8+qPNaIHZmDEQjpdGV5+tppmNceqHKep9jXJtdb2w+/udS53Kh7SW9uAiMoh/09LoQatmKl9J GDL+4K/ivoW74SO1AluoGFyae9IzZa7yypt83xR7Mpr+JjMFrBmRZQ8FdNpft6A5MgPnnnyHu SIxBxK9IFBSqtcw3AlHtCneOHOPO3EnG5fJW3Vme1RmlYGVV6oXmgcFxZpJMEroEh3j7v3a5Y aYV7RzwgKijJdKD0fL02MaabRwXCfK6VWbzBElqMzlfDuplWQN6WGp2MHnIsHxLOP6Asw43w6 hTZwYKZ/N9oMqz6/L0FDEq2CXxZKsnanalmUwA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I think that last case is something we haven't considered yet: if I resize > windows manually while the mini-window is enlarged, they will be in an > inconsistent state when it goes back to normal, right? FWIW here resizing a window "manually" makes the mini-window "go normal" first. Resizing the frame leaves the mini-window alone. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 14:04:48 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 18:04:48 +0000 Received: from localhost ([127.0.0.1]:40522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1Xc-0007Lh-Co for submit@debbugs.gnu.org; Thu, 27 Aug 2015 14:04:48 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:37698) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV1Xa-0007LZ-2a for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 14:04:46 -0400 Received: by igui7 with SMTP id i7so42327347igu.0 for <21333@debbugs.gnu.org>; Thu, 27 Aug 2015 11:04:45 -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=q+uXUL+tF2N3M3soAGHe0s/4rnuTXnV2fJIrOVYYsKo=; b=gwi3vlBzPT7PiCrLA0JJX/E9bdJOYENsbWPBonud4WFrJB5AgjINO8ZAFJNG1/OjLX uDzHHt8NhEUNrnPcMOwK9HaaL7/gMo/oAq9TE01J2CgNV2wEhMPor/XlSFCYPfPmF3Dc 0pGrhbKC+xxyuZY5zg8y3x/3RfOSReSwl/XuNGxdSHO7ysH7oNDlpD6ZeT1x2mqhAPvK RCnwVQDsgV40OJyAVP+J2oIKdDkMPRe+PvjmjoP0CArcvZ1RffUeL1/0lXrDruEbNPh7 bdB65wiExT3qk6DGN9aK9A4gk+oZV4v6Lo/vRO3r7WS2sh/wDfiFXwVpXt4GDkThmy9j A1tw== MIME-Version: 1.0 X-Received: by 10.50.97.33 with SMTP id dx1mr17110016igb.1.1440698685306; Thu, 27 Aug 2015 11:04:45 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Thu, 27 Aug 2015 11:04:45 -0700 (PDT) In-Reply-To: <55DF4FF3.1020603@gmx.at> References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> <55DF4FF3.1020603@gmx.at> Date: Thu, 27 Aug 2015 18:04:45 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: martin rudalics Content-Type: multipart/alternative; boundary=047d7b10c8895de007051e4ecd49 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b10c8895de007051e4ecd49 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 5:59 PM, martin rudalics wrote: > > I think that last case is something we haven't considered yet: if I > resize > > windows manually while the mini-window is enlarged, they will be in an > > inconsistent state when it goes back to normal, right? > > FWIW here resizing a window "manually" makes the mini-window "go normal" > first. Strange, that doesn't work here. Are you using the echo area or the minibuffer to test? I'm using the minibuffer. > Resizing the frame leaves the mini-window alone. > ...which means they'll be in an inconsistent state afterwards, having been resized while the mini-window was enlarged. --047d7b10c8895de007051e4ecd49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 27, 2015 at 5:59 PM, martin rudalics <rudalics@= gmx.at> wrote:
> I think tha= t last case is something we haven't considered yet: if I resize
> windows manually while the mini-window is enlarged, they will be in an=
> inconsistent state when it goes back to normal, right?

 FWIW here resizing a window "manually" makes the mini-window &quo= t;go normal"
first.

Strange, that doesn't work here.= Are you using the echo area or the minibuffer to test? I'm using the m= inibuffer.
=C2=A0
=C2=A0 = Resizing the frame leaves the mini-window alone.

...which means they'll be in an inconsistent state afterwa= rds, having been resized while the mini-window was enlarged.
--047d7b10c8895de007051e4ecd49-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 14:35:13 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 18:35:13 +0000 Received: from localhost ([127.0.0.1]:40540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV213-00084W-38 for submit@debbugs.gnu.org; Thu, 27 Aug 2015 14:35:13 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:38830) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV210-00084N-H1 for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 14:35:11 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTR009007DVK900@mtaout28.012.net.il> for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 21:35:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTR00AJS7MD1A00@mtaout28.012.net.il>; Thu, 27 Aug 2015 21:35:02 +0300 (IDT) Date: Thu, 27 Aug 2015 21:35:10 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <8337z460m9.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 27 Aug 2015 17:05:35 +0000 > From: Pip Cet > Cc: martin rudalics , 21333@debbugs.gnu.org > > > Since mini-window resizing can persistently > > change the end position of the first of these windows > > Any command that clears the echo area will resize it back, AFAIK. So > it's not persistent. > > > That's not what I'm seeing here. When I run: > > (progn > (run-with-timer 2 nil (lambda () (message "hi"))) > (run-with-timer 3 nil (lambda () (message ""))) > (read-from-minibuffer (make-string 3000 ?*))) > > The minibuffer resizes once, when the read-from-minibuffer prompt makes it grow > to its maximal size; it then stays at that size as the short message is being > displayed, then restores the long minibuffer prompt without changing size again > when the echo area is cleared. That's a different situation, quite bizarre btw. Just run normal code, like only the message above, then move the cursor, and you will see the echo area shrink back. That's the normal use case. > > OT1H we do care about point being visible when its window is partially > > obscured by the mini-window and deliberately scroll the window in that > > case. OTOH we'd say that `follow-mode' should not care about keeping > > its text coherent in that case. Is that fair? > > Yes. In that situation, the user most probably reads the mini-window > text anyway, and if not, then she reads the text at point. The > probability that she is reading the text that will be scrolled out of > view as result of the mini-window resize is IMO minuscule. > > So if, for whatever reason, I have a timer function that displays a two-line > message once a second (so the echo area never goes back to its single-line > state), my follow-mode buffer will be and remain in an inconsistent state until > I manually resize a window, when it will go back to a consistent state, but > then if I cancel the timer (and the mini-window shrinks) it'll be in an > inconsistent state again, and the only way out of that one is another manual > window resize? I'd say just don't do that, it's terribly annoying to see such display even without the other issues. > I think that last case is something we haven't considered yet: if I resize > windows manually while the mini-window is enlarged, they will be in an > inconsistent state when it goes back to normal, right? What do you mean by "inconsistent state"? From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 14:39:18 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 18:39:18 +0000 Received: from localhost ([127.0.0.1]:40544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV250-0008AO-2u for submit@debbugs.gnu.org; Thu, 27 Aug 2015 14:39:18 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:59984) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV24x-0008AC-7W for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 14:39:16 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NTR000007JLDW00@mtaout27.012.net.il> for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 21:36:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTR00JRI7O8IQ60@mtaout27.012.net.il>; Thu, 27 Aug 2015 21:36:08 +0300 (IDT) Date: Thu, 27 Aug 2015 21:39:15 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55DF4FCD.9000104@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83zj1c4lv0.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> <55DF4FCD.9000104@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 27 Aug 2015 19:58:37 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org > > >> A window's size might also change when input arrives. > > > > In what way? I thought it can only change as part of redisplay, which > > always happens after some command finishes. > > Always but not only. IIUC redisplay can also happen when running a > timer or upon receiving input. Only if the last command finished. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 14:57:09 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 18:57:09 +0000 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 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 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) 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) Date: Thu, 27 Aug 2015 21:57:06 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83y4gw4l19.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 15:00:23 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 19:00:23 +0000 Received: from localhost ([127.0.0.1]:40563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV2PO-0000Do-ON for submit@debbugs.gnu.org; Thu, 27 Aug 2015 15:00:23 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:52593) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV2PL-0000De-SZ for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 15:00:20 -0400 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 22:00:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTR00A068SB1A50@mtaout28.012.net.il>; Thu, 27 Aug 2015 22:00:11 +0300 (IDT) Date: Thu, 27 Aug 2015 22:00:20 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <83zj1c4lv0.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: rudalics@gmx.at Message-id: <83wpwg4kvv.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> <55DF4FCD.9000104@gmx.at> <83zj1c4lv0.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 27 Aug 2015 21:39:15 +0300 > From: Eli Zaretskii > Cc: pipcet@gmail.com, 21333@debbugs.gnu.org > > > Date: Thu, 27 Aug 2015 19:58:37 +0200 > > From: martin rudalics > > CC: pipcet@gmail.com, 21333@debbugs.gnu.org > > > > >> A window's size might also change when input arrives. > > > > > > In what way? I thought it can only change as part of redisplay, which > > > always happens after some command finishes. > > > > Always but not only. IIUC redisplay can also happen when running a > > timer or upon receiving input. > > Only if the last command finished. That was confusing. Let me rephrase: Emacs only reads subprocess input or runs timers when it's idle, so these events are only possible after some command finishes, and Emacs gets back to its command loop. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 16:49:22 2015 Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 20:49:22 +0000 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 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 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== MIME-Version: 1.0 X-Received: by 10.50.137.100 with SMTP id qh4mr533162igb.1.1440708558141; Thu, 27 Aug 2015 13:49:18 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Thu, 27 Aug 2015 13:49:17 -0700 (PDT) In-Reply-To: <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> <83y4gw4l19.fsf@gnu.org> Date: Thu, 27 Aug 2015 20:49:17 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11c31f74d545ef051e511928 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --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-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 04:03:59 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 08:03:59 +0000 Received: from localhost ([127.0.0.1]:40760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEdi-0000D4-WD for submit@debbugs.gnu.org; Fri, 28 Aug 2015 04:03:59 -0400 Received: from mout.gmx.net ([212.227.15.18]:59564) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEdg-0000Cq-Gg for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 04:03:57 -0400 Received: from [178.190.19.248] ([178.190.19.248]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M2tXS-1YgI9626a6-00scYX; Fri, 28 Aug 2015 10:03:54 +0200 Message-ID: <55E015E3.2050409@gmx.at> Date: Fri, 28 Aug 2015 10:03:47 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> <55DF4FF3.1020603@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WSeeiNC8tgSmsqJzZCaRHab6NELj5c6aXHiWvt1OGIO8NLYIHvO pPR9C3ovh9OTcoj+bbzZWS9pYK2dYFfQfQfI48cCT+TMc2JYJ/kC1bGz8/3m+WyYF2eyKyA OYxrZ1gvR368S6aoHDrdZW/coh159MQ1OkyB0/E35dQ7O7l05EIaSIZBNpSST1hIzF075BH 3GVA7pVUgjWVv51/hMByQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:nEey3Dpg3/Q=:1kfZH5g9tcUeJ+CM3Qle4T 353aCDMJ4zOFgVRib0GBYJ7tkl4glWQv+mi3LQZ0BaAPN1uY35S/F292sCUTz6q9hfWY8H/kP Z8/cu5edE9sTe+LPloO7qmaEHK0E8edvYM+Ib9a0Yqj1qHdyVPqg+2LSwHDAU4qUSsYAmiKw4 kMSpRN4yZgnsobRnSXuHoOfKqiYD7HJZO7GOV5Zn2u9LG/gtc2vZGxbqIFhNem/50617aDqm6 gOVNEQVuLuuWNQI+bsmnQE8AdPWY8j+RYGIE6PZ2K5svW8eYgvBpdhCScl+89AZr/FmXS4oGN A//r1ZMyWGT/Zt/vjLeGYbiwq2YSzG+C/hWUR4ql/AiF1ijhzm4kFvdkiTiX9sOrcOICi9qGs W3OmIPHK5/ro49RYLWjqw54uS8bFYy6RAez/YFsKA/rJ1lN2O8Lb/7Bcd03khOa5nNwy8LEQ1 bkoo2XYsrnB/x9iFFp31kVT1mKAmgM0CA3QiJMQ0suuTAR+/pTuARKBhE2OP6xHqa6m/x2gny bPMNgVpS6wvvrUdzyEuoS8wOe6ks+SC1MsCkPf3y+gBUGaSfEXMoGkwbbBZrvpQ7UHo1fBDb9 fLXgy4l7zWznSKYEnU5nfEa1iqWiTFPEf2C7neJ1BRySJPOAXY7BXpWdyGsbagSW2e1Ajy1cU BANbhEGsYmIhrVA1Y4v9mZHkegPsP1KYMt1DHpSsMjd0vus4o39FqDGg5y0uQI9QqvFPwkIco +vLP4mr604bbeKxnFTWrqA4kt80zM9eDQhnRNg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> FWIW here resizing a window "manually" makes the mini-window "go normal" >> first. > > Strange, that doesn't work here. Are you using the echo area or the > minibuffer to test? I'm using the minibuffer. It goes back to normal in the echo area but leaves the minibuffer window alone as you say. What precisely did you use? >> Resizing the frame leaves the mini-window alone. >> > ...which means they'll be in an inconsistent state afterwards, having been > resized while the mini-window was enlarged. Can you tell me more about this inconsistency? martin From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 04:04:37 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 08:04:37 +0000 Received: from localhost ([127.0.0.1]:40764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEeL-0000EJ-Fi for submit@debbugs.gnu.org; Fri, 28 Aug 2015 04:04:37 -0400 Received: from mout.gmx.net ([212.227.15.15]:58838) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEeJ-0000EB-99 for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 04:04:35 -0400 Received: from [178.190.19.248] ([178.190.19.248]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4nYT-1YmbmO003Z-00yxQG; Fri, 28 Aug 2015 10:04:33 +0200 Message-ID: <55E01609.2090102@gmx.at> Date: Fri, 28 Aug 2015 10:04:25 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> <55DF4FCD.9000104@gmx.at> <83zj1c4lv0.fsf@gnu.org> <83wpwg4kvv.fsf@gnu.org> In-Reply-To: <83wpwg4kvv.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:bBssRmj7aqqpj6AARTFShAhaj5gfiO6tJlqRZsqi3LnaGVmfr0F BYI6ikCxySvrzXGZwGwKhq5hkk02F2QV3CACh6n2LmK77dGXy2dRa12pr16LhJ6LfORLI4Q rPlwtuam5UqT28jx0NUB/FGMbF527hSVy9GZT5pnTUT99g1QKHv38V2iZfcfCbsk41vBmv9 iqLsEkD4BUuQ9dVkgWvdQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:iGPQgw1aLMY=:inbSP21KKuWZV61sCOfgMw zKWAn9oBQCMNERIKK3RSGEHXU8S3FMej8Td0g5yXai02reeXWwb7l6ftDw2OlDyNGPYeunyEZ HHCl8r3X1oBC7hmiGB+NWUBwugqhRV4Y/mx77MBpYotoqDe8GmQjII2HCQRfZleTZEiC728fw 91BOfobFkbKqn5EWk8j1b9MQTHZ+r+79kiWZhI/vhpbBDnq4SwQvcdWrGuQbHdS/dmLsAvFXX QH2XCtu7k5Vtc67T3uyEiz+Fq4OsIlsF9qXHUe91i8iPRfm9tdNfzdx5X9lSmcssd8NfeiHDM xJuIm3jz6He9+XetHoIwJjLqqhLnKjhvhxlZY0pxI3h9imatsT2M829pdAKM4l9D5Zl9bMRtY wstpAp9Kn1xdoFE8J0fsc0KUT2QHFID+B6KoWN4CfNNqD/xCdv9YDJN7wM7KSYcIgPzhsqlwe ll4qEd7QPyPHXDNvykzjrjtOJNmzvP5BUJiACdzKer7cUHyaP4Ph2QL9SBYTi+3eF23QBqjIW xr5OcEkzz1lGLOVnIiGVbSrhpbRrjSvh6nYcgGR/RdjOyO/heiSOFJEzLcxXLxRPm2c5AAsbm seNHagfIz4/XXeH48p8X7thvr6N3YiCLB+q0PXNW8ZfPRIw7qjqi2sDS/e9Zq723X3wdMKi6B yNavrEMd9IcxLwlXE1ek398sTShxuSdg6OXCkcigQPFdjJtH3zZbezROKsuPG4/UaHJOIn9/B TfkOfT59uRjKCfYemCZ7R4Ga+hxtxcW4pnEMdQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > That was confusing. Let me rephrase: Emacs only reads subprocess > input or runs timers when it's idle, so these events are only possible= > after some command finishes, and Emacs gets back to its command loop. Obviously. My point was that =E2=80=98post-command-hook=E2=80=99 won't c= atch these. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 04:19:33 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 08:19:33 +0000 Received: from localhost ([127.0.0.1]:40769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEsm-0000ZV-T2 for submit@debbugs.gnu.org; Fri, 28 Aug 2015 04:19:33 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:36648) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEsk-0000ZL-4D for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 04:19:30 -0400 Received: by igcse8 with SMTP id se8so13293983igc.1 for <21333@debbugs.gnu.org>; Fri, 28 Aug 2015 01:19:29 -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=c6ZWfcNMzo7gKp/wy+CELoG512pciwib8sTB6KiOAHY=; b=J30AzW87LeqqsQrS6fhAk9RVOJECBlavOlWcsvrazAiG6GT+enhEZn52MgYf6tET/A kWf8pclrfKoXWT9Yoc7kbrmLY2vD4RpBrynKt7IM53vZky0H7joenWeBXcGeQlh3xRzz 9lAVFaXPMytlbgVkuxduEH8vsfrcQgrFLJGY5mvfWBEj4dcdJ0OJZAIM+IItG+QbW24J 6T/UNbjyRj4LcMsoafSosLoul1ZMEuvpH8p6CEvA9hZTe5afYakC+CWczGFGH2YV3/ER evL9NTSoRUImt+YIkjUvQQDwIn2bMFH257PUNgWChsg325xlouKainT6b7D+spkiHQlC 8BjA== MIME-Version: 1.0 X-Received: by 10.50.97.33 with SMTP id dx1mr2125357igb.1.1440749969536; Fri, 28 Aug 2015 01:19:29 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Fri, 28 Aug 2015 01:19:29 -0700 (PDT) In-Reply-To: <55E015E3.2050409@gmx.at> References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> <55DF4FF3.1020603@gmx.at> <55E015E3.2050409@gmx.at> Date: Fri, 28 Aug 2015 08:19:29 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: martin rudalics Content-Type: multipart/alternative; boundary=047d7b10c88924fc44051e5abef8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b10c88924fc44051e5abef8 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 8:03 AM, martin rudalics wrote: > >> FWIW here resizing a window "manually" makes the mini-window "go normal" > >> first. > > > > Strange, that doesn't work here. Are you using the echo area or the > > minibuffer to test? I'm using the minibuffer. > > It goes back to normal in the echo area but leaves the minibuffer window > alone as you say. I had assumed "go normal" meant "shrink back to normal size", which is true for the echo area but not the minibuffer. > >> Resizing the frame leaves the mini-window alone. > >> > > ...which means they'll be in an inconsistent state afterwards, having > been > > resized while the mini-window was enlarged. > > Can you tell me more about this inconsistency? > Well, first, to clarify, I was talking about unpatched Emacs, and using window-size-change-functions in an attempt to catch window size changes. 1. window at 80x24, mini-window at 1 line, window thinks it's 80x24. Everything okay. 2. mini-window grows to 2 lines 3. window at 80x23, mini-window at 2 lines, window thinks it's 80x24. Inconsistent, but temporary. 4. user resizes window to 79x23. size-change-functions called. 5. window at 79x23, mini-window at 2 lines, window thinks it's 79x23. Everything okay again. 6. mini-window shrinks. 7. window at 79x24, mini-window at 1 line, window thinks it's 79x23. Permanent inconsistency. Am I missing something here? Pip --047d7b10c88924fc44051e5abef8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 28, 2015 at 8:03 AM, martin rudalics <rudalics@gmx.at> wrote:
>> FWIW h= ere resizing a window "manually" makes the mini-window "go n= ormal"
>> first.
>
> Strange, that doesn't work here. Are you using the echo area or th= e
> minibuffer to test? I'm using the minibuffer.

 It goes back to normal in the echo area but leaves the minibuffer window alone as you say.

I had assumed "go no= rmal" meant "shrink back to normal size", which is true for = the echo area but not the minibuffer.
=C2=A0
>>=C2=A0 =C2=A0 Resizing the fra= me leaves the mini-window alone.
>>
> ...which means they'll be in an inconsistent state afterwards, hav= ing been
> resized while the mini-window was enlarged.

 Can you tell me more about this inconsistency?

Well, first, to c= larify, I was talking about unpatched Emacs, and using window-size-change-f= unctions in an attempt to catch window size changes.

1. w= indow at 80x24, mini-window at 1 line, window thinks it's 80x24. Everyt= hing okay.
2. mini-window grows to 2 lines
3. w= indow at 80x23, mini-window at 2 lines, window thinks it's 80x24. Incon= sistent, but temporary.
4. user resizes window to 79x23. size= -change-functions called.
5. window at 79x23, mini-window at = 2 lines, window thinks it's 79x23. Everything okay again.
6. mini-window shrinks.
7. window at 79x24, mini-window at 1= line, window thinks it's 79x23. Permanent inconsistency.

=
Am I missing something here?

=
Pip
--047d7b10c88924fc44051e5abef8-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 04:45:31 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 08:45:31 +0000 Received: from localhost ([127.0.0.1]:40777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVFHu-0001AH-Ri for submit@debbugs.gnu.org; Fri, 28 Aug 2015 04:45:31 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:33424) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVFHs-0001A8-Ha for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 04:45:29 -0400 Received: by iods203 with SMTP id s203so85770401iod.0 for <21333@debbugs.gnu.org>; Fri, 28 Aug 2015 01:45:28 -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=45JMO+P/5tcGojsF69KYxXcjdod054QJdQBPK90680g=; b=LXUHI9SZMYqLMGhvtCc4pkP8LVll2mxxbmf+i0BpbweQAmTJdwYbqsALpGSg5xG1Pu 0JI4N7+CZqNFEHwnd0GiD8clWoXOa3RewFzk3CrXWn76J+Wrw07lahTI/0kDI2vH7NUz 492KA1n59vSC4X/XdQZ9DPmQkIQbCcaM7+IThigmFYd9rfptFPW3ZaZw8pSY9RVTmX4G NX6ouYCp48OzV0PYI5LSpJ0v2NqX9TvzXDv7XT7wzASY3KOP/QKg2m+lnHLe44jfWRU7 N1Nym0o32wuomxYdMT4kk6fmo3YugXzMTei/hnXGOA7XP7nP4a829u+MqCqNs2xiuB// elwA== MIME-Version: 1.0 X-Received: by 10.107.132.139 with SMTP id o11mr12716468ioi.3.1440751527938; Fri, 28 Aug 2015 01:45:27 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Fri, 28 Aug 2015 01:45:27 -0700 (PDT) In-Reply-To: References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> <55DF4FF3.1020603@gmx.at> <55E015E3.2050409@gmx.at> Date: Fri, 28 Aug 2015 08:45:27 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: martin rudalics Content-Type: multipart/alternative; boundary=001a113ed2f80851b4051e5b1b9e X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: Eli Zaretskii , 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113ed2f80851b4051e5b1b9e Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 8:19 AM, Pip Cet wrote: > > Am I missing something here? > Turns out I was missing (at least!) one thing: step 6 needs to be triggered by a recursive minibuffer invocation, because exiting the minibuffer will restore the old window configuration. The inconsistency can still happen, but it's much more difficult to trigger than I thought. (I must say I don't think restoring the window configuration upon minibuffer exit is the right thing to do: if the user created, split, or resized windows manually during the recursive editing session, at least those manual changes should not be undone when they end that session. As you've pointed out, looking into window configurations is quite tricky (and impossible from Lisp code, IIUC), and I can currently only think of a kludge to make it work.) --001a113ed2f80851b4051e5b1b9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 28, 2015 at 8:19 AM, Pip Cet <pipcet@gmail.com> wrote= :
Am I missing something here?

Turns out I was missing (at least!) one thing: step 6= needs to be triggered by a recursive minibuffer invocation, because exitin= g the minibuffer will restore the old window configuration. The inconsisten= cy can still happen, but it's much more difficult to trigger than I tho= ught.

(I must say I don't think restoring the window = configuration upon minibuffer exit is the right thing to do: if the user cr= eated, split, or resized windows manually during the recursive editing sess= ion, at least those manual changes should not be undone when they end that = session. As you've pointed out, looking into window configurations is q= uite tricky (and impossible from Lisp code, IIUC), and I can currently only= think of a kludge to make it work.)
--001a113ed2f80851b4051e5b1b9e-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 04:47:10 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 08:47:10 +0000 Received: from localhost ([127.0.0.1]:40781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVFJW-0001Cx-E0 for submit@debbugs.gnu.org; Fri, 28 Aug 2015 04:47:10 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:48743) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVFJT-0001Cn-KB for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 04:47:09 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NTS00B00AA9QC00@mtaout24.012.net.il> for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 11:39:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTS00AF8APDWL20@mtaout24.012.net.il>; Fri, 28 Aug 2015 11:39:13 +0300 (IDT) Date: Fri, 28 Aug 2015 11:47:08 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55E01609.2090102@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83mvxb4x6b.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> <55DF4FCD.9000104@gmx.at> <83zj1c4lv0.fsf@gnu.org> <83wpwg4kvv.fsf@gnu.org> <55E01609.2090102@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 28 Aug 2015 10:04:25 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org > > > That was confusing. Let me rephrase: Emacs only reads subprocess > > input or runs timers when it's idle, so these events are only possible > > after some command finishes, and Emacs gets back to its command loop. > > Obviously. My point was that ‘post-command-hook’ won't catch these. Are you sure you aren't making some incorrect assumptions about the exact place where the command loop calls post-command-hook? What if it is called immediately after processing the above events? From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 06:02:06 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 10:02:06 +0000 Received: from localhost ([127.0.0.1]:40815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVGU0-0002yI-W2 for submit@debbugs.gnu.org; Fri, 28 Aug 2015 06:02:05 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:42843) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVGTw-0002xq-Lk for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 06:02:03 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NTS00P00E696E00@mtaout25.012.net.il> for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 12:58:33 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTS00KOWEDKZW40@mtaout25.012.net.il>; Fri, 28 Aug 2015 12:58:33 +0300 (IDT) Date: Fri, 28 Aug 2015 13:02:01 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83fv334tpi.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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 27 Aug 2015 20:49:17 +0000 > From: Pip Cet > Cc: rudalics@gmx.at, 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 don't think you've misread, no. See below. > 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. That's my interpretation as well. There's some misunderstanding here, but I'm not sure what it is. We keep saying the same things about the higher levels, and for me it's clear that our argument is about lower-level details, not about the high-level overall picture. But you for some reason think we disagree on that higher level. Upon re-reading the thread, it's possible that the misunderstanding is due to the following factors: . it's not always clear whether we are talking about what would happen _after_ resize_mini_window is changed to raise the frame's "windows changed" flag, or about the current code where it doesn't; . both window-size-change-functions and pre-redisplay-function is being discussed, although it should be clear their purpose is different, and in particular pre-redisplay-function cannot be moved from where it currently lives, at least not significantly: it must run _before_ the bulk of the redisplay code runs, or else it will fail to fulfill its contract; and . you introduce issues into the discussion that are not directly related to it, which just muddies the waters, for example: > > 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=0x1265ef0, delta=210, pixelwise=true) at window.c:4488 > #1 0x0000000000452c01 in resize_mini_window (w=0x1265ef0, exact_p=true) at > xdisp.c:10833 > #2 0x0000000000426fb9 in do_switch_frame (frame=54632789, track=1, > for_deletion=0, norecord=43920) at frame.c:1163 > #3 0x000000000042718d in Fselect_frame (frame=54632789, norecord=43920) at > frame.c:1225 > #4 0x0000000000496566 in select_window (window=54633277, norecord=43920, > inhibit_point_swap=false) at window.c:499 > #5 0x00000000004967de in Fselect_window (window=54633277, norecord=43920) at > window.c:575 > #6 0x0000000000453fe7 in x_consider_frame_title (frame=54632789) at > xdisp.c:11487 > #7 0x0000000000454437 in prepare_menu_bars () at xdisp.c:11595 This code path is realized when Emacs needs to perform a thorough redisplay, which happens relatively rarely. How does adding this complication to the already troubled discussion help to reach an agreement and move on? IMO, we should first agree on what happens in 99% of cases and on solutions to that, and then see if the remaining 1% needs any minor corrections. By contrast, if we keep adding more and more marginal cases, we are just expanding the tree of issues that need to be discussed without control and without any hope to advance any time soon. > 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. No, I mean the next one. Because the frame's "windows changed" flag is tested before the flag is set (if it will be set by resize_mini_window). > I had assumed your message referred to the state of Emacs as of HEAD, not with > my proposed changes included. It was. > > 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?... > > 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. 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 I hope it is clear that, depending on what exactly the hook function wants to do with the info about resizing, it could or should be called in different parts of the code, which are involved in these steps. And please keep in mind that the first 2 steps mentioned above are not in a single place in the code. For example, redisplay_window attempts several optimizations, each one of which might eventually succeed; or all of them might fail, indicating to redisplay_internal that a thorough redisplay of the entire frame is needed. > 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. See above: this seems to indicate that your wishlist hook needs to be called somewhere inside update_window. But where exactly, and whether indeed update_window is the right place, depends on what would you like to do with the resizing information. E.g., if you want to do something that will require another redisplay, then update_window is not the right place. In addition, it is not clear whether your hook will care if the window actually didn't change at all. That is something update_window decides on a screen line by screen line basis, as it goes about its job. The result can only be known at the end, and it's quite possible that we will have to add code to collect the results of individual screen lines (I didn't check if we already do something like that). Also, you never actually explained, AFAIR, why it is so important for you to be called "just before the change hits the X server". And finally, I hope you will agree now that pre-redisplay-function is not the right vehicle for these 2 wishes, because your wishes cannot be granted before redisplay did most of its job regarding the window in question. > 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? At the very best, you will be able to obtain part of the information about the window being resized; the rest of it, which redisplay still needs to figure out, will not yet be available. For example, if the window being resized is the mini-window, the buffer position where the window above the mini-window ends will not yet be known. > Wish #2 eliminates the race condition. Maybe, but it also limits what you can usefully do from such a hook. > > 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"? I meant the one we both call "the next". On further thought, it's possible that the current cycle will do that, at least in some situations. It all depends on how redisplay was entered and which windows/buffers have their 'redisplay' flags set. > 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, but you will see in update_frame and its subroutines code that compares the current and the desired contents of the displayed windows. That code only redraws the portions that actually changed. When redisplay decides nothing needs to be recomputed, the current and the desired contents will be identical. > 1. user input > 2. redisplay called That is inaccurate. Redisplay is called after Emacs returns to its main loop and finds that no input is available. Emacs returns to the main loop after processing some command, which could be triggered by user input, or by input from a subprocess, or by some timer that became ripe, or by input from D-bus, or from any number of additional input sources. > 3. prepare_menu_bars called, calls hooks. Hooks think nothing has changed. > 4. grow_mini_window called, calculates new window size You omitted the main part of redisplay here, entered via redisplay_windows (to potentially redisplay all windows on a frame) or redisplay_window_1 (to redisplay only the selected window). That is where data required by update_frame is computed. > 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 has resized. > > Right? Given what I wrote above, I think you will understand when I answer "yes and no". For starters, when you say "hooks" which one(s) do you have in mind? > 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. For which hook? You cannot do that for pre-redisplay-function, because it _must_ run before redisplay. (And "swap" is inaccurate, see my explanations above.) From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 06:51:41 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 10:51:41 +0000 Received: from localhost ([127.0.0.1]:40847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVHG0-00049G-LR for submit@debbugs.gnu.org; Fri, 28 Aug 2015 06:51:40 -0400 Received: from mout.gmx.net ([212.227.17.22]:55720) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVHFy-000497-8L for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 06:51:38 -0400 Received: from [188.22.106.20] ([188.22.106.20]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LvUwp-1YWgDD0u4B-010bKw; Fri, 28 Aug 2015 12:51:36 +0200 Message-ID: <55E03D30.4060908@gmx.at> Date: Fri, 28 Aug 2015 12:51:28 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> <55DF4FCD.9000104@gmx.at> <83zj1c4lv0.fsf@gnu.org> <83wpwg4kvv.fsf@gnu.org> <55E01609.2090102@gmx.at> <83mvxb4x6b.fsf@gnu.org> In-Reply-To: <83mvxb4x6b.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:rnWZoDRYex6UFDwWor/rwZdcCKHwFhRFpnqpvbz0ogIavAI/JdH xyAwxc8sT6FLzs0I821/+TmgxFb7g3bLRPoqxpLyTcrSLR81wiZPTWU1NH44oboK/kRpv6P 75an4AqHAqN+2+5vJMHQJUmEDAfbKAuwU/gePVIZ9m0qX5UFy+gwgv0/eIXaMQo3OlO5rVx hcncFFur5n/n8Ap2hQd7A== X-UI-Out-Filterresults: notjunk:1;V01:K0:LephJBxzzgY=:qgeh7md4fsye55pO/NSglk m7ZMDx8qCprfLCTFWcnQIP+PNLNvBXF1tJp0InpiwDxoeh4euJEvMNQOKT0tO64d0V6kHonHz GslN/mHXNhlbYXQUmpt4WDSIUKp975xQieXLsobJp25uF6IaMr1d13ogmmLb6LbXQ5HG6UDL2 DGkCtDPnmL7PTbKORjwdxuVKx3GHyS1jT+jYRmbYTB+IY8Lyn5CKzxKRju/hz/Cnax7jxILIQ nbOveJ/TBZ820Wp8ElkxbQaR/oK/jRUapoegT/Y6qFY3hJXngj2P7weCLdd+QKsrB3bYGjFVN sl7OJcdXkUqOQOMs5kdpSw7GVg5Q6hrb1g8UBWEYpbWzPD/s6OnTaY16EaIi8cnjkvQ6RscRF lFndXtHn4wq7qoA2EbvCJsH8imNK5MHQceP9tOoQp3x1Kl/EsRORqTwRR03TclZoAdQwo6Pkq EluswZLSsI0Wa5NOnP+REt98MMoeScUUS/qjl56ltXshjuLCFevR7m6bxwfOWiVV+quTUeBWU /jGvvOdowwz8MGpRfyHRWOJCkPY10sLsGiRhsX76805XPc0UgbvCYqoCQWAfyuX4L31/J1rpN bC4Z2yrdBPOxjvsiwtSI/BnHZJzo1bvGh2rxANufvQkwq3hVOVy4K0Ms2js6PzgTA3B6cpHc/ 4nnBo4QFBPALrJrJ7NUPoWW0YJkZQCv9Zu9h0l4VWjvFJ2G2v55QB0PfYooTeq/YA4UOUeTJR gyORWmlIewjLmdHnxRAa54nHjTifru9UQYRFWw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> > That was confusing. Let me rephrase: Emacs only reads subprocess= >> > input or runs timers when it's idle, so these events are only pos= sible >> > after some command finishes, and Emacs gets back to its command l= oop. >> >> Obviously. My point was that =E2=80=98post-command-hook=E2=80=99 won= 't catch these. > > Are you sure you aren't making some incorrect assumptions about the > exact place where the command loop calls post-command-hook? What if > it is called immediately after processing the above events? I don't understand. We don't call =E2=80=98post-command-hook=E2=80=99 wh= en resizing a window gets triggered by a timer. The only way an application can react to such a resize is currently either via =E2=80=98pre-redisplay-function=E2= =80=99 or via =E2=80=98window-size-change-functions=E2=80=99. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 08:35:01 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 12:35:01 +0000 Received: from localhost ([127.0.0.1]:40880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVIrz-00086e-3M for submit@debbugs.gnu.org; Fri, 28 Aug 2015 08:35:00 -0400 Received: from mail-ig0-f174.google.com ([209.85.213.174]:33476) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVIru-00086T-Vd for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 08:34:56 -0400 Received: by igbuu8 with SMTP id uu8so6469142igb.0 for <21333@debbugs.gnu.org>; Fri, 28 Aug 2015 05:34:54 -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=COd4Ajgiy9ZQLhMLDU1+KveSgFFMhiydee+UgBRHrlA=; b=eZOBAYQ2qVcBvT9V43XADl2qi1sJXwFNYGGzk0iV5wP+0L2GOYtSysMrIjqzE1b9hb keJrtWjhKkPuMrxCtadZX2g5X53NcER6dFncGK+DiXxH+u3ZUL2aD/BfI0+agMTq8In/ LHVvs9ElKFi+6idNzZBSPrVApQ7CAZxr9KIW7A6unsmRTi4MQ4zcGF2/A+TVolIgqDeY CbnQVI6Blc3OobF3PskvPtf/ihKctjW597BZSvTjiuV+RPU1+CQ2i5ikBZqQ7wQuq7rP VRgNl0iwtIAxFfjdZcTeywfZNAGxopMVyK+CmaEKnb2pNfhbXB8q6No6Z83iryHMXh5U dYeQ== MIME-Version: 1.0 X-Received: by 10.50.120.9 with SMTP id ky9mr2852353igb.61.1440765294100; Fri, 28 Aug 2015 05:34:54 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Fri, 28 Aug 2015 05:34:53 -0700 (PDT) In-Reply-To: <83fv334tpi.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> Date: Fri, 28 Aug 2015 12:34:53 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=047d7b874bbe8f4889051e5e4f22 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b874bbe8f4889051e5e4f22 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 10:02 AM, Eli Zaretskii wrote: > > Date: Thu, 27 Aug 2015 20:49:17 +0000 > > From: Pip Cet > > Cc: rudalics@gmx.at, 21333@debbugs.gnu.org > > 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. > > That's my interpretation as well. See below. The "On further thought" addendum brings us into agreement. It describes the case I'm actually seeing and testing with here (not just some contrived case that I can trigger with bizarre elisp code), and it makes some of the other statements you made incorrect We > keep saying the same things about the higher levels, and for me it's > clear that our argument is about lower-level details, not about the > high-level overall picture. But you for some reason think we disagree > on that higher level. > Again, I think your "On further thought" addendum settles that disagreement. > Upon re-reading the thread, it's possible that the misunderstanding is > due to the following factors: > > . it's not always clear whether we are talking about what would > happen _after_ resize_mini_window is changed to raise the frame's > "windows changed" flag, or about the current code where it doesn't; > I agree that is often unclear. > . 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" For many purposes, that's interchangeable. So while the intended uses might be different, many applications will be happen to use either one, or a different hook. and in particular pre-redisplay-function cannot be moved > from where it currently lives, at least not significantly: it must > run _before_ the bulk of the redisplay code runs, or else it will > fail to fulfill its contract > See below. > . you introduce issues into the discussion that are not directly > related to it, which just muddies the waters, for example: > I agree we should drop this case. (I mentioned it because it actually happened to me while I was testing, in more than 1% of cases, so it's not a totally separate issue). (As for the general problem, I accept that point of criticism and will try to stay more focused.) > > > 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. > > No, I mean the next one. I'm confused. Do you mean the cycle for which redisplay() has been called but hasn't returned, the cycle corresponding to what will be the next call to redisplay(), or some other cycle? Did you mean to say "Yes, I mean the next one"? I think our problems are partially due to exchanges like this one: > > I had assumed your message referred to the state of Emacs as of HEAD, > not with > > my proposed changes included. > > It was. > But before that, you said (referring to the same message): "I was talking about the situation after you proposed changes, which will cause the flag to be set (AFAIU)." I could not determine from context which statement is valid for which parts of which message. I'm not saying you necessarily contradicted yourself, just that my interpretations of those statements are contradictory. In other words, I'm confused. > 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. Also, the redisplay code is free to call the hook at other times even though nothing has changed. That's part of the wish #1 contract. If I had free choice, my preference would be the second option, but the other options are also okay. > I hope it is clear that, depending on what exactly the hook function > wants to do with the info about resizing, it could or should be called > in different parts of the code, which are involved in these steps. > It is, but I think it would be a valid design decision to leave that unspecified and just say it's one of the three options. > > Wish #2: .... My suggestion is to drop wish #2 for now. 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. Also, you never actually explained, AFAIR, why it is so important for > you to be called "just before the change hits the X server". > Let's drop this for now. (I was thinking about the rather contrived case in which VNC shares one Emacs window but not the rest of the Emacs frame. Before we put anything else into the shared rectangle, I want to clear the previous contents and update the VNC server's shared rectangle coordinates, then synchronize with VNC, and only then permit the redisplay to continue.) And finally, I hope you will agree now that pre-redisplay-function is > not the right vehicle for these 2 wishes, because your wishes cannot > be granted before redisplay did most of its job regarding the window > in question. > I'm perfectly happy using another option instead of pre-redisplay-function. I'm also happy to accept your verdict that pre-redisplay-function is not the right thing to use. > 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. At the very best, you will be > able to obtain part of the information about the window being resized; > the rest of it, which redisplay still needs to figure out, will not > yet be available. For example, if the window being resized is the > mini-window, the buffer position where the window above the > mini-window ends will not yet be known. > That's a very convincing argument. (We can kludge our way around that, of course). > > > 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"? > > I meant the one we both call "the next". On further thought, it's > possible that the current cycle will do that, at least in some > situations. Yes, precisely, that's what I'm seeing! I believe that to be a very common situation, when the minibuffer grows because the user entered more characters than fit in a single line. > > 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). In all the cases that I did look at in gdb, update_frame actually did make changes to (2), but did not synchronize them with (3), so it was important for me to call x_sync in order to avoid falsely concluding that update_frame hadn't performed the update when, in fact, it had. When redisplay decides nothing needs to be recomputed, the current and > the desired contents will be identical. > Do you think this is actually happening in our test situation? I think it's another marginal 1% case that we can drop. > 1. user input > > 2. redisplay called > > That is inaccurate. I did not mean to imply that list was complete, just that it was a description of the typical 99% case when the minibuffer is resized because the user put in a character. > Emacs returns to the > main loop after processing some command, which could be triggered by > user input, or by input from a subprocess, or by some timer that > became ripe, or by input from D-bus, or from any number of additional > input sources. > But we just agreed to drop such marginal cases. 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 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. > 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. > (With the new numbering, it would mean moving step 5 to happen between step 7 and step 8, or installing a new hook there). Are you suggesting a hook between steps 8 and 9? I think that's not a single position in the C code, but it would be the perfect solution. --047d7b874bbe8f4889051e5e4f22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 28, 2015 at 10:02 AM, Eli Zaretskii <eliz@gnu.org= > wrote:
> Date: Thu, 27 A= ug 2015 20:49:17 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: rudalics@gmx.= at, 21333@de= bbugs.gnu.org
> I think of redisplay cycles as beginning when redisplay() is called > and ending when it returns, so in my terminology the "next"<= br> > 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.

That's my interpretation as well.

See below. The "On further thought" addendum brings us into agr= eement. It describes the case I'm actually seeing and testing with here= (not just some contrived case that I can trigger with bizarre elisp code),= and it makes some of the other statements you made incorrect

=
=C2=A0We
keep saying the same things about the higher levels, and for me it's clear that our argument is about lower-level details, not about the
high-level overall picture.
But you for some reason think we disagree
on that higher level.

Again, I think yo= ur "On further thought" addendum settles that disagreement.
=C2=A0
Upon re-reading the thread, it's possible that the misunderstanding is<= br> due to the following factors:

=C2=A0. it's not always clear whether we are talking about what would =C2=A0 =C2=A0happen _after_ resize_mini_window is changed to raise the fram= e's
=C2=A0 =C2=A0"windows changed" flag, or about the current code wh= ere it doesn't;

I agree that is oft= en unclear.
=C2=A0
=C2=A0. both window-size-change-functions and pre-redisplay-function is
=C2=A0 =C2=A0being discussed, although it should be clear their purpose is<= br> =C2=A0 =C2=A0different,

What's the huge= difference? As far as I can tell:
pre-redisplay-function: &q= uot;I'm about to redisplay these windows, and they might have changed s= ize or content"
window-size-change-functions: "I= 9;m about to redisplay windows on this frame, and some of them might have c= hanged size"

For many purposes, that's interchan= geable. So while the intended uses might be different, many applications wi= ll be happen to use either one, or a different hook.

and in particular pre-r= edisplay-function cannot be moved
=C2=A0 =C2=A0from where it currently lives, at least not significantly: it = must
=C2=A0 =C2=A0run _before_ the bulk of the redisplay code runs, or else it w= ill
=C2=A0 =C2=A0fail to fulfill its contract

See below.=C2=A0
=C2=A0
=C2=A0. you introduce issues into the discussion that= are not directly
=C2=A0 =C2=A0related to it, which just muddies the waters, for example:
=

I agree we should drop this case. (I mentioned i= t because it actually happened to me while I was testing, in more than 1% o= f cases, so it's not a totally separate issue).

(As f= or the general problem, I accept that point of criticism and will try to st= ay more focused.)
=C2=A0
>=C2=A0 =C2=A0 =C2=A0So if
>=C2=A0 =C2=A0 =C2=A0resize_mini_window, however it is called, sets the = flag that windows
>=C2=A0 =C2=A0 =C2=A0has been resized, only the next redisplay cycle wil= l notice that and
>=C2=A0 =C2=A0 =C2=A0call 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'r= e currently in.

No, I mean the next one.

I'm con= fused. Do you mean the cycle for which redisplay() has been called but hasn= 't returned, the cycle corresponding to what will be the next call to r= edisplay(), or some other cycle?

Did you mean = to say "Yes, I mean the next one"?


I think our problems are partially due to exchanges like this one:
=C2=A0
> I had assumed your message referred to the state of Emacs as of HEAD, = not with
> my proposed changes included.

It was.

But before that, you said (referrin= g to the same message):
"I was talking about the situation after you proposed changes, = which
will cause the flag to be set (AFAIU)."

I could not = determine from context which statement is valid for which parts of which me= ssage. I'm not saying you necessarily contradicted yourself, just that = my interpretations of those statements are contradictory. In other words, I= 'm confused.


> Wish #1: a way of knowing "when" windows are resized or move= d, 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.=C2=A0 Resizing of a = window
is done in several distinct steps:

=C2=A0. some function (resize_mini_window, if we are talking about the
=C2=A0 =C2=A0mini-window) decides whether a window should be resized, and i= f so,
=C2=A0 =C2=A0computes its start position;

=C2=A0. redisplay_window, called by redisplay_internal, computes the
=C2=A0 =C2=A0"desired" contents of the window on screen;

=C2=A0. update_window, called by update_frame, actually delivers the needed=
=C2=A0 =C2=A0changes to the glass

Wish = #1 is for the hook to be called at any of the following points:
=C2=A0- between steps 1 and 2
=C2=A0- between steps 2 and = 3
=C2=A0- shortly after step 3.

Also, the r= edisplay code is free to call the hook at other times even though nothing h= as changed. That's part of the wish #1 contract.


=
If I had free choice, my preference would be the second option, = but the other options are also okay.
=C2=A0
I hope it is clear that, depending on what exactly the hook function
wants to do with the info about resizing, it could or should be called
in different parts of the code, which are involved in these steps.

It is, but I think it would be a valid design d= ecision to leave that unspecified and just say it's one of the three op= tions.
=C2=A0
> Wish #2: ....

My suggestion is = to drop wish #2 for now.

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 s= ee no way around that complication.

Also, you never actually explained, AFAIR, why it is so important for
you to be called "just before the change hits the X server".
<= /blockquote>
Let's drop this for now. (I was thinking about the rath= er contrived case in which VNC shares one Emacs window but not the rest of = the Emacs frame. Before we put anything else into the shared rectangle, I w= ant to clear the previous contents and update the VNC server's shared r= ectangle coordinates, then synchronize with VNC, and only then permit the r= edisplay to continue.)

And finally, I hope you will agree now that pre-redisplay-function is
not the right vehicle for these 2 wishes, because your wishes cannot
be granted before redisplay did most of its job regarding the window
in question.

I'm perfectly happy using another= option instead of pre-redisplay-function. I'm also happy to accept you= r verdict that pre-redisplay-function is not the right thing to use.

> Wish #1, assuming something like my proposed changes go in and this bu= g is
> closed, has been granted; there's a race condition, but I might ju= st have to
> live with that.

Do you still think it has been granted?

I= f I'm not allowed to use pre-redisplay-function, no.

At= the very best, you will be
able to obtain part of the information about the window being resized;
the rest of it, which redisplay still needs to figure out, will not
yet be available.=C2=A0 For example, if the window being resized is the
mini-window, the buffer position where the window above the
mini-window ends will not yet be known.

That's a very convincing argument. (We can kludge our way around that,= of course).
=C2=A0
>=C2=A0 =C2=A0 =C2=A0> No. The sequence is redisplay_internal, then p= repare_menu_bars, then
>=C2=A0 =C2=A0 =C2=A0> grow_mini_window, then update_frame.
>
>=C2=A0 =C2=A0 =C2=A0But grow_mini_window only recomputes the start of t= he window, it does
>=C2=A0 =C2=A0 =C2=A0not redisplay it. The next cycle will.
>
> The one I call "the current cycle"?

I meant the one we both call "the next".=C2=A0

On furth= er thought, it's
possible that the current cycle will do that, at least in some
situations.

Yes, precisely, that's what= I'm seeing! I believe that to be a very common situation, when the min= ibuffer grows because the user entered more characters than fit in a single= line.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0The function update_frame only reflects on the glas= s what its
>=C2=A0 =C2=A0 =C2=A0redisplay cycle computed to be the desired display.= If redisplay
>=C2=A0 =C2=A0 =C2=A0didn't recompute the window contents, update_fr= ame will change
>=C2=A0 =C2=A0 =C2=A0nothing.
>
> 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 i= t wrong):
When update_frame returns, it's possible that i= t has made Xlib calls to change the screen content but that Xlib has not ye= t 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 ha= ppen.

IOW, there are several ideas of what the screen loo= ks like:
=C2=A01. the glyph matrix etc.
=C2=A02= . what Xlib has been told the screen should look like
=C2=A03= . what the screen actually looks like.

update_frame synch= ronizes (2) with (1). x_sync synchronizes (3) with (2).

In all= the cases that I did look at in gdb, update_frame actually did make change= s to (2), but did not synchronize them with (3), so it was important for me= to call x_sync in order to avoid falsely concluding that update_frame hadn= 't performed the update when, in fact, it had.

When redisplay decides nothing needs to be= recomputed, the current and
the desired contents will be identical.

Do you think this is actually happening in our test situation? I think it&= #39;s another marginal 1% case that we can drop.

> 1. user input
> 2. redisplay called

That is inaccurate.

I did not mean t= o imply that list was complete, just that it was a description of the typic= al 99% case when the minibuffer is resized because the user put in a charac= ter.
=C2=A0
Emacs returns to the
main loop after processing some command, which could be triggered by
user input, or by input from a subprocess, or by some timer that
became ripe, or by input from D-bus, or from any number of additional
input sources.

But we just agreed to dr= op such marginal cases.

I omitted some steps. = How about (again, this is a description of the typical case that I'm ac= tually seeing here):
1. user input
2. command l= oop handles user input
3. command loop calls redisplay
4. prepare_menu_bars called
5. pre-redisplay-functio= n 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_fra= me based on the new window sizes
9. update_frame is called, w= rites 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 calle= d
14. window-size-change-functions not called on unmodified E= macs, called with my initial suggested patch.

> But there's no guarantee that there won't be intermediate comm= ands 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.

(With the new numbering, it would mean moving step 5 to hap= pen between step 7 and step 8, or installing a new hook there).

Are you suggesting a hook between steps 8 and 9? I think that's = not a single position in the C code, but it would be the perfect solution.<= /div>
--047d7b874bbe8f4889051e5e4f22-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 08:46:58 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 12:46:58 +0000 Received: from localhost ([127.0.0.1]:40885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJ3Z-0008NT-Uk for submit@debbugs.gnu.org; Fri, 28 Aug 2015 08:46:58 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:54460) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJ3X-0008NK-6J for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 08:46:56 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NTS00700M5WUU00@a-mtaout22.012.net.il> for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 15:46:45 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTS007XFM5XPZ30@a-mtaout22.012.net.il>; Fri, 28 Aug 2015 15:46:45 +0300 (IDT) Date: Fri, 28 Aug 2015 15:46:48 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: <55E03D30.4060908@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83bndr4m2v.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> <55DF4FCD.9000104@gmx.at> <83zj1c4lv0.fsf@gnu.org> <83wpwg4kvv.fsf@gnu.org> <55E01609.2090102@gmx.at> <83mvxb4x6b.fsf@gnu.org> <55E03D30.4060908@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 28 Aug 2015 12:51:28 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org > > >> > That was confusing. Let me rephrase: Emacs only reads subprocess > >> > input or runs timers when it's idle, so these events are only possible > >> > after some command finishes, and Emacs gets back to its command loop. > >> > >> Obviously. My point was that ‘post-command-hook’ won't catch these. > > > > Are you sure you aren't making some incorrect assumptions about the > > exact place where the command loop calls post-command-hook? What if > > it is called immediately after processing the above events? > > I don't understand. We don't call ‘post-command-hook’ when resizing a > window gets triggered by a timer. Can you show me some Lisp which causes this? I'd like to see what am I missing here. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 09:05:47 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 13:05:47 +0000 Received: from localhost ([127.0.0.1]:40889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJLm-0000Lr-S9 for submit@debbugs.gnu.org; Fri, 28 Aug 2015 09:05:47 -0400 Received: from mout.gmx.net ([212.227.17.22]:49840) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJLl-0000Lj-AB for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 09:05:46 -0400 Received: from [188.22.234.198] ([188.22.234.198]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MJFBe-1ZY3RC0Iqg-002p4D; Fri, 28 Aug 2015 15:05:44 +0200 Message-ID: <55E05C9F.80508@gmx.at> Date: Fri, 28 Aug 2015 15:05:35 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <83mvxe5af9.fsf@gnu.org> <55DEC310.5050408@gmx.at> <83d1y869gh.fsf@gnu.org> <55DF4FCD.9000104@gmx.at> <83zj1c4lv0.fsf@gnu.org> <83wpwg4kvv.fsf@gnu.org> <55E01609.2090102@gmx.at> <83mvxb4x6b.fsf@gnu.org> <55E03D30.4060908@gmx.at> <83bndr4m2v.fsf@gnu.org> In-Reply-To: <83bndr4m2v.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:HzqEzJrV08duF+QxrrMS8Q5MHxp8ukx41klNXiDcQpbBCJwHiQG 0WKeUNyUnu0N2GLH1QwgXO/OzZozp5SnP5SkGoPRbOG9/M2YaSDxlgUKAIKPCqotWWIt7/J DkeFdMYfR9Ma9sKXArPYZgchbQpR/ctPadr+S7x+hRld5zef9p9sDxob3/+I9IHrEvENecG BAmR+96BWz7fBP1xE3oNw== X-UI-Out-Filterresults: notjunk:1;V01:K0:BgKuBcKuWiA=:2DpaZ3EAnVbbOo+8oP2yGK ZlJXFxuJyeKTNbWFYo/iSv/Iggxd1A46dYPreq4Z5Ew0tIwYVnVPHNqWA8fcn65NYiPMaRn2U 1TvnUkjdUMn+sd+y2GOTwSaCtvsp/bj90gLgetcGRqR6M/vSP2ECNP56ehWPEqhfHSGfUyB9n vWcvp4lgJGFjkVzWxj72WEX6rLITCSvGfxMqxggfZ54miWpEV9dqkA5cCI0gIMhYtNNyBZwsu qOqnCFoJ2e7wWhcG5NEelG/f5zlGrNKDHn06ZkdGDSD6JdcadJ7qeM+NQP+tUeXknQCcQWXhB UF+LzF2uZ1jQXXmm24dZfyVzpwf21v0PYM9P79heDF99YHs+cYhzF50HYAe82tat5RodK1Q8y bJ9iaJD/X3RvWaVIUHal01/KdttjuTbkm0I3ZvYdtxuFlIRO9fgV7K3RVEUbe/6PEcbulxwTF YmwuK9G9F2/4deYJRmGm4TrDg3zKzkmpDyuTp6JxbUwowBRpo0yIzNzXs1/S+u+hCo+fwceLF UV0q33if6IcBfndQeNtygTgJHhE00Zjtp8P+eoy9RMJEQX1TtzuqLWl00TvIlx/hNuO+6tseZ 8G4fLi+16VUqNJYwQEyQ6vGmbWp94VFT7Lj+i8vpIFkRiKMYzn6Tqkuzwja97dlfgK+qIlisY loryFsFozhm7wB1dTWrvmjHiC76Ux/yKGeQ3JZM/B9bQFPlDNl8Ov9WQYHcnrFft3pR7HGrm4 +Lt5tNx+8npwBM3kCqeMLM+RM8u7morGrJJO2g== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> I don't understand. We don't call =E2=80=98post-command-hook=E2=80=99= when resizing a >> window gets triggered by a timer. > > Can you show me some Lisp which causes this? I'd like to see what am > I missing here. I'm not sure what you mean but put the following snippet into your *scratch* with emacs -Q and =E2=80=98eval-buffer=E2=80=99. (defvar timer nil) (defvar foo 0) (defvar bar 0) (defun foo () "..." (setq foo (1+ foo)) (if (>=3D (length (window-list)) 2) (delete-other-windows) (split-window)) (when (timerp timer) (cancel-timer timer)) (setq timer (run-with-idle-timer (time-add (current-idle-time) 2) t 'foo)) (message "foo: %s ... %s" foo bar)) (defun bar () "..." (setq bar (1+ bar)) (message "bar: %s ... %s" foo bar)) (setq timer (run-with-idle-timer 2 t 'foo)) (add-hook 'post-command-hook 'bar) You will see that eventually only foo increases while bar remains fixed. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 09:13:48 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 13:13:48 +0000 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 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 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) 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) Date: Fri, 28 Aug 2015 16:13:44 +0300 From: Eli Zaretskii Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet 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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 09:26:33 2015 Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 13:26:33 +0000 Received: from localhost ([127.0.0.1]:40897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJfs-0000qH-HA for submit@debbugs.gnu.org; Fri, 28 Aug 2015 09:26:33 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:33012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJfp-0000q8-FS for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 09:26:30 -0400 Received: by iods203 with SMTP id s203so92603950iod.0 for <21333@debbugs.gnu.org>; Fri, 28 Aug 2015 06:26:28 -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=+D74bKvQ+P02p0ATMiZDL1jo5nCkGv7h6ap11UmVBYE=; b=BQeMHz1u0d7zyEDbRAfbQG1Hk69a5jxeAfyfzW9sjxVmwMXClLSN0XFkQXwaJBTVNm e9sqiN2c0V1XA+nyu3QqJl4U7B2ccBSe1Idj9FBB0WtL+cKpj+x9/l1jIF/CJFt3Ar57 kgoPFJK+eoGEN53yRWo790X55voy2aQufNqBXjjuIZqOmgUlSZ9swhPSCD+jQH6EQP4p rZyBc9tgXX8ocVySJKkyAjMvcHDQeS8yenWJqYol3Kht3kvTgkneLHttjIG+ifzME72i iN1nTCm4Vi/snewHdumk6dKzLjxEmyN5ju7CbY4HtmLcpwAyd2uGZP3vIIPEMhRBtNeb i95w== MIME-Version: 1.0 X-Received: by 10.107.132.139 with SMTP id o11mr13610972ioi.3.1440768388828; Fri, 28 Aug 2015 06:26:28 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Fri, 28 Aug 2015 06:26:28 -0700 (PDT) In-Reply-To: <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> <837fof4ktz.fsf@gnu.org> Date: Fri, 28 Aug 2015 13:26:28 +0000 Message-ID: Subject: Re: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113ed2f80514b7051e5f08d4 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113ed2f80514b7051e5f08d4 Content-Type: text/plain; charset=UTF-8 As I said, that would be the perfect solution! On Fri, Aug 28, 2015 at 1:13 PM, Eli Zaretskii wrote: > > 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? By actually looking at the screen to see what's on it. 1. set breakpoint in update_frame 2. "p x_sync($f)" (if necessary) 3. look at screen to see before-state 4. "finish" 5. "p x_sync($f)" 6. look at screen 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 can conclude that all parts that changed on the screen have been redrawn. You're right that I cannot conclude that the other parts have not been redrawn, so my method is of limited utility, but in this case, it works. I agree with everything else you said in the last email. Pip --001a113ed2f80514b7051e5f08d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I said, that would be the perfect solution!

On Fri, Aug 28, 2015 at 1= :13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.=C2=A0 But how does that let you know what update_frame<= br> actually did?=C2=A0

By actually looking at = the screen to see what's on it.

1. set bre= akpoint in update_frame
2. "p x_sync($f)" (if neces= sary)
3. look at screen to see before-state
4. = "finish"
5. "p x_sync($f)"
= 6. look at screen

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 can conclude = that all parts that changed on the screen have been redrawn. You're rig= ht that I cannot conclude that the other parts have not been redrawn, so my= method is of limited utility, but in this case, it works.

I agree with everything else you said in the last email.

Pip
--001a113ed2f80514b7051e5f08d4-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 09 16:41:31 2015 Received: (at control) by debbugs.gnu.org; 9 Nov 2015 21:41:31 +0000 Received: from localhost ([127.0.0.1]:59525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvuBu-0003nK-97 for submit@debbugs.gnu.org; Mon, 09 Nov 2015 16:41:30 -0500 Received: from eggs.gnu.org ([208.118.235.92]:50109) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvuBs-0003nA-4e for control@debbugs.gnu.org; Mon, 09 Nov 2015 16:41:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvuBr-0003oi-C8 for control@debbugs.gnu.org; Mon, 09 Nov 2015 16:41:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvuBr-0003oZ-93 for control@debbugs.gnu.org; Mon, 09 Nov 2015 16:41:27 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1ZvuBr-0000Z4-0Y for control@debbugs.gnu.org; Mon, 09 Nov 2015 16:41:27 -0500 Subject: control message for bug 21869 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Mon, 09 Nov 2015 16:41:27 -0500 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) merge 830 21869 From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 12:54:31 2015 Received: (at 21333) by debbugs.gnu.org; 17 Nov 2015 17:54:31 +0000 Received: from localhost ([127.0.0.1]:42002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZykSc-0006MG-MT for submit@debbugs.gnu.org; Tue, 17 Nov 2015 12:54:31 -0500 Received: from mail.muc.de ([193.149.48.3]:38255) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZykSZ-0006Lt-TW for 21333@debbugs.gnu.org; Tue, 17 Nov 2015 12:54:29 -0500 Received: (qmail 54928 invoked by uid 3782); 17 Nov 2015 17:54:26 -0000 Received: from acm.muc.de (p579E91A5.dip0.t-ipconnect.de [87.158.145.165]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 17 Nov 2015 18:54:25 +0100 Received: (qmail 5103 invoked by uid 1000); 17 Nov 2015 17:56:24 -0000 Date: Tue, 17 Nov 2015 17:56:23 +0000 To: 21869@debbugs.gnu.org Subject: Re: bug#21869: [Patch] Redisplay: after echo area diminishes in size, Follow Mode windows aren't resynchronised. Message-ID: <20151117175623.GA5077@acm.fritz.box> References: <20151109093546.GA2284@acm.fritz.box> <56406FA0.8090601@gmx.at> <20151109194200.GE2284@acm.fritz.box> <83egfynbgu.fsf@gnu.org> <20151116150357.GA7344@acm.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151116150357.GA7344@acm.fritz.box> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 21333 Cc: rudalics@gmx.at, Eli Zaretskii , pipcet@gmail.com, 21333@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On Mon, Nov 16, 2015 at 03:03:57PM +0000, Alan Mackenzie wrote: > On Mon, Nov 09, 2015 at 10:50:57PM +0200, Eli Zaretskii wrote: > > > Date: Mon, 9 Nov 2015 19:42:00 +0000 > > > From: Alan Mackenzie > > > Cc: 21869@debbugs.gnu.org, Pip Cet > > > > Probably bug#830 and bug#21333. > Quick summary of the bug: with Follow Mode active, with a multi-line > display in the echo area, do C-f. The echo area resizes to one line, > but the Follow Mode windows don't get resynchronised. > Quick summary of the cause: redisplay_internal calls prepare_menu_bars > (which invokes the window-size-change-functions hook) before it calls > echo_area_display (which resizes the echo area). Thus changes to the > echo area size aren't yet in place when window-size-change-functions is > invoked. > I propose the following strategy to fix the bug: > 1. Call resize_mini_window from redisplay_internal before the call to > prepare_menu_bars. > 2. Remove the call to resize_mini_window from display_echo_area_1, and > make that function of type void. > 3. Change the contract of echo_area_display, such that the echo area > must have been set to the correct height before calling it. > 4. Adapt message3_nolog (the only other function which calls > echo_area_display) to call resize_mini_window. > As a result of these changes, any change in the size of the echo area > would be taken into account when invoking window-size-change-functions. > An advantage of this change is that a recursive invocation of > redisplay_internal inside echo_area_display could be removed, improving > performance. No it couldn't. That invocation is not a recursive one, it's the main call of redisplay_internal for the message functions. Here is a patch implementing the above scheme. It should also fix bug#21333 (or, at least, go a long way towards fixing it): Invoke window-size-change-functions after changing echo area height. Fixes bug #21869 and probably bug #21333. Separate the resizing of the echo area from the displaying of text in it. This allows window-size-change-functions to be invoked after the former, but before the latter, according to its specification. src/xdisp.c (message3_nolog): Invoke resize_mini_window_1 before calling echo_area_display. (display_echo_area): Change type to (static) void. Change contract such that the echo area must have been resized, if nec., before calling, and that this function doesn't resize. (display_echo_area_1): Now always return false, since the function never resizes. (echo_area_display): Add extra parameter `window_height_changed_p', replacing a local of the same name. The function no longer resizes the echo area. (redisplay_internal): Invoke resize_mini_window_1 before calling prepare_menu_bars (which invokes window-size-change-functions). diff --git a/src/xdisp.c b/src/xdisp.c index 30dfac5..68e56b7 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -800,6 +800,9 @@ static int redisplay_mode_lines (Lisp_Object, bool); static void handle_line_prefix (struct it *); static void handle_stop_backwards (struct it *, ptrdiff_t); +static bool with_echo_area_buffer (struct window *, int, + bool (*)(ptrdiff_t, Lisp_Object), + ptrdiff_t, Lisp_Object); static void unwind_with_echo_area_buffer (Lisp_Object); static Lisp_Object with_echo_area_buffer_unwind_data (struct window *); static bool current_message_1 (ptrdiff_t, Lisp_Object); @@ -815,7 +818,7 @@ static void push_it (struct it *, struct text_pos *); static void iterate_out_of_display_property (struct it *); static void pop_it (struct it *); static void redisplay_internal (void); -static void echo_area_display (bool); +static void echo_area_display (bool, bool); static void redisplay_windows (Lisp_Object); static void redisplay_window (Lisp_Object, bool); static Lisp_Object redisplay_window_error (Lisp_Object); @@ -10234,8 +10237,10 @@ message3_nolog (Lisp_Object m) /* Get the frame containing the mini-buffer that the selected frame is using. */ Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf); + struct window *mw = XWINDOW (mini_window); Lisp_Object frame = XWINDOW (mini_window)->frame; struct frame *f = XFRAME (frame); + bool window_height_changed_p; if (FRAME_VISIBLE_P (sf) && !FRAME_VISIBLE_P (f)) Fmake_frame_visible (frame); @@ -10253,7 +10258,12 @@ message3_nolog (Lisp_Object m) clear_message (true, true); do_pending_window_change (false); - echo_area_display (true); + if (window_height_changed_p = + with_echo_area_buffer (mw, display_last_displayed_message_p, + resize_mini_window_1, + (intptr_t) mw, Qt)) + FRAME_WINDOW_SIZES_CHANGED (sf) = true; + echo_area_display (true, window_height_changed_p); do_pending_window_change (false); if (FRAME_TERMINAL (f)->frame_up_to_date_hook) (*FRAME_TERMINAL (f)->frame_up_to_date_hook) (f); @@ -10711,15 +10721,15 @@ setup_echo_area_for_printing (bool multibyte_p) } -/* Display an echo area message in window W. Value is true if W's - height is changed. If display_last_displayed_message_p, - display the message that was last displayed, otherwise - display the current message. */ +/* Display an echo area message in window W. If + display_last_displayed_message_p, display the message that was last + displayed, otherwise display the current message. The window + height of W must already have been set for the message. */ -static bool +static void display_echo_area (struct window *w) { - bool no_message_p, window_height_changed_p; + bool no_message_p; /* Temporarily disable garbage collections while displaying the echo area. This is done because a GC can print a message itself. @@ -10735,24 +10745,22 @@ display_echo_area (struct window *w) bool i = display_last_displayed_message_p; no_message_p = NILP (echo_area_buffer[i]); - window_height_changed_p - = with_echo_area_buffer (w, display_last_displayed_message_p, - display_echo_area_1, - (intptr_t) w, Qnil); + with_echo_area_buffer (w, display_last_displayed_message_p, + display_echo_area_1, + (intptr_t) w, Qnil); if (no_message_p) echo_area_buffer[i] = Qnil; unbind_to (count, Qnil); - return window_height_changed_p; } /* Helper for display_echo_area. Display the current buffer which contains the current echo area message in window W, a mini-window, - a pointer to which is passed in A1. A2..A4 are currently not used. - Change the height of W so that all of the message is displayed. - Value is true if height of W was changed. */ + a pointer to which is passed in A1. The height of W must already + have been set to the correct height for the message. Always + returns false. */ static bool display_echo_area_1 (ptrdiff_t a1, Lisp_Object a2) @@ -10767,11 +10775,6 @@ display_echo_area_1 (ptrdiff_t a1, Lisp_Object a2) here. */ forget_escape_and_glyphless_faces (); - /* Do this before displaying, so that we have a large enough glyph - matrix for the display. If we can't get enough space for the - whole text, display the last N lines. That works by setting w->start. */ - bool window_height_changed_p = resize_mini_window (w, false); - /* Use the starting position chosen by resize_mini_window. */ SET_TEXT_POS_FROM_MARKER (start, w->start); @@ -10780,7 +10783,7 @@ display_echo_area_1 (ptrdiff_t a1, Lisp_Object a2) XSETWINDOW (window, w); try_window (window, start, 0); - return window_height_changed_p; + return false; } @@ -11196,16 +11199,17 @@ clear_garbaged_frames (void) } -/* Redisplay the echo area of the selected frame. If UPDATE_FRAME_P, update - selected_frame. */ +/* Redisplay the echo area of the selected frame. If UPDATE_FRAME_P, + update selected_frame. WINDOW_HEIGHT_CHANGED_P states whether the + echo area's height has just been changed. It is ignored unless + UPDATE_FRAME_P is true. */ static void -echo_area_display (bool update_frame_p) +echo_area_display (bool update_frame_p, bool window_height_changed_p) { Lisp_Object mini_window; struct window *w; struct frame *f; - bool window_height_changed_p = false; struct frame *sf = SELECTED_FRAME (); mini_window = FRAME_MINIBUF_WINDOW (sf); @@ -11230,7 +11234,7 @@ echo_area_display (bool update_frame_p) if (!NILP (echo_area_buffer[0]) || minibuf_level == 0) { echo_area_window = mini_window; - window_height_changed_p = display_echo_area (w); + display_echo_area (w); w->must_be_updated_p = true; /* Update the display, unless called from redisplay_internal. @@ -13497,6 +13501,19 @@ redisplay_internal (void) /* Clear frames marked as garbaged. */ clear_garbaged_frames (); + /* Resize the echo area, if needed, before the invocation of + window-size-change-functions. */ + { + Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf); + struct window *mw = XWINDOW (mini_window); + + if (!MINI_WINDOW_P (XWINDOW (selected_window)) + && with_echo_area_buffer (mw, display_last_displayed_message_p, + resize_mini_window_1, + (intptr_t) mw, Qnil)) + FRAME_WINDOW_SIZES_CHANGED (sf) = true; + } + /* Build menubar and tool-bar items. */ if (NILP (Vmemory_full)) prepare_menu_bars (); @@ -13534,7 +13551,7 @@ redisplay_internal (void) echo-area doesn't show through. */ && !MINI_WINDOW_P (XWINDOW (selected_window)))) { - echo_area_display (false); + echo_area_display (false, false); if (message_cleared_p) update_miniwindow_p = true; -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 11:02:53 2015 Received: (at 21333-done) by debbugs.gnu.org; 21 Nov 2015 16:02:53 +0000 Received: from localhost ([127.0.0.1]:47217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Acn-0001M1-4f for submit@debbugs.gnu.org; Sat, 21 Nov 2015 11:02:53 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:42367) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Ack-0001Lo-Oe; Sat, 21 Nov 2015 11:02:51 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NY600K009WPI700@a-mtaout22.012.net.il>; Sat, 21 Nov 2015 18:02:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY600KPD9WOHJ00@a-mtaout22.012.net.il>; Sat, 21 Nov 2015 18:02:49 +0200 (IST) Date: Sat, 21 Nov 2015 18:02:39 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <20151121155658.GA3636@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: 21333-done@debbugs.gnu.org, 21869-done@debbugs.gnu.org Message-id: <83a8q749y8.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21333-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 21 Nov 2015 15:56:58 +0000 > Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net > From: Alan Mackenzie > > Hello, Eli. > > On Sat, Nov 21, 2015 at 01:35:02PM +0200, Eli Zaretskii wrote: > > > Date: Thu, 19 Nov 2015 18:03:39 +0200 > > > From: Eli Zaretskii > > > Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net > > > > > Date: Wed, 18 Nov 2015 23:23:04 +0000 > > > > Cc: martin rudalics , juri@linkov.net, andlind@gmail.com, > > > > 19576@debbugs.gnu.org > > > > From: Alan Mackenzie > > > > > > Could you try a simpler patch below? It seems to fix both your test > > > > > case and the one originally reported in bug#21333. > > > > > It does indeed fix my test case (I haven't tried it on #21333). However > > > > it violates the specification of window-size-change-functions, which > > > > says that the hook is called _before_ redisplay, not after it has > > > > started. I suppose one could argue over what "redisplay" means here, > > > > but intuitively I would say it is the putting of glyphs into matrices. > > > > "Redisplay" is indeed not defined well enough, but the only reasonable > > > interpretation of "before redisplay" is that it happens before the > > > call to redisplay_internal. And this is false for your suggested > > > solution as well. It is false even by your definition, because > > > prepare_menu_bars already manipulates the glyph matrices, the ones it > > > creates for the tool bar (and also menu bar on some display types). > > > And display_echo_area also manipulates glyph matrices (it calls > > > try_window). > > > > Which is only logical for an event that by itself is triggered as part > > > of redisplay! It's redisplay that decides to resize the mini-window, > > > so calling the hook after that decision _cannot_ possibly count as > > > being "before redisplay". > > > > IOW, once we, by popular demand, decided to call > > > window-size-change-functions when the mini-window is resized, we > > > invalidated that specification. All the other callers of this hook > > > are not part of a redisplay cycle, but this one is, and cannot be > > > anywhere else. > > > > So no matter what change we eventually install, the documentation of > > > the hook needs to be amended to say that it's called "before redisplay > > > or at the beginning of a redisplay cycle", and maybe also mention that > > > the second case is when the mini-window is resized. > > > No further comments, so I've committed the changes I posted here > > earlier. I also modified the documentation to be consistent with what > > the code does. > > Thanks. > > > Please tell me if this bug and bug#21333 could now be closed, or if > > there are any leftovers. > > I don't think this fix concerns #19576. The discussion of #21869 seems, > somehow, to have moved to here. > > But I think that #21333 can be closed, and #21869 certainly can be; both > of these were about window-size-change-functions not getting called for > echo area size changes. Closing. From unknown Thu Jun 19 14:03:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 20 Dec 2015 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator