From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs's set-frame-size can not work well with gnome-shell? Date: Mon, 27 Jan 2020 00:35:03 +0300 Message-ID: <9badd57f-5f63-7ee6-7ade-9ac473391527@yandex.ru> References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <437eae9b-ccc1-3875-86b7-1af0e61b6e15@gmx.at> <710da57c-28dc-fab7-81af-0318a9389d6a@yandex.ru> <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> <44e78be7-be8b-3756-805b-e1455516ef2c@gmx.at> <7f0ebc82.7f9.16fcf69ab7e.Coremail.tumashu@163.com> <7237c15a-8e6c-316d-8d0f-cf15a6c58d14@gmx.at> <619a81b3-d89e-dde0-0cbf-a42c45fcde03@yandex.ru> <93b0c6f4-74e5-854d-3bad-a0b994f83e89@yandex.ru> <8f8f03e2-39d3-af46-361d-2d5060d15217@gmx.at> <56e8b49f-bdb8-d97c-11ca-01612b5c7e5c@yandex.ru> <52546096-e66e-7851-d256-255f8374f3a6@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="81094"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: "emacs-devel@gnu.org" To: martin rudalics , tumashu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 26 22:35:41 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 1ivpZE-000L3u-WB for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Jan 2020 22:35:41 +0100 Original-Received: from localhost ([::1]:37266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivpZE-0001Vh-34 for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Jan 2020 16:35:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48733) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivpYi-00011C-Rq for emacs-devel@gnu.org; Sun, 26 Jan 2020 16:35:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ivpYh-0003Tu-Lj for emacs-devel@gnu.org; Sun, 26 Jan 2020 16:35:08 -0500 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:41241) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ivpYh-0003T4-Bn for emacs-devel@gnu.org; Sun, 26 Jan 2020 16:35:07 -0500 Original-Received: by mail-lj1-x232.google.com with SMTP id h23so8642751ljc.8 for ; Sun, 26 Jan 2020 13:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XOdWPdHEczOioRoaVoWX5K4Rvs2IRepsullV5wgXB/c=; b=m58BvIH7ksZjuwubU/cuzmivzixhZj2DD/kSWUQ03J2Ls3zpIyqW21WSmKb6k70Zeu JLYDKtzars3qPmXmQr3RtJagEs/G4y67tztBHaCJJq/t4p4eYFgqVFQREUMu6A0MHiCa PmV8OfAbSa0XChh81Gx4ioC3b1PUdITK9cgbYcMtqbcc+P3IAmWFmDhj+AzG+MPblGBM cqEoTQAbyAa7wmzaT7uPNyyq7h4QMsTP4DM5jB/7kx9/LENV/2k42Ms9O2Kfm2TtdHkn JOsm3XWc9v8QxkvHNn9gqIkpS740li03ryq3wC1Z2vz1Ck39Gkc0yLHlUyefliUZCeEh TAfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XOdWPdHEczOioRoaVoWX5K4Rvs2IRepsullV5wgXB/c=; b=g49qoHy6XCIwlH5Vboo+xTG79mZamUdefEj1Y80ZC5JHlahhoHfUWvlXX2C77zgIuE Dy4wtmwdgYFSxFN3i0LwVmmJDHwQwbFc2wu1FbHFBvLnyJOMfTnarGIfRXVHePtFlrq/ PS5ZykLsqnoSSRmNNm0TgAhO6o1mO7jovkkFV71IX7Rycmj/cMHaI7KLloWdN0G998jh PYgh+u8YQc9nZ5op1S64MJF95AI8CA4VgBcidHcSDf+va1hq3SMmrvkYIxC6Ls2a4iNM zN6EaBghWxH74l7uJysvD2Tf1Ggbgb+dyylBxwdqkEF8Q8HvGkL7Ye5jzdqVrX4QTePA Imtg== X-Gm-Message-State: APjAAAXODUC2UfzEdahdSo/X+Z9GuGfIvcA1CgPAJQtcOki6YFBCgOR4 9QPNVkhuVFuCc2TcO6P9/shCHCc1yiw1Ew== X-Google-Smtp-Source: APXvYqyZXUOir0LD1D3QAoSEbwgPhaOa9HOVIvb3mSTeCKJFfcm8mB1y8FRVQC63aUzCf/ej1w1/Iw== X-Received: by 2002:a2e:7818:: with SMTP id t24mr8063959ljc.195.1580074505388; Sun, 26 Jan 2020 13:35:05 -0800 (PST) Original-Received: from [192.168.1.35] (87-100-236-223.bb.dnainternet.fi. [87.100.236.223]) by smtp.googlemail.com with ESMTPSA id a12sm7060624ljk.48.2020.01.26.13.35.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jan 2020 13:35:04 -0800 (PST) In-Reply-To: <52546096-e66e-7851-d256-255f8374f3a6@gmx.at> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::232 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:244664 Archived-At: On 26.01.2020 18:32, martin rudalics wrote: > > Okay. With xterm.diff applied it works like this: > > > > Breakpoint 1 is hit. I add breakpoint 2. Hit continue -> B 2 is hit. > > This is at least interesting so we could continue work from here.  IIUC > B 2 is hit but no resizing occurs.  Is that correct? Yes. > > Call resize-test again (target height is the same): B1 is hit, B2 is > not. > > OK per se, just that our frame does not have that height and we don't > know. Right. > > Change resize-test to call set-frame-height with a different HEIGHT > (e.g. 30). Call resize-test: B1 and B2 are both hit. > > > > Call resize-test again (however many times): only B1 is hit. > > OK, both.  Just that the frame still doesn't have that height.  Right? Yup. > > IOW, something somewhere remembers the last value we've set HEIGHT > to, and doesn't send any more configureEvent's for the same value. > > That something should be Emacs itself.  At the time adjust_frame_size is > called in say 'set-frame-height' it's not yet clear whether Emacs will > issue a resize request.  The resize request is issued in this block > >       if (FRAME_TERMINAL (f)->set_window_size_hook) >         FRAME_TERMINAL (f)->set_window_size_hook >       (f, 0, new_text_width, new_text_height, 1); >       f->resized_p = true; > > of adjust_frame_size so if you set B 1 there you will see whether Emacs > has decided that the request is necessary so it gets dispatched to the > various toolkit backends (or frontends depending on the way you look at > them).  Please try. AFAICT, the "if" predicate always returns true when resize-test is called: I set breakpoints on both the first and the second lines, and both of them are triggered when resize-test is called. Yet, the frame is not resized. > > The actual visible height of the child frame still doesn't change, > meanwhile. > > One thing that can be useful for further debugging: Put a background on > the child frame like this (which also disables some additional things). > > (defun open-test (buffer) >   (display-buffer-in-child-frame >    buffer '((child-frame-parameters >              . ((width . 10) >                 (height . 10) >                 (top . 50) >                 (left . 50) >         (undecorated . t) > ;;         (override-redirect . t) >         (inhibit-double-buffering . t) >         (background-color . "yellow") >         (minibuffer . nil) >         (tool-bar-lines . 0) >         (menu-bar-lines . 0) >         (vertical-scroll-bars . nil) >         (horizontal-scroll-bars . nil) >         (left-fringe . 0) >         (right-fringe . 0) >         (border-width . 0) >         (internal-border-width . 2) >         (drag-internal-border . t) >         (drag-with-mode-line . t) >                 ))))) > > The background color here is useful to discern window system operations > that apparently do clear parts of the screen in reaction to our requests > but do not send us the related ConfigureNotify message nor the messages > to re-expose the obscured parts of the parent frame. The child frame's background is now yellow. But I don't see anything else happen with it when I call resize-test. > And finally try the attached patch for GTK builds to resize frames > directly via gdk calls.  I doubt it changes anything but who knows. Alas, no change. With override-redirect uncommented -- too.