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#25380: 25.1; save-window-excursion problem in batch mode Date: Mon, 09 Jan 2017 17:19:29 +0100 Message-ID: <5873B811.4000404@gmx.at> References: <7qwpe5xusr.fsf@fencepost.gnu.org> <58735A58.80801@gmx.at> <83pojwi7qc.fsf@gnu.org> 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 1483978990 6711 195.159.176.226 (9 Jan 2017 16:23:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Jan 2017 16:23:10 +0000 (UTC) Cc: p.stephani2@gmail.com, 25380@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 09 17:23:06 2017 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 1cQcip-0000eD-9g for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Jan 2017 17:22:59 +0100 Original-Received: from localhost ([::1]:40933 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cQcit-0006fN-IK for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Jan 2017 11:23:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cQcg2-0004Bm-72 for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2017 11:20:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cQcfy-0001XN-6z for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2017 11:20:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60810) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cQcfy-0001X4-4W for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2017 11:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cQcfx-0007r7-SD for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2017 11:20:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Jan 2017 16:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25380 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25380-submit@debbugs.gnu.org id=B25380.148397878930175 (code B ref 25380); Mon, 09 Jan 2017 16:20:01 +0000 Original-Received: (at 25380) by debbugs.gnu.org; 9 Jan 2017 16:19:49 +0000 Original-Received: from localhost ([127.0.0.1]:47976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQcfj-0007qc-RQ for submit@debbugs.gnu.org; Mon, 09 Jan 2017 11:19:49 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:49992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQcfi-0007qP-UD for 25380@debbugs.gnu.org; Mon, 09 Jan 2017 11:19:47 -0500 Original-Received: from [192.168.1.100] ([212.95.7.106]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LeeNW-1cpBFm21S2-00qQeG; Mon, 09 Jan 2017 17:19:36 +0100 In-Reply-To: <83pojwi7qc.fsf@gnu.org> X-Provags-ID: V03:K0:jyV1zpdD7NucY5qeUcem3PNu4HEe8SXt2W4BynSIKiMG3F5UAar ONgD1ytSzujIgf/5FLT2mncoIyG6kprVqaZ7fSPpOHMyZEw94KUFJVa6ewJpHDUeqj2/Vcv o3ki2UxbOCXAOtQYDOnkQCq+Ng4h8Z/YJLMpfWpxSOHX4APcs/AAKRBnFtc0Pii2ccZKjrb PmL0kAe0mYw0qzMihX14Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:TfJ/EnUHuH8=:U6UWmigKfDg8mwPwHUv4Xn kgapX202Gg4neuqWfiS5ZR1aQ1Jt+82NGqrE261PZcbWZJ4cQjKiaJ0BvVkUtUb3lAoz91TGk IIarXgAwwgU18axUgDa/0M3jCD6dVAEdzUorm4bWVPDF9efz8Nq5XyZTMkR1TmWr1zWtgj9JS w1KRSh0b2sDZNh/vTY1AkrEDPZc5ppuazLyy085UUdElQpj1ISTXP5dJA8EFCEEWbvL9wWGQC sVRVtlLQmRxuiZobOfOEZoqSQ1/azEaII7ZXA24NqjyTAR64I8cwurwRn+DhAtfwbDmajloxR RCZPPSF64p7L7awsxKyaoXJZDfUq4eRkrpu61EFsQhI6kpbX3u+ORvRiCNnbSoaLE2VrjVfSA cj2dmhGCAYTbgdLBSOxxyNZkLZlAQVNcLyukMa1p9HhFLGXd6sVUieEZT+bu2UWJ/vV3pFO6e 1tLU5rOyJ2efCXrcE01mOEtor0YVVhATDQYXvWFU0tKrVEjTAriSGUdHMcvxeqp+rytKVMa9k oPTIIBvzTZ49JWAZ0tbeiQC/EeubD9Zuqd9DoIIBK8tISlE9QAS4mWmBnDQsCPgSUeXPMpzeK 60D/iUoRWuXcmldwA75vfTdrZ3SA4l6Ph/ZYAjMsIwtEM6Y4s1r2Cve6acELj2mBVUQG2znte QZeEi6wBez8Dfm1ahLI55cGKobQ0EAfoGuHI0M7eeoQwoxKIIGwOYq3ppUtRHMGoDa8Lfk71W UiWQ92KhvQLDAVI+JOveDWnUjM6VUb/0zRdYC1hHGTXvprbbr/4gH/wGX/Xmds8lWPfI5BPM 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:127934 Archived-At: >> IIUC the pixel comes from a menubar line which gets spuriously added.= > > I believe you are right, see the backtrace below from the place which > changes the value from 0 to 1 (it's not pixel units, btw, it's > character units, AFAIU). At the time the comparison fails in =E2=80=98compare-window-configuration= s=E2=80=99 it's at !EQ (sw1->pixel_top, sw2->pixel_top) so it's off by one pixel. It probably would fail later at !EQ (sw1->top_line, sw2->top_line) as well. > More accurately, the initial current-window-configuration call happens= > so early that the basic geometry of the "windows" is not yet set, and > in particular the menu bar is not yet computed and accounted for. > This is indeed where Emacs 25 behaves differently from previous > versions, and for a very good reason. Does the basic geometry of the "windows" ever get set? Would I have to create a frame manually for that? >> If someone told me how to debug this, I might be able to tell more. > > I just ran Emacs under a debugger with a breakpoint in > Fcurrent_window_configuration, then put a watchpoint on every top_line= > member of every window that got saved there, and waited for it to > break. That's obvious. But how do I find out where that menubar line gets set? >> I have no idea how the frame seen by =E2=80=98current-window-configur= ation=E2=80=99 >> gets created in batch mode. > > It comes from temacs, AFAIR. Hmm... the normal "F1" frame made by =E2=80=98make_initial_frame=E2=80=99= =2E Still: Who adds the menubar line? AFAIK neither NS nor GTK should. > I'm not actually certain we should try fixing this, unless Martin can > do that in some easy and safe way. The code involved in this is quite= > fragile, because Emacs creates its first frame without knowing > anything about its geometry and the window-system. That code took a > long time to get right on all systems; I'd hate to break it to cater > to (IMO) much less important use cases. I'd rather people wouldn't > count on anything related to "frames" and "windows" in the batch > session, except that they exist. (They must exist because some > functions will simply not work without a frame or a window.) So far I can't do anything here - this is code I cannot debug. At the time =E2=80=98compare-window-configurations=E2=80=99 gets called it's alr= eady much too late :-( > IOW, I think unit tests that must compare windows cannot be na=C3=AFve= ly > run in batch mode; you need to use tricks. For example: > > emacs -batch -eval "(progn (save-window-excursion (current-window-c= onfiguration)) (print (equal (save-window-excursion (current-window-confi= guration)) (current-window-configuration))))" =3D> t emacs -batch -eval "(progn (menu-bar-mode -1) (print (equal (save-window-= excursion (current-window-configuration)) (current-window-configuration))= ))" works here too. martin