From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#31745: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A?= bug#31745: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A=E5=9B=9E=E5=A4=8D=EF=BC=9ARe:_?= =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9Abug#31745:?= Frame's bug whenwindow-system Date: Fri, 29 Jun 2018 10:42:02 +0200 Message-ID: <5B35F0DA.108@gmx.at> References: <878t7pms1e.fsf@gmail.com> <87r2lho3cg.fsf@gmail.com> <5B2CB9B3.1000600@gmx.at> <87r2ky2852.fsf@gmail.com> <5B2E077E.7070907@gmx.at> <871scsr4bj.fsf@gmail.com> <5B34962C.6050408@gmx.at> <871scrpbap.fsf@gmail.com> <5B349D71.3090301@gmx.at> <87tvpnnuuw.fsf@gmail.com> <5B34D3B0.3060302@gmx.at> <87in63ateo.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1530261749 27456 195.159.176.226 (29 Jun 2018 08:42:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Jun 2018 08:42:29 +0000 (UTC) Cc: 31745@debbugs.gnu.org, =?UTF-8?Q?=E5=88=98=E5=8A=9B=E9=93=AD?= To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 29 10:42:25 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fYoz2-000728-K9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jun 2018 10:42:24 +0200 Original-Received: from localhost ([::1]:40647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYp1A-0007XK-1r for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jun 2018 04:44:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYozi-0006jx-2t for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2018 04:43:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYoze-00056R-4N for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2018 04:43:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59551) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fYozd-00056B-WE for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2018 04:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fYozd-0007qr-K1 for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2018 04:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Jun 2018 08:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31745 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31745-submit@debbugs.gnu.org id=B31745.153026173730118 (code B ref 31745); Fri, 29 Jun 2018 08:43:01 +0000 Original-Received: (at 31745) by debbugs.gnu.org; 29 Jun 2018 08:42:17 +0000 Original-Received: from localhost ([127.0.0.1]:39212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fYoyv-0007ph-Cf for submit@debbugs.gnu.org; Fri, 29 Jun 2018 04:42:17 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:59451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fYoyt-0007pS-53 for 31745@debbugs.gnu.org; Fri, 29 Jun 2018 04:42:15 -0400 Original-Received: from [192.168.1.101] ([213.162.73.36]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhwAY-1fvBN32jw2-00nAkQ; Fri, 29 Jun 2018 10:42:03 +0200 In-Reply-To: <87in63ateo.fsf@gmail.com> X-Provags-ID: V03:K1:55+ns2T/BCBUJTmOP7bETYLmg15NS9fD33TzUtTN2SwxePeFRXb LLbgdmZQrwIxLy/px8bvkvwHCwmPqrCMCtYqkMMWFzTWla+ALvNWJOPy8v0Non3X/Y7p20F 5YXKEw3mePe0U9KNK/mWGnMxfewRSomdH7v+0mRnbrdUQ+u9jhdKT49XqTwymRK9lCDR6QV EshzPQmBSabKZupIMY1XA== X-UI-Out-Filterresults: notjunk:1;V01:K0:SAFJm8rVW4g=:k09u/5zMUiBnGKaGSQ084b X7WC03NUCdnt3aExzyHAOtz9VuboNRh61qvGPzoN4m/J+QQTAt6CJWvAZXb3hpKUIb7UTvtBc hbNnIOoJULpnr62cIdE+DH8EVdeTtcIjTGccs+tLWcqZCObhWiyyh8hfDACSUeaSHQWdGJPA9 3oDbDfupt7mELZgYk44hSbFdcicxSc02u37/I+t09vJd6ltf+xlU7cS7pCW9DxskUuN1vTOeq r1aRHcuG6i2Y5JkLUDRc2sK/TaDuLcD3cUpySJ2UUiSGEqttRLeFqmSXSjLRCqQ97MaEzS1zb RvuhblFNWmh4N+eZbPJMKDUb0pCoORQa2p/1YtfuCIToKW7s/HRXqtWDk2a9agd/bRI8/6GjG JqSeTZNng324a39mpHJn4m/1j7aDpyGK6bktHpEcCwY4Fbgmw8rzjbLsLTRdVhRIXqM/Vupza LsTR3RqciQd1V+k79eRTjvA/W8KrOsboImS2VmiOPMgKp/o1FN8RJ+gFOc1wcQdZS6aAgt9/d DyD0E2512WQrRl5nQhXF6bwFCt2Ax4xcNpIGci1S2lyOQd1WQuMwgya9PhvJ1OtXmLxilCFBE YIFszMBAgibgY3o+RZhR7qijQtQZzdwAo/w+ZhjM6NVJjxbtH7gSCuvqoBu0obVU7DjhJ5ZcU Qb/ZJJb3ilyWutkIKoyrIr/sW6Upb070AeESsLOKTHqE5MVTzxaDEuO12mE8Hm9bo2PktZpSF gVpJxdtcobYGGMSIQJ+bzU6bjbhutFJVA6NdbeipWwjQBngQwOCXuB4bF0HUZYMChFq2A68N X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:147945 Archived-At: > 130x56 fits on my screen fine, so I=CA=BCm not sure that=CA=BCs what's= > happening. Once the initial frame has been created I can modify its > size without any problems. Maybe it does not fit with the initial window position chosen by the window manager. > That=CA=BCs not surprising to me, the issue > is somewhere during the setup of the initial frame. Window managers can be more picky to make sure a new frame fits on the screen. For an already existing frame they usually accept that it moves off-screen. Can you position any other application's first window off-screen? > You=CA=BCre right that the frame is not resized the way we requested, = but > it doesn=CA=BCt seem to be because GTK thinks it=CA=BCs too big, since= eg > > src/emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) = (width . 79) (height . 35)))" > > can result in emacs thinking the frame is *smaller* than what's > actually displayed, so the modeline is drawn too high, and the > minibuffer has empty lines drawn underneath it. Screenshot: If you continue to work with this frame without (implicitly) triggering a frame resize, does Emacs keep on thinking so forever? Does the buggy behavior trigger also when you do not set the 'left' and 'top' parameters, that is, if you purely resize the frame and not move it at the same time? If so, we maybe should try to use gdk_window_move_resize or whatever there is now. ISTR that I tried it once and it seemed to work but dropped the idea later because I had difficulties figuring out a suitable interface. Also, does setting 'x-gtk-use-window-move' change anything? It could conceptually, for GTK 3.18. martin