From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Emacs's set-frame-size can not work well with gnome-shell? Date: Tue, 28 Jan 2020 10:47:45 +0100 Message-ID: <728856fd-dab1-eade-54f5-6ba2c299373a@gmx.at> References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <0e41cd9e-8be3-f67a-6958-7bad38ee1266@gmx.at> <6c86c25b-22df-2b69-34fe-539605f624ba@yandex.ru> <7dd69fe5-4ef4-782c-2fba-031d475f6406@yandex.ru> <32fb4915-be55-f753-5f6c-423a09030fd6@gmx.at> <8b252ea4-5902-d21e-a0d7-cdb3ddbb4e08@yandex.ru> <39d47d8c.4bad.16fcd672191.Coremail.tumashu@163.com> <729d39eb-d0b4-2cc5-cac3-e129a3effa87@yandex.ru> <06c6b6fb-ce6f-456b-6a22-c5a26a0ab297@gmx.at> <50912835-37d2-f15b-8fd1-b6619893d1ce@yandex.ru> <4a424bf3-ee08-b114-73ef-287bde14003b@gmx.at> <5dd35cdd-2914-0b91-a6fd-e8764feecfb0@gmx.at> <9839e101-a25d-8875-4eee-2e6772249afe@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="90541"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Dmitry Gutov , tumashu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 28 10:54:13 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iwNZU-000NWC-7B for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jan 2020 10:54:12 +0100 Original-Received: from localhost ([::1]:56214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iwNZT-0006lG-4E for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Jan 2020 04:54:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37876) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iwNTN-0003gk-8P for emacs-devel@gnu.org; Tue, 28 Jan 2020 04:47:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iwNTM-0000jn-7z for emacs-devel@gnu.org; Tue, 28 Jan 2020 04:47:53 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:57703) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iwNTL-0000gF-Re for emacs-devel@gnu.org; Tue, 28 Jan 2020 04:47:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580204866; bh=HbUnSWg/4UjkiPDKFC0S7nIEilkB5UC+Yr3kjsOq+v8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=BlwnlyaBtGWdAy3myrGovHDjFvmYmw+BT/J3xD/P4B2AhQ3J6Q0qO67kvPJhEY8lc Q0cLYZ/g8kQsAmqhAXdTmJec7v9urZXLGGA1GbcvFBqv40dM5pB1hfsk8wYH0bcjDK LRo4wyuf1cIKp00UrIeKy5XvzOdkgJ4UO01kreWs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.90]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3lcJ-1ixCPx14vj-000uU4; Tue, 28 Jan 2020 10:47:46 +0100 In-Reply-To: <9839e101-a25d-8875-4eee-2e6772249afe@yandex.ru> Content-Language: en-US X-Provags-ID: V03:K1:ermfz9Z83YRxn/D/53+uBIJRNdd04fob/5d6jLVy6JdJxLMTh4G lqW1dVymOwWR66/+7wTY+UhURKc6H6sRzyKDBBniaSR6uwaLUfX0+C+q+dC91oLWqp7yrLA JlHd8ma3+COsj5sByT74sq4fIrYYIYc2xA2GE/FM0lIjqIvSGzYfHEmzRxnH741GaNNjdJF CGmci0oF4Iqyoy/iIanIA== X-UI-Out-Filterresults: notjunk:1;V03:K0:RFOhj6d6990=:x6RnmPAfK1k1Vf/4qUABv5 s0wWPY4/khaFUKJFA0iPAyTp2IGcjvSX++4VzSSEo2nyuDD1z8By33zCjDBKB2pNzGH5vCnoB w8Fz6rNuqXvRwh5+m0CCMBU0fm4t2SJm/B/Xn0mkxHxnYAgt1OOzFBua9ctw7KOAqamttIOzy KRGQl5n84asZrSDY4CpKxi4GPFQDBepcRnri3Km4F818SIWTvACivMXqhGrkuclOYch0MBHgJ CfT2o1pvMkRFNXdPZkx3lTal2wifxB7Iqy7TPU/8XVYpuFpOKpu3xu245Wjj9x4Fi0y1PChQd fL+FB0PZo5wJPgZDHoJedt9nopuxCKKw+YkHSsxZT4CJfKi5sm0evpVryXyQkCk0S1qaE7cYL ztz1+BVl3XdQR9tP+nwpkoM2JFVB4XhuOqIZFP1EwRHNkIYRkQAjdkvZfMGAVEI/wqBUkrByO tZ4aWrMa70VXnvLjN5ZZAAj6ZWn2Ll1QQSGGA6zF2KdCcHiSa42LCmMr7ZSB3Twgah509qomC 90eThRsi8aIsJ1ItyJKW3iQao+4CD2UFEtvhoYaIvwn0BX5y7xbMpluksZDgI5eKdKi8WDRrt kX65xuSy6wv/z/O3GY6KIWCkOgTEhYQ/lE54+Epzayhv2/MwTUrZbK6OCtujnSY7yaJH9+iGw ftljVPTdkmwBgUnLgB8bmgociTI/Ej2/JOdAOfBIL06InL988K3WIITNMA2oEafX4ud2v/yDc ZTmXEJ4M3GcCx7V8lizLGb8+eLaYecqiVTyrWKPSjbydgiKJR/duQgBE3ukd3JAeaicGakne X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244689 Archived-At: >> The reason for this (and I don't know if you've seen it as well) > > Not really. If I drag any border of a normal, decorated frame, the other borders stay where they were. Did you run this with a pristine, unpatched GTK+ build? Did you compare the outer right edges before and after the moves? Everything here is OK when running the 'bar' functions from a Lucid build, BTW. I suppose though that your Emacs' redraws too lag behind by showing either a gap between the right scroll bar and frame border when dragging to the left and not showing the scroll bar when dragging to the right? Here they do that even when dragging the left border with the WM alone. > I'm guessing that here, under Mutter, the window manager controls the > sizing and positioning when I'm doing this. And Emacs just handles > sizing notifications and redraws itself. So I've never seen this > particular issue act up in practice. Then it would ignore the Emacs sizing request even for a top-level frame something we hadn't that far. Unless your machine is so fast that you can handle all requests in "real time" so that you don't see the lags I mentioned above. > But your description sounds similar to my results in the previous experiment with non-decorated non-child frames. > >> The commands 'foo-' and 'foo+' drag the left border a 100 times to the >> right or left by three pixels in one step. The right border should >> remain unchanged. The commands 'bar-' and 'bar+' should do the same >> but, in fact, sometimes move the right border as well. > > Yes, I'm seeing exactly the same results with these commands (aside from the redisplay detail, which I haven't tried). You mean the right border never ever moves with the bar functions. Don't bother for the redisplay and sleep-for details then. We just see different bugs with different builds and WMs. Biodiversity at work. martin