From unknown Sat Jun 21 03:28:02 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#52666 <52666@debbugs.gnu.org> To: bug#52666 <52666@debbugs.gnu.org> Subject: Status: 27.0.50; Unexpected mode line flickering when creating frames Reply-To: bug#52666 <52666@debbugs.gnu.org> Date: Sat, 21 Jun 2025 10:28:02 +0000 retitle 52666 27.0.50; Unexpected mode line flickering when creating frames reassign 52666 emacs submitter 52666 Markus Triska severity 52666 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 19 15:30:23 2021 Received: (at submit) by debbugs.gnu.org; 19 Dec 2021 20:30:23 +0000 Received: from localhost ([127.0.0.1]:48276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mz2p5-0005p1-H1 for submit@debbugs.gnu.org; Sun, 19 Dec 2021 15:30:23 -0500 Received: from lists.gnu.org ([209.51.188.17]:48918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mz2p3-0005ot-Rs for submit@debbugs.gnu.org; Sun, 19 Dec 2021 15:30:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36414) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mz2p3-00084p-Ii for bug-gnu-emacs@gnu.org; Sun, 19 Dec 2021 15:30:21 -0500 Received: from [78.47.144.35] (port=35612 helo=metalevel.at) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mz2p1-0003ex-Ml for bug-gnu-emacs@gnu.org; Sun, 19 Dec 2021 15:30:21 -0500 Received: from mts-Mac-mini.localdomain (localhost [127.0.0.1]) by metalevel.at (Postfix) with ESMTP id 207E19C73E for ; Sun, 19 Dec 2021 21:23:03 +0100 (CET) Received: by mts-Mac-mini.localdomain (Postfix, from userid 501) id 03F311A2376E; Sun, 19 Dec 2021 21:42:21 +0100 (CET) From: Markus Triska To: bug-gnu-emacs@gnu.org Subject: 27.0.50; Unexpected mode line flickering when creating frames Date: Sun, 19 Dec 2021 21:42:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 78.47.144.35 (failed) Received-SPF: none client-ip=78.47.144.35; envelope-from=triska@metalevel.at; helo=metalevel.at X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -3.3 (---) Dear all, to reproduce this issue, please put the following form in a new file flicker.el: (while t (let ((f (make-frame `((parent-frame . ,(selected-frame)) (left . 200) (top . 200))))) (set-frame-width f 200 nil t) (set-frame-height f 200 nil t) (sit-for 0.3) (delete-frame f))) and then invoke Emacs with: $ emacs -Q -l flicker.el The form repeatedly creates and destroys a child frame, offset 200 pixels both horizontally and vertically from the top left corner of the frame. Unexpectedly, the mode line flickers in many (though apparently not all) iterations, starting at 200 pixels horizontally from the left, even though the frame does not overlap the mode line in any way. Ideally, the creation of the frame should not have any visible effect on the mode line. Could the pleasant double buffering feature I have read about help to remove this flickering when creating child frames? Please let me know if you can reproduce the issue or need any further information. I can reproduce the flickering both on OSX and on Debian. Thank you a lot! Markus In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin18.0.0, X toolkit, Xaw scroll bars) of 2018-11-15 built on mts-mac Repository revision: b4eb908f858284a7962851fd99c94598f76afa6f Windowing system distributor 'The X.Org Foundation', version 11.0.11804000 System Description: Mac OS X 10.14.2 Configured using: 'configure --prefix=/opt/local --without-ns --without-dbus --without-gconf --without-libotf --without-m17n-flt --without-gpm --with-gnutls --with-xml2 --with-modules --infodir /opt/local/share/info/emacs --with-json --with-x-toolkit=lucid --without-xaw3d --without-imagemagick --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-lcms2 --without-rsvg --with-xft 'CFLAGS=-pipe -Os ... Configured features: XPM JPEG TIFF GIF PNG NOTIFY KQUEUE ACL GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON LCMS2 GMP From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 20 10:14:46 2021 Received: (at 52666) by debbugs.gnu.org; 20 Dec 2021 15:14:46 +0000 Received: from localhost ([127.0.0.1]:51034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzKNC-0000j6-1B for submit@debbugs.gnu.org; Mon, 20 Dec 2021 10:14:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzKN9-0000io-MF for 52666@debbugs.gnu.org; Mon, 20 Dec 2021 10:14:44 -0500 Received: from fencepost.gnu.org ([209.51.188.10]:51350) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKN3-0002mw-1V; Mon, 20 Dec 2021 10:14:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WO0I/emtbbpAT6sjG91p9tKgn6Ku6cY3MXJ6HuFl7As=; b=j+vE6x8qSkH/ Vso0dSBZqfIj6fQ8fONlogkXO2Bp8K3OHt8A1IYsa6SZh1qpaJ8I0S4TdTHvKa4ljnfSyP2OwJoCP Lbek0h7LhM98GqmaYjfiOaoqVBY+Ec7YL50Rshr29BvGujeFg7pi/8GOq9LgDQo9Y/N6T68aF0y/+ wAUktfJRIQXl3ObsGF/wG16K85DpVlVq/LJrGTigH5d1CvEFEUwJ3OQE5JwqkqUFV0Zio42juLwEv 2V63pcS2xSp05/VotK5c7+Ium0OTMPxksXbuT6aKC8QJ4q7/Q8ChgTtFQfI4Kfv9ShdP6TC2z5+Yq l5I9Mw3oRMd2qEz+NDE8sQ==; Received: from [87.69.77.57] (port=2322 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKJx-0006qG-I4; Mon, 20 Dec 2021 10:11:30 -0500 Date: Mon, 20 Dec 2021 17:11:22 +0200 Message-Id: <837dbz2twl.fsf@gnu.org> From: Eli Zaretskii To: Markus Triska , martin rudalics In-Reply-To: (message from Markus Triska on Sun, 19 Dec 2021 21:42:21 +0100) Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52666 Cc: 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -3.3 (---) > From: Markus Triska > Date: Sun, 19 Dec 2021 21:42:21 +0100 > > (while t > (let ((f (make-frame `((parent-frame . ,(selected-frame)) > (left . 200) > (top . 200))))) > (set-frame-width f 200 nil t) > (set-frame-height f 200 nil t) > (sit-for 0.3) > (delete-frame f))) > > and then invoke Emacs with: > > $ emacs -Q -l flicker.el > > The form repeatedly creates and destroys a child frame, offset 200 > pixels both horizontally and vertically from the top left corner of the > frame. > > Unexpectedly, the mode line flickers in many (though apparently not all) > iterations, starting at 200 pixels horizontally from the left, even > though the frame does not overlap the mode line in any way. I think the child frame is first placed in some location determined by the WM, and then moved to the place the code says. Martin, is that so? If I'm right, then the flickering of the parent frame is when the child frame intersects some of its elements. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 20 11:47:43 2021 Received: (at 52666) by debbugs.gnu.org; 20 Dec 2021 16:47:44 +0000 Received: from localhost ([127.0.0.1]:51272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzLp9-0005kt-GO for submit@debbugs.gnu.org; Mon, 20 Dec 2021 11:47:43 -0500 Received: from mout.gmx.net ([212.227.15.15]:52005) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzLp8-0005kU-0h for 52666@debbugs.gnu.org; Mon, 20 Dec 2021 11:47:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640018855; bh=zOp5O5sANC6XUAIEt7hv5eB/1sdV8RRFdeacA7rT5Hk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=l2IRzcfebZaibLAikKRAgJHDbcXV5MU0Zh7ehptJcPAwOqbdSqwmxz8OAibnNz3kP NK6rZ2t/6Er6ugZuhDJYqUDRwCONTd8h9dPSQD1Fk+tZAzMbFU6iDtN9+ujXl+3SyY CdfctCSzhJil4miWP6v+TuFw3M6Hc6D+CIX24YDc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.96.93]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MA7GS-1nAs8b0QBO-00BeA8; Mon, 20 Dec 2021 17:47:35 +0100 Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames To: Markus Triska , 52666@debbugs.gnu.org References: From: martin rudalics Message-ID: <0c04099a-02c7-6bf0-b2cf-492327a1582e@gmx.at> Date: Mon, 20 Dec 2021 10:18:48 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:No42W63h2UlSno9TTBN5oRPukefM9uBjBr2r0PKh4oXrt7bfrf3 jB4baefat0jYcwNo/aJG9h/tGHRErGuJumfuon9UkeQCZQl0sfuvmEFtb75rU6UyGxNFr29 Hkug6V30gDg0DerETk+yMThT2TzaCAM/T91D8bUsdo06Q4vPGXH1Zd3Hjf/j9NCNzQm3n9+ rK+1ZuhWddT2+YURFisQQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:dOvSsAW8OX0=:N/zaSObgseDK9Rl8aaJ2XF 6wlMWXQeVOO1YWN81saDsSl0IIuN3MffmbEWR2KiKiyaxG2fEYIVnijW1FvXqMhenoeVElHr6 jbscgNxDWi+vAIfShn9oGpJQHuDP6bI5rYcInAqIONt1KJCaAsPN1AKepZXzm+cyFgVjHwQO9 vemwsl4PDN0p4ZB4BYsNwZFHMjqCUVL3QT/VeVyi3BpW94eWxzkVqXnNmXugLMDrS6Yjz2pOu 0G9YaCLhSMPFuRQCkDA0ELdlNtu7q6TlkE3EBqI1q6fobJQfF29NjDg4JVsqZw4nDxcOuLJHX KFQVH3li4Thd2C1hKjG23utaEEswJmUPBWtafh+DBBMP0JnSw7un/tWnN4nHhm1+W+JLVHqRe oX38BIzrNLzwzY9uhUzKx8RB4pG27jAKp7o1FpIsQHQrDUOypo9UkUUbbOVengpBguwOxKOu6 E8fLZJWDEAzGdm1/x4M4LyqDmnCFkrLsgpQiPTcyMA5FeZbpb1fZdvlctwdVihESDY5KgPnFY XqGErsaYGBp6d3mZOpANC6U3D3kUTq36cgCWJOIp1gz7HMxNSD9JlJvaKnRWwaz9FRRxnDgFD IDEjAbZHA0D0nDporHqKn/P2BE0Ovh4249fwA4OD3UH0gxV1AfxOSxLafhHXrUkXPgOmiXdEy 8IGVRyv4Zxz4Hhbg57A1wYiyYQ5nZI8xS4Xgvx/Chun7kazdHP0DH/g89p1dPbeaksQTzOUQP nM5a8xyD+979rLbiUY45fIGxwazZ+rxkfmZSN+wcXOYbZxEB+/BNw4FZ6RlbZp0oFqEKxiAGv BSzMYs/7xOc+BJ5ZvucLKNi4LatnxbVfE5zkp2T3viWdCkmRA+71mm8d1BnUqaY8M1/0CwNwN WpOntEdvrmuS6hlNM9c4Iv5Mrvl307cj+nNiogpoQ4EJ9Qim+02rj//xlezoH9IzDumfMxvS/ WEFaNPMXyxVJZAXjs1N3CuxCkDu0ZQth+WaPrGEmfHfRa4S1v6BSPm/VGqAXRIN0CJbtFkbGl 30wpL/IolUMkD4IvH5L5Ae3gK96BNZ/hWZfhjABdGWTAwc4BpRlU3lcDIkLatKBFm025HyTZr l0k5SHO0ctGTtk= X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 52666 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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 (/) > to reproduce this issue, please put the following form in a new file > flicker.el: > > (while t > (let ((f (make-frame `((parent-frame . ,(selected-frame)) > (left . 200) > (top . 200))))) > (set-frame-width f 200 nil t) > (set-frame-height f 200 nil t) > (sit-for 0.3) > (delete-frame f))) > > and then invoke Emacs with: > > $ emacs -Q -l flicker.el > > The form repeatedly creates and destroys a child frame, offset 200 > pixels both horizontally and vertically from the top left corner of the > frame. > > Unexpectedly, the mode line flickers in many (though apparently not all) > iterations, starting at 200 pixels horizontally from the left, even > though the frame does not overlap the mode line in any way. > > Ideally, the creation of the frame should not have any visible effect on > the mode line. I can reproduce the flickering with a GTK build where the child frame never appears at all. I cannot reproduce it with a Lucid build where the child frame appears shortly and gets deleted as expected. In either case the mode line is redrawn because it changes from active to inactive and back. > Could the pleasant double buffering feature I have read about help to > remove this flickering when creating child frames? Please let me know if > you can reproduce the issue or need any further information. I can > reproduce the flickering both on OSX and on Debian. The (sit-for 0.3) might conflict with 'x-wait-for-event-timeout' so playing around with the latter could help. BTW is yours really a Lucid build on a Mac? martin From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 20 12:22:04 2021 Received: (at 52666) by debbugs.gnu.org; 20 Dec 2021 17:22:04 +0000 Received: from localhost ([127.0.0.1]:51345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzMMO-0006lq-AG for submit@debbugs.gnu.org; Mon, 20 Dec 2021 12:22:04 -0500 Received: from mout.gmx.net ([212.227.15.19]:36297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzMMJ-0006l9-B7 for 52666@debbugs.gnu.org; Mon, 20 Dec 2021 12:22:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640020912; bh=mClTYSCDrb9r2Z2ICTvr0cJN97V+2ZUP9f0CQTb+dLw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=jD5MI0AHIYzalvE7vMuLlBHqQ+QMyaiaPkS05AlXZjjKGNlsr1NgNRlzx+Dzpdfnb aACxBdEomJi4B2HoBcS8+fKRlXCUP6sr6cxT0GggzuELgodMlsB/SyBmfYOIrfYbkL 0P3twbwYgauovhbxbTnrJ0Mq0pW7XKqNn/K8qsGE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.96.93]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MVvL5-1mryNR27gj-00RqcW; Mon, 20 Dec 2021 18:21:52 +0100 Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames To: Eli Zaretskii , Markus Triska References: <837dbz2twl.fsf@gnu.org> From: martin rudalics Message-ID: <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> Date: Mon, 20 Dec 2021 18:21:50 +0100 MIME-Version: 1.0 In-Reply-To: <837dbz2twl.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:vDuzsqQuhFPBRnN58iJyExbT9ICWaJ5vQ6Oqwj6TqLm/9cJU6Hh 06dOKq1kBCN0hUOQMEQXhEuJ1i9bNttUUlCReFE6qnfdsFnGi2Ry8te+Q6dT/Y1qKhj3yxM k91YMz6IKMn1P8Sgy7Fqj0oDR5m5GbrUhLvN3Smvy9dmRY4jGNC9t4wl24E1fa71mogl58A 1jo4SU2TGKJbuWk0eI/Gw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:GbTEN1V7uxU=:jBx3M3veaQZiClpFN1pHuk WLTsby5kLjhCbv6pXIuzgi+d938rSOxNpP/UH4ln/RiJVsXpT6qIByhTsUnVxN5LHelzW9aTv VFDGPuE8JaIzt0cMtF/851f6hZj4MCVQSGw9Nz+S8+z0b2ZHW49IZKUfXYl9sKcLHrI42Jfwl PlPqb3FKCulQJrQU1DDKv4GtrgmrNIoyLbWhPyijcqJ0KjAw1JogDXvr2C5ooTElqec2PVnz/ KINyMIpewTuc5HpbQJvSd5F27jgsHFoQ+nrG400KADVPUJEtAMVsY22zis3ES1Qo/tiUQMldT sf5M4lMMLUoG6b6T3LPAJc6FIbkuc+D1+jKrPVQrkzquZB68FwyWVU2ZE/GRt7HwxIDHCjxYT okFFwgLf/TMJWVx/wxhRP8FpYjduzwWJSn8UZqntA7bLE/7WpiCN1rgyd6wvNjm57eOBtmLDC tbbK1dI15KNWG2x/mBnmcsc2CWNMx38RPEuWdvgCEMn83FT1Fp67ymaGJYO4iEdTo3ow+QKPM QVxubo5G0JgQc6+69Z++/r/+4nzLkk9MfHCVOVn0dVj9d1ehI+BrOd7dsI2guRNh454ikD6E+ ZHDPq2Is+a0oZ53Jz98d79G/0QxN5JUQshfqrdB+idu5bspICSSUD2o8J7ycHwVCp+ieaySIk dmah2TONVWdZHx0MI/+TjnL7ZyCHtXZEzZ9axOqgz0hSpKJB87zzmhiujOfIOlQnlKbEhWv9t q0muxW8zJwrK64hmgdpJp7/P6vVjCJHjJYO1A7VYSJn5kx5YoqM3k15s5YJ//CTYlItZOcG8z zHHl9OmAfDwTRiv06dBz856VjByJnuNev+PdhA7p/x44zy4rk4cC4eEsezTZjrvOvhZf4IM5F 8/HtHBPx6eALRU3s57edlcr1OId8WfO/KQXjNOsYEn+4p7uUlXxtCtNC1HbYQJKAG5Zz/H1AX 6fLbFgDozAxI2ipchGzSKVRH8HFhko3l3k+ZiJM1lcruE2uy/ntRUJ93bQ+lU0IkSDBKQ/0ca z2mK5kE1/R6ldUfsau6kvuE6igwKlwKzbqN7WC7gMTqQws4ii/SzzoFKVGi0tasKvWNcoEqzG h1b5ehFbB//dwA= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52666 Cc: 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -1.7 (-) > I think the child frame is first placed in some location determined by > the WM, and then moved to the place the code says. Martin, is that > so? Not really - the frame should be placed correctly from the outset. The code has two problems: Using 'set-frame-width' and 'set-frame-height' immediately after the frame has been created is bad karma and should be avoided at all costs. The right approach is (while t (let ((f (make-frame `((parent-frame . ,(selected-frame)) (left . 200) (top . 200) (width . 200) (height . 200))))) (sit-for 0.3) (delete-frame f))) > If I'm right, then the flickering of the parent frame is when the > child frame intersects some of its elements. This is the second problem: 200 x 200 is way too large for the parent frame so the WM has to clip the child frame and where it overlaps with the parent frame it probably induces some sort of expose event that eventually causes the flicker. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 20 13:23:28 2021 Received: (at 52666) by debbugs.gnu.org; 20 Dec 2021 18:23:28 +0000 Received: from localhost ([127.0.0.1]:51410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzNJn-0008Sn-SP for submit@debbugs.gnu.org; Mon, 20 Dec 2021 13:23:28 -0500 Received: from [78.47.144.35] (port=41080 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzNJk-0008Sd-CO for 52666@debbugs.gnu.org; Mon, 20 Dec 2021 13:23:26 -0500 Received: by metalevel.at (Postfix, from userid 1000) id C487C9C74E; Mon, 20 Dec 2021 19:23:22 +0100 (CET) From: Markus Triska To: martin rudalics Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> Date: Mon, 20 Dec 2021 19:23:22 +0100 In-Reply-To: <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> (martin rudalics's message of "Mon, 20 Dec 2021 18:21:50 +0100") Message-ID: <87wnjz6spx.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: martin rudalics writes: > immediately after the frame has been created is bad karma and should be > avoided at all costs. The right approach is > > (while t > (let ((f (make-frame `((parent-frame . ,(selected-frame)) > (left [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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.3 (/) martin rudalics writes: > immediately after the frame has been created is bad karma and should be > avoided at all costs. The right approach is > > (while t > (let ((f (make-frame `((parent-frame . ,(selected-frame)) > (left . 200) > (top . 200) > (width . 200) > (height . 200))))) This seems not equivalent to what I posted: In the original snippet, I set the width and height to 200 pixels, by specifying pixelwise as t. In contrast, this version now sets the width and height to 200 columns and rows, respectively, yielding a much larger frame. > This is the second problem: 200 x 200 is way too large for the parent > frame so the WM has to clip the child frame and where it overlaps with On my configuration, a frame of 200x200 pixels fits well within the parent frame at the given position, so this should not be a problem. You can evaluate the following form in isolation to see that the frame that is created with the original snippet fits within the parent frame: (let ((f (make-frame `((parent-frame . ,(selected-frame)) (left . 200) (top . 200))))) (set-frame-width f 200 nil t) (set-frame-height f 200 nil t)) If you execute it repeatedly, you will sometimes see the flickering in the mode line, and sometimes not. Putting this in a loop as in the original snippet lets you easily observe the flickering. Is there a way to set the pixelwise frame hight and width already when the frame is created? Thank you and all the best, Markus From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 20 13:30:49 2021 Received: (at 52666) by debbugs.gnu.org; 20 Dec 2021 18:30:49 +0000 Received: from localhost ([127.0.0.1]:51424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzNQv-0000EM-3p for submit@debbugs.gnu.org; Mon, 20 Dec 2021 13:30:49 -0500 Received: from mout.gmx.net ([212.227.15.19]:36933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzNQp-0000E3-KO for 52666@debbugs.gnu.org; Mon, 20 Dec 2021 13:30:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640025037; bh=lT8KxM5gVXLNgQEwzYjJDm++7nowG9pyU46J5moXMhw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=O0p8vT7zc0d2KUGfE16gPy85eMZdSi8iBKrzu9LHWb8XM19dda7NnhikXsF8lpSUv 0bXY17Th+qnbs7eRG3VxjHAer6mHSXRyEvWQb5DQqe9Qb17t+kWwQ11HchV5gyR5ZH ByZHvsSHzXRU09IoX5QS0JtZVFuuJMyGRzV9J1OQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.96.93]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbzyP-1mU9sQ0A9v-00dauO; Mon, 20 Dec 2021 19:30:37 +0100 Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames To: Markus Triska References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> From: martin rudalics Message-ID: <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> Date: Mon, 20 Dec 2021 19:30:34 +0100 MIME-Version: 1.0 In-Reply-To: <87wnjz6spx.fsf@metalevel.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:CpUG+Dt9Hc5jG7kY/xphKWT3f+gw/LdXU2Prvs2mAdXyRSskl2g nAX3mPM6dAC11xy47dCbxts5/NwzU39FCZ1/zYzXWm3MDf9M8Nz46PCTPqpjHeOjxS6ncY7 /Qzr0bo4tNFnPdYuUJJbKU/yikqlnlqX6rEL5Qw6EU5nKkv6TXLDE4Cn0ufs7JdKCoTbxbE eIYt3UEdejkie6G/gO/gw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:cPe+JVci9pg=:XU5XXpj3WpH3Eh2mZ1QGWj HjCfTPAxQjy+QXY5y+WiqDTDFvuXtYqekwZ2a7dp3bcgVjf8P3OzvagxueoXvYLKTOOxAxVdL dTn/pDqavcnwt3a67gBY8r8bGI9kr4ywmTW6zuNkdSNZG90pe8zJUWsWHO74j15bnD/EOqz0B w2P/dHYmf09MaYaQs0S3iB2D2W9Owr0WUfl3UMxqAgE8bMr+aCTo2zVyUg4iH43HDRqxYcIH9 FajfrQ3IYkJk8RTt0TFdB/O6hxA+QdhINZesvJdqa0wuvu5vyYA6LS+2xtCSB5SUZlnvcHOGC jq9FCFcJPha7gS89NpB88lakqtjUcFf3YxYUDrn8ijKCAhR/izUbo9MPkVYWRTO0pYDVTJ6SB hawQrvJMVEgqkmEHFCyXUnlBlrQD1UDUBGv4sLYspthCLFYkmSZ9ZuZn88yHVCbQtiAyVEZlJ T/KjApTvra02OxCyZwqhKPPcsvXT1gkIkXibhst9v3vpKZJ4F4eBL+LiA6HPk8/wihFXsIogH HoXiPML6Q5/aUaLESUjL/AaHdAzsUHWOce7igtP9iVuE7XUD7rlRbeButqFgmeqzCLG/tMmK4 iHZercw+XSPA0Zw150GYc6GSvGWEJY8MnekP3Koq/JRL9XS1j03E5kBjCm6LXRSx+EfmA0Khd 2pJE4jPUuub1guyeTLT8B3Q+JGiMzwk++joszGzgpxYy9VoaSHeh5sy+RqviLlIdu03aAa/5S jviv/cPAsERLD3ZnLulvBugSsbRo5byCRAErG9kEDIQcomygXogBKb/fFYyuKr8zoXMAp88yz Kohq7T6VHTfAiCrmCI67MCMt0p1JQYmtWlBYTdS0QA1nf1kkyMWlebhqjQgVgTS2Sa5tjlVkN R8VMzbsGWMMYorI6P4gSjmxCuMKAZ6oSAeuCM4R0NHGRVGvyAP23X1rVMY4q++p8CmclB/wnF p1OZuKXFTLcyFrrxhhnpZCkub8Vv1FFEAOXDhd6jQCCInRnP8AACSg90RK6aghJYTZH+Aw5qH ZKWAjRrk2cqS7kpFRj+1jB8BATHjRIpzLpnq/D3+/rzcolEkbCTZH6LeqPQmwp75MoO/5k1Pa 84QoYa0Enra4A8= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -1.7 (-) > Is there a way to set the pixelwise frame hight and width already when > the frame is created? Please try with (while t (let ((f (make-frame `((parent-frame . ,(selected-frame)) (left . 200) (top . 200) (width . (text-pixels . 200)) (height . (text-pixels . 200)))))) (sit-for 0.3) (delete-frame f))) martin From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 20 13:41:48 2021 Received: (at 52666) by debbugs.gnu.org; 20 Dec 2021 18:41:48 +0000 Received: from localhost ([127.0.0.1]:51441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzNbY-0000Vs-DV for submit@debbugs.gnu.org; Mon, 20 Dec 2021 13:41:48 -0500 Received: from [78.47.144.35] (port=41258 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzNbW-0000Vj-GG for 52666@debbugs.gnu.org; Mon, 20 Dec 2021 13:41:46 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 2FC6C9C74C; Mon, 20 Dec 2021 19:41:45 +0100 (CET) From: Markus Triska To: martin rudalics Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> Date: Mon, 20 Dec 2021 19:41:45 +0100 In-Reply-To: <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> (martin rudalics's message of "Mon, 20 Dec 2021 19:30:34 +0100") Message-ID: <87y24fdspi.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: martin rudalics writes: > Please try with > > (while t > (let ((f (make-frame `((parent-frame . ,(selected-frame)) > (left . 200) > (top . 200) > (width . (text-pixels . 200)) > (height . (text-pixels . 200)))))) > (sit-for [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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.3 (/) martin rudalics writes: > Please try with > > (while t > (let ((f (make-frame `((parent-frame . ,(selected-frame)) > (left . 200) > (top . 200) > (width . (text-pixels . 200)) > (height . (text-pixels . 200)))))) > (sit-for 0.3) > (delete-frame f))) That's perfect, thank you a lot for this! With this I get no mode line flickering at all, neither on OSX nor on Debian. Yes, I am always using the Lucid build in all platforms, also on OSX! Do you still observe the mode line flickering you mentioned in the Gtk build also with this version? If not, then this solves all issues I reported, thank you again! All the best, Markus From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 21 05:33:06 2021 Received: (at 52666) by debbugs.gnu.org; 21 Dec 2021 10:33:06 +0000 Received: from localhost ([127.0.0.1]:52453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzcSA-0006cI-Cj for submit@debbugs.gnu.org; Tue, 21 Dec 2021 05:33:06 -0500 Received: from mout.gmx.net ([212.227.17.21]:35199) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzcS5-0006bR-Mt for 52666@debbugs.gnu.org; Tue, 21 Dec 2021 05:33:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640082774; bh=ScEppJHe+7sf1TYxVDvEIDinvUnWRgeGZt5/Etcji2k=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ZRfFYmnH4lHzDAmKGOvfQX+9jFTcqUoWGrl14MQyE/0KBD72fgGdfMm/ktetVDY00 eXKqtVh9GtiJqph8BdE2s/mtlfi27tcTCv1rODAPahX1DxqZvoJn6F0SEL0YfM88vT 7PW05moamTQLYR4eUr26aOlztR6SCjdO/BpSWwF4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([213.142.96.105]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3UZG-1n0AgG25Ss-000cae; Tue, 21 Dec 2021 11:32:54 +0100 Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames To: Markus Triska References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> From: martin rudalics Message-ID: <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> Date: Tue, 21 Dec 2021 11:32:53 +0100 MIME-Version: 1.0 In-Reply-To: <87y24fdspi.fsf@metalevel.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:AlnztQONQXKWYZE7y9N9E68PXnvmlkf6/aVRy5LluQ6teEMwk1P 6lK0DpvFPg5ChP0avxVmtwF6TFuEM0kG9jadk7fuAnGZqdQOt02JH2Cy1ZOg0BOy07RwHnZ wvj70xQur2GkFGowhimevnNdH/FY+9pho0/w2s6c+TG9e8QcZD0V3yYA1W0ZwtBKJnmGfu5 3r2JYZ4rrzqaIQwIiyRQA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Ky4+IB1mlZA=:7M2JR+JgqCdJrg706hB/er 65DCl3CvpgGkLjHvfNgyhthum3ntt/nS7jOBlrcLJAuk0zMECMMLCjWSrawa/L8d8YAKGg8MH SlxXT/NXwYw6KxHEbExuLobIu6O5Lc6yYKZJhq8JiVf4yqdD++LnlAG6oNQhIaJRDbb7+xvzH oqLOp7UE8fGbXwQgRTiTK9dbOcyAFrcOftjy09lbQy7kJFtPQHYo1VW+DwGoNET3orrwtJwlH MdGdMFfLsOabwwk1qPJUwDBSyR/YmAeixTg4agVPQqsPdP7Y+gw8cj/V5z9jNNjT6OugpNQLg xbc/MZ9+b4AvK8TnYgDxPgX1U5Ltr8lz8fVpDe65A3zJXb162XmgnObj3pGNuQkEli/eeyDQ4 ckwK0ubZmj8m+dWAkvJN4/Pf3Jtltkr34r/Ykl7FXB/Ka9Dp37Yrwqx7Bq2Bv+IoPnaOuJAg2 CWjSGOa5n45jyz54SIE6OgmJ7uZSIQfvMC2DlCapifDzUvD5H3zcWH/muuAhulrGtLfj5Y9yq zM+OXrxnB78EO35sgfJJrrmKoF2VkiDN6wGMaq+Kup51rYio1SKpYJSmcF4QM3QhHIRoqeYEH 7HwAxHbEqTbHzefrFZGqShfREkHVjX+4ZWZbm9Y8wWM3sDTjDP+d8VLCS+qp3npyyvwZHB2IY PiHrI83LedsOsATs+6uOh+5YgOtiisQM1VypGhjh4XxGRr5NvvelCMjs2W1BQjNDwXz5wPmGY 4gu9fcdSLmQynkUnj1QqGfkXLd9UPcC5pehqsD8g0up30TsrTrFAPTi6BOfnhEns090lOwB56 01UWXIP50pkCizyD6vyYRZK2oi3DN8QkSgPePr4cvw/8IKPByNVqIxGJfu/UE/wdDZaRcEG7Y dwbDioWdqarrHi5ggJX6KcJQnVaT/E0JeQyF2roBc6zl0g/KlPO8nQG52ZAcNt2WfRKEzV2n1 waxBEncn1/C4WKiZT1hdq9SsrFBelvm3QMkzDSOoDxJA3b6Gwko4p2wcEyIPiLKD7H1B8+QbC S1pBXOVRluXSk5HBudPYcG2UH7ecHhcYGFmAJNefgJbHRVDu53VoEiDx013mMw5ih4cl+ALRk ewzbZR8EFnzSYY= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -1.0 (-) > Do you still observe the mode line flickering you mentioned in the Gtk > build also with this version? I later found out that with my GTK-3 build the child frame never became visible with your original recipe when I moved the mouse into the area reserved for it. Maybe this is related to my focus follows mouse settings maybe it's something else. I can explain the mode line flickering as follows: This (let ((f (make-frame `((parent-frame . ,(selected-frame)) (left . 200) (top . 200))))) creates a child frame at a 200 . 200 pixels offset from the top-left corner of the parent's native frame. Since the size of the child frame is by default that of its parent, the child frame will thus draw over the entire area of the parent frame (including mode line and scroll bars) to the right of and below that position. Next you do (set-frame-width f 200 nil t) which will expose the part of the parent frame to the right of a ~400 pixels X-position and then you do (set-frame-height f 200 nil t) which will expose the part of the parent frame below a ~400 pixels Y-position. With all possible delays involved when setting width and height ('x-wait-for-event-timeout' might come into play here too) such flickering should not come as a surprise here. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 21 15:44:48 2021 Received: (at 52666) by debbugs.gnu.org; 21 Dec 2021 20:44:48 +0000 Received: from localhost ([127.0.0.1]:55822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzm07-0002dW-QJ for submit@debbugs.gnu.org; Tue, 21 Dec 2021 15:44:47 -0500 Received: from [78.47.144.35] (port=59432 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzm04-0002dF-Pg for 52666@debbugs.gnu.org; Tue, 21 Dec 2021 15:44:46 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 5B0849C74E; Tue, 21 Dec 2021 21:44:43 +0100 (CET) From: Markus Triska To: martin rudalics Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> Date: Tue, 21 Dec 2021 21:44:43 +0100 In-Reply-To: <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> (martin rudalics's message of "Tue, 21 Dec 2021 11:32:53 +0100") Message-ID: <87o859vgas.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: martin rudalics writes: > I later found out that with my GTK-3 build the child frame never became > visible with your original recipe when I moved the mouse into the area > reserved for it. Maybe this is related to my focus [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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.3 (/) martin rudalics writes: > I later found out that with my GTK-3 build the child frame never became > visible with your original recipe when I moved the mouse into the area > reserved for it. Maybe this is related to my focus follows mouse > settings maybe it's something else. I also noticed this: When the mouse is in the area where the new frame arises, then the new frame is selected on all platforms I tried. I have set focus-follows-mouse to nil (the default). Ideally, I would like the existing frame to reliably retain the focus, and the new frame to not be selected when it is created. Is there any way to reliably ensure this? > corner of the parent's native frame. Since the size of the child frame > is by default that of its parent, the child frame will thus draw over > the entire area of the parent frame (including mode line and scroll I think this is the part that can be counterintuitive, since the Elisp documentation states: 39.2 Forcing Redisplay ====================== Emacs normally tries to redisplay the screen whenever it waits for input. In the example that exhibits the flickering, there is no waiting for input between the creation of the frame and the change of its width and height. Therefore, it is unexpected that the frame is drawn over the entire area of the parent frame. I expected it to be drawn only for the area it is configured, when Emacs waits for input. Thank you and all the best, Markus From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 22 04:23:08 2021 Received: (at 52666) by debbugs.gnu.org; 22 Dec 2021 09:23:08 +0000 Received: from localhost ([127.0.0.1]:56798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzxpz-0005ki-NG for submit@debbugs.gnu.org; Wed, 22 Dec 2021 04:23:07 -0500 Received: from mout.gmx.net ([212.227.15.18]:37175) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzxpx-0005jz-L4 for 52666@debbugs.gnu.org; Wed, 22 Dec 2021 04:23:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640164979; bh=HSkhajexnSa0ABFt7fqV0CsNNdUt0V6Sdr4JXlOxHdQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VV49P1q+0qxGJ0T1e6cNwcZEianLgJR8e/kglhVcwr8j4mnriUkG4va1/DXFgR2Uw hIEad06CGjkgvOEaCDTn2dzD5q/XO+J5ZLoNY+TL8aD6Yz87ViTrM9kMZULEHtqY0r SGTyymCwJ6NNafJAnw46T7bQ/bJ3dff8XYIuvCb0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([212.95.5.187]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGhuK-1nCasC39PO-00Dp3d; Wed, 22 Dec 2021 10:22:58 +0100 Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames To: Markus Triska References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> <87o859vgas.fsf@metalevel.at> From: martin rudalics Message-ID: <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> Date: Wed, 22 Dec 2021 10:22:57 +0100 MIME-Version: 1.0 In-Reply-To: <87o859vgas.fsf@metalevel.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:v+3PQxRI2oqIq4i38CUhdFr1ii0R9ZygpiVG8+UBIe7vLrlfzHG K4X/qFUIqX4N0LoMB3Po5ncItajcCwxfa5iluLaHntyEhZgIpEf29+KrSu9dK0wbFQlHcdB BCYk2bnoQlyR1Sm+NUmUcoHDsQc9GCwcXg5xeu3c6VPZpwOzsIwX4NKH95YFRnmUiOmkQtI kWnqLy+wD7oRL8rZckHGQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:O5B8H2Fjjf0=:egSMLqtgzCg/cB8WzrcgBe PB5ZXn9sHtLOYQ5fh4iCe3ErOTLID8Oo0pO6Ciyw9gyq3snueqwkWploOfgM+0UHRbLqDU0Fs Eflm/ZnoIOGvnGHQ+pNYHpTa6j47Q9uwfw/f5CnqlSD7X73qTydRHBmVF8fOcRNG5qYGqryVj UkMkrS03pUxbeHXS8BrSkCHC54Ep47owhTVkJlOMx7O5+lP4TBLkliFaoXz8X0Q9GsMWJI5D+ ipegcCrUppWzDK6KwrUYfGxurdbolQYHHnCa63ZXVdRQw8HOu1wyYgIBW9gYEF0XGq72pJ/fM QnxEqmN6LUFs88kcCSsvHsed1mU6B13MFxMTneq/EKdN1/7Eha3bB11xPOn/yX+NYfYB8F9JL pirm4uaznLE0FmD2rz4rBGFLThsbXrYIHKM/G4GaYL6xLWXY+ltm1QKOjtFJFvuyLsFqT8eId uN5BNHeU/lbAFXaAeR3bXsPd43YQcaFnB9izSBliJJUARyFDYM5n14TnuJQOesCa4pbDAiFla FO1EAAyflc5cI60OS4o8hrWAT0XCUFlxBoE3x4E94l2vJwi0hj+SOr9XTRTgxGLv6BuaNZrVd TbBNrLQ0vle+yFdCSalSKRjgEIUFJ6JQwgAHWMhw0az7TnsoytG7NDg/7C5PDR7i0tpV22wpZ Pn9IeCx7xVC3n9b34uMkGfFvpFQmWonknFTTm2zH4d4WOC5ezF0pBufJECXkspN866/wCERAA hRkNpgE1Ez4DuG+ISdKnBZA2phW05NW8o6XX5engMQw8klj7YGEG5p+nfqTXWMvMxIXKR3NxV mkzs53jWDN7caXKtorVoq6Wm2ZWtHgLIf8Ct/Etz1NcceyapVkGV2sUWdV9n+vHSOFgOgms5e DDCYhWi/8r4k27v8NTEFZ4Fkd+B9y2RyMeazerhGRwWcmcVmAKDwPuDqJ4PtlWDDM5jeJE2nC ajy4kB/wq4yEXSWQPn6oCWnBS/R6l9iPKM+HPGyMaOy3w/ep0uYJeU4F482kUIOcTE4cOHFvH Xlgdj/ZuImBHVpVJoHdiBbZs0P/N+Nud2js8K79iqFQysvuFiEZOh6agKDZRpa+IAYgC26twj r3FCEUeKuKHzH8= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -1.7 (-) > I also noticed this: When the mouse is in the area where the new frame > arises, then the new frame is selected on all platforms I tried. Are you sure that the new frame is _not_ selected when the mouse is _not_ in that area? > I have > set focus-follows-mouse to nil (the default). Ideally, I would like the > existing frame to reliably retain the focus, and the new frame to not be > selected when it is created. Is there any way to reliably ensure this? Not in my experience. Conceptually, it should be possible by setting the 'no-focus-on-map' or temporarily (that is until the frame has become visible) the 'no-accept-focus' window parameter but I haven't yet seen a WM strictly adhering to that discipline. It worked best on Windows XP. >> corner of the parent's native frame. Since the size of the child frame >> is by default that of its parent, the child frame will thus draw over >> the entire area of the parent frame (including mode line and scroll > > I think this is the part that can be counterintuitive, since the Elisp > documentation states: > > 39.2 Forcing Redisplay > ====================== > > Emacs normally tries to redisplay the screen whenever it waits for > input. > > In the example that exhibits the flickering, there is no waiting for > input between the creation of the frame and the change of its width and > height. Maybe that line is confusing. Emacs may have to redisplay whenever it receives a corresponding event (like Map, Visibility, Expose and Focus notifications). Waiting for user input is only a tangential aspect there. What that chapter tries to describe is that an application can try to force additional redisplays by using the means described there. Inhibiting redisplay (via setting 'inhibit-redisplay') is in general not supported and might have no effect either. > Therefore, it is unexpected that the frame is drawn over the > entire area of the parent frame. I expected it to be drawn only for the > area it is configured, when Emacs waits for input. Emacs does not necessarily "wait for input" in that case. Depending on the underlying windowing system it might rather wait for a MapNotify or ConfigureNotify event. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 22 08:37:23 2021 Received: (at 52666) by debbugs.gnu.org; 22 Dec 2021 13:37:23 +0000 Received: from localhost ([127.0.0.1]:57117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n01o3-0002ko-JX for submit@debbugs.gnu.org; Wed, 22 Dec 2021 08:37:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n01o2-0002kb-2a for 52666@debbugs.gnu.org; Wed, 22 Dec 2021 08:37:22 -0500 Received: from [2001:470:142:3::e] (port=38922 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n01nv-0001EJ-0b; Wed, 22 Dec 2021 08:37:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=j15YK4r8Z3Mz5+MhCEDwK8YOzKcpDMSUY8JRzeEVxlA=; b=RGKtk9RdqsNA ZybV1rpcHKt2uTvPTkv2U7JK/tHn7r23h1CenaqWGIZlKLPfhoBZWxG/YtqK5zH8UJyU+1KAFkhlX jXBOG4GxJ2anDPZAlpvwocRbnG+iHxbJA2t/SWy7V8vuGWvleGAKd2mAXRawK/h9bD/Q6cdJtxsW+ zeLieAN17IjuDMR5AvVMNdZ/sq7+J2A1TqsR4vraTGlDXqhiML0bxcoxBvmJBzkv7hg8IILfsWQnU zDDIbqmUv4LV5datMGXxndUK+oFK+yER/lgQ5tOIq2Lpps5xn9ay5njE0mm9AnTomp5sUKUy+ogmG 4ug2DiIYdHQm0mJ9ZFiADQ==; Received: from [87.69.77.57] (port=4522 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n01nu-0005Zk-UY; Wed, 22 Dec 2021 08:37:15 -0500 Date: Wed, 22 Dec 2021 15:37:17 +0200 Message-Id: <83ilvgyd4i.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> (message from martin rudalics on Wed, 22 Dec 2021 10:22:57 +0100) Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> <87o859vgas.fsf@metalevel.at> <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52666 Cc: triska@metalevel.at, 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -3.3 (---) > Cc: Eli Zaretskii , 52666@debbugs.gnu.org > From: martin rudalics > Date: Wed, 22 Dec 2021 10:22:57 +0100 > > > 39.2 Forcing Redisplay > > ====================== > > > > Emacs normally tries to redisplay the screen whenever it waits for > > input. > > > > In the example that exhibits the flickering, there is no waiting for > > input between the creation of the frame and the change of its width and > > height. > > Maybe that line is confusing. Not really. It says "normally", and that is accurate. There are other situations where Emacs does redisplay, either because some Lisp program forced it to do so, or for other reasons. The ELisp manual has limitations if treated as documentation of the Emacs internals -- that's not its purpose. > Emacs may have to redisplay whenever it > receives a corresponding event (like Map, Visibility, Expose and Focus > notifications). Waiting for user input is only a tangential aspect > there. Not entirely, or at least not always: Emacs ("normally") reads events when it waits for input. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 22 11:33:12 2021 Received: (at 52666) by debbugs.gnu.org; 22 Dec 2021 16:33:12 +0000 Received: from localhost ([127.0.0.1]:59600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n04YC-0001bj-CW for submit@debbugs.gnu.org; Wed, 22 Dec 2021 11:33:12 -0500 Received: from [78.47.144.35] (port=42068 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n04YB-0001bb-2f for 52666@debbugs.gnu.org; Wed, 22 Dec 2021 11:33:11 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 62CE29C74E; Wed, 22 Dec 2021 17:33:09 +0100 (CET) From: Markus Triska To: martin rudalics Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> <87o859vgas.fsf@metalevel.at> <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> Date: Wed, 22 Dec 2021 17:33:09 +0100 In-Reply-To: <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> (martin rudalics's message of "Wed, 22 Dec 2021 10:22:57 +0100") Message-ID: <87wnjwr456.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: martin rudalics writes: > Are you sure that the new frame is _not_ selected when the mouse is _not_ > in that area? Yes, the new frame is *not* selected in that case! I have constructed the following test case to reproduce this: Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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.3 (/) martin rudalics writes: > Are you sure that the new frame is _not_ selected when the mouse is _not_ > in that area? Yes, the new frame is *not* selected in that case! I have constructed the following test case to reproduce this: (let ((f (make-frame `((parent-frame . ,(selected-frame)) (left . 200) (width . (text-pixels . 200)) (height . (text-pixels . 200)) (top . 200))))) (eq f (selected-frame))) When I evaluate it, and the mouse is far away from the window, I get "nil" as the result, showing that f is not the selected frame. I get this with the Lucid build on OSX and Debian. In fact, also if the mouse is within the area where the new frame appears, I still get "nil", and the new frame is not selected: The existing frame remains the selected frame, independent of the position of the mouse. I previously thought that the new frame is selected, but that was apparently mistaken: It only appeared to be selected because when entering text, the new (smaller) frame also shows the new text, even though it is entered in the existing frame which is selected. For my specific use case, this behaviour is ideal: I would like to show information in a new frame, but not select the frame. I am surprised to hear that in your configuration, the new frame is indeed selected. Do you accordingly get t as the result of evaluating the above form? Thank you and all the best, Markus From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 23 09:46:18 2021 Received: (at 52666) by debbugs.gnu.org; 23 Dec 2021 14:46:18 +0000 Received: from localhost ([127.0.0.1]:60765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0PMI-0002rU-4n for submit@debbugs.gnu.org; Thu, 23 Dec 2021 09:46:18 -0500 Received: from mout.gmx.net ([212.227.15.18]:54753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0PME-0002rF-6p for 52666@debbugs.gnu.org; Thu, 23 Dec 2021 09:46:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640270767; bh=kZJMM2au1umbtAx+VjWH1DlxtaYd9EWs4SZmmJjIwXc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=OCsJ54LkwAoGsurAv+NbWC3Wi5QHO0l0tUOPOlu9siA9IPzYEu++2oF1GomcLN2FF RaSzWnNIHG64CQ6ZUItHb8k87Y3ZNDkc/69QpSJgEFe/hL6pUxpYV/gtotyOQFfr7t z1V8BwqcqdjXnytcrjz/CzpcADW/R7hUMnnqwd9A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([213.142.96.225]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M4s4r-1n08N604rX-0022tO; Thu, 23 Dec 2021 15:46:07 +0100 Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames To: Markus Triska References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> <87o859vgas.fsf@metalevel.at> <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> <87wnjwr456.fsf@metalevel.at> From: martin rudalics Message-ID: <258f5841-1b0c-f844-1b46-c8224190635c@gmx.at> Date: Thu, 23 Dec 2021 15:46:05 +0100 MIME-Version: 1.0 In-Reply-To: <87wnjwr456.fsf@metalevel.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:oMZZuU+aHC1GIetbyhCjH1KWSh0y+AlZjlFQIQyvF3BoCPLyTYw 6nDU2+3zYliXsl4i09NsnOnkwlXHNsy07LVgxaXjPMprG7iQgU6Cxej/k4AH5oukWZScuIG I9lFQ7lfWNrXNody+oiy78YHEbM4fHwvmnXvsV0o15WKPvByudSL4mYJeTfugBLuxn2ed89 tAuepyDqgM+68rUkYdB1g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:amlmxB2MQwo=:KGEzCF/127+YrtY8OaYp+h 1ihDKiiCnuWGjOLxBdS6pc0BnnCG0i2KOM7bAjxN8v10wjxMW468mnwhgHBe6SI4KecQibwOm 1CEJWT0V009GkvcEpII+RiF7RVFd6ZvBFohZCjqciBBfIhLoiSCArP90ixUVN3QcHkiNzsnj/ hGYowsCoFjiKG8eKzd+cQOLl4zxMRJJD55BOEt3OJ4gZ9chlinvYvSEyXqN5dH9cpC9PizD7/ qf67+OzaDc63q9VYaBSC6aQJN1T/6cmhRj/4+LYTaGXe96pqD0wjy4WSvO8wSWJpoHUUlCsgN ENFxxm2YxWdLCAloD3K9F2KbW3ZbvAQ0ADOqCWDJkMiPXZO3w0vWEiGRPGM+3bM/0rFHT3/iF CK8Z/b3WyPv1LYCIL/uXQL9UDi+C2kp6jEq/QyqPuWStfM+AT0Y4hw5Y21zbDiHuDVeU9jdGJ 8Md0vbaQpW5T8pCWYT+ttney4EFWv41HkgI+O4+dhgUWdGxF+6K6QA1zSuL07X1mpzSEYbfN/ cwLkMFJFghhY0jD9NqNAIFoK4ILXNYHGbM2EoSyEIBNjLdNku/XWVElRD8NPAgNLMQ+BDhNeL 0kHAcrXvASd4zzD8EoKTrC/OCKu/HJmhS/soclrDu1ot2/4HzLv9YZXRI5MFdrWbA0Y0WchR/ qMpORVGweaMmF5if/suAAUSjs5LluFTH/+gXIzL4Z125NroD224y+YJ4uwk3gg4Puee3zYVc7 kttR9dVHC6Y+qdLMNqqkQgVZZ7MhbY7pz7oEsIEpfTHyBKNllytjhU8+IhMJAxxpSCBVhxAv7 Cohets3Oaupk6JtyFALErvFtzbxPxsHFYk2F4lAhZrTS0PksRlhcqwn5XTO21qq7Esdj2UbSW at6GMMjhb1qs0fF3b1yMWkLks/4MPoiqAxxwLns/AjnpF2AuzfSfaeirGLyriJU0fe7yivYqL UaXhbZNWKURupmsAIGPBW5WQqdGmjbdh9IZIBfTgty9JAmW1jVfvoXlITBg2kTCeU55SDI5fs +O86TNz5p5rrP9BPB74r4/1TJSwqlJyDce8Nk0XTqyTQYQCJHU23G85lsdJ3L8ALI0FDCDRGb fgNxSd9QtuBAbo= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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: -1.7 (-) > For my specific use case, this behaviour is ideal: I would like to show > information in a new frame, but not select the frame. I am surprised to > hear that in your configuration, the new frame is indeed selected. Do > you accordingly get t as the result of evaluating the above form? No. I'm getting nil here too. And apparently the child frame gets selected if and only if I click into it. If all issues have been resolved, please close this bug. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 23 11:23:07 2021 Received: (at 52666) by debbugs.gnu.org; 23 Dec 2021 16:23:07 +0000 Received: from localhost ([127.0.0.1]:34698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0Qry-0005rN-Qe for submit@debbugs.gnu.org; Thu, 23 Dec 2021 11:23:06 -0500 Received: from [78.47.144.35] (port=54926 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0Qrx-0005rE-OP for 52666@debbugs.gnu.org; Thu, 23 Dec 2021 11:23:06 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 648CA9C74D; Thu, 23 Dec 2021 17:23:04 +0100 (CET) From: Markus Triska To: martin rudalics Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> <87o859vgas.fsf@metalevel.at> <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> <87wnjwr456.fsf@metalevel.at> <258f5841-1b0c-f844-1b46-c8224190635c@gmx.at> Date: Thu, 23 Dec 2021 17:23:04 +0100 In-Reply-To: <258f5841-1b0c-f844-1b46-c8224190635c@gmx.at> (martin rudalics's message of "Thu, 23 Dec 2021 15:46:05 +0100") Message-ID: <87bl17e1ef.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: martin rudalics writes: > No. I'm getting nil here too. And apparently the child frame gets > selected if and only if I click into it. Perfect, thank you a lot. Yes, please close this issue, it works perfectly now with the approach you showed! Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 52666 Cc: Eli Zaretskii , 52666@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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.3 (/) martin rudalics writes: > No. I'm getting nil here too. And apparently the child frame gets > selected if and only if I click into it. Perfect, thank you a lot. Yes, please close this issue, it works perfectly now with the approach you showed! Thank you and all the best, Markus From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 23 17:06:06 2021 Received: (at control) by debbugs.gnu.org; 23 Dec 2021 22:06:06 +0000 Received: from localhost ([127.0.0.1]:35066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0WDu-0008B3-P1 for submit@debbugs.gnu.org; Thu, 23 Dec 2021 17:06:06 -0500 Received: from [78.47.144.35] (port=34618 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0WDp-0008AX-SS for control@debbugs.gnu.org; Thu, 23 Dec 2021 17:06:05 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 449BA9C749; Thu, 23 Dec 2021 23:06:00 +0100 (CET) From: Markus Triska To: control@debbugs.gnu.org Subject: Re: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> <87o859vgas.fsf@metalevel.at> <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> <87wnjwr456.fsf@metalevel.at> <258f5841-1b0c-f844-1b46-c8224190635c@gmx.at> <87bl17e1ef.fsf@metalevel.at> Date: Thu, 23 Dec 2021 23:06:00 +0100 In-Reply-To: <87bl17e1ef.fsf@metalevel.at> (Markus Triska's message of "Thu, 23 Dec 2021 17:23:04 +0100") Message-ID: <87k0fvj7sn.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: close 52666 Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 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.3 (/) close 52666 From unknown Sat Jun 21 03:28:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 21 Jan 2022 12:24:08 +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