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#27923: 24.3; -iconic switch screws up geometry Date: Fri, 17 Nov 2017 09:52:13 +0100 Message-ID: <5A0EA33D.2080004@gmx.at> References: <5995604A.3050605@gmx.at> <59980B16.1020307@gmx.at> <5A0D54A1.3020307@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1510908792 17380 195.159.176.226 (17 Nov 2017 08:53:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Nov 2017 08:53:12 +0000 (UTC) Cc: 27923@debbugs.gnu.org To: Geoff Kuenning Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 17 09:53:08 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 1eFcOa-0004FY-15 for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Nov 2017 09:53:08 +0100 Original-Received: from localhost ([::1]:44487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFcOh-0001qc-EH for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Nov 2017 03:53:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFcOa-0001qV-T0 for bug-gnu-emacs@gnu.org; Fri, 17 Nov 2017 03:53:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFcOV-0001aX-V1 for bug-gnu-emacs@gnu.org; Fri, 17 Nov 2017 03:53:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35498) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eFcOV-0001a8-PP for bug-gnu-emacs@gnu.org; Fri, 17 Nov 2017 03:53:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eFcOV-0007K0-DE for bug-gnu-emacs@gnu.org; Fri, 17 Nov 2017 03:53:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Nov 2017 08:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27923 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27923-submit@debbugs.gnu.org id=B27923.151090874828099 (code B ref 27923); Fri, 17 Nov 2017 08:53:02 +0000 Original-Received: (at 27923) by debbugs.gnu.org; 17 Nov 2017 08:52:28 +0000 Original-Received: from localhost ([127.0.0.1]:44179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFcNv-0007J9-Ve for submit@debbugs.gnu.org; Fri, 17 Nov 2017 03:52:28 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:57966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFcNt-0007It-IJ for 27923@debbugs.gnu.org; Fri, 17 Nov 2017 03:52:26 -0500 Original-Received: from [192.168.1.100] ([46.125.250.116]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdEsh-1eX0Xc3DsJ-00IRRW; Fri, 17 Nov 2017 09:52:15 +0100 In-Reply-To: X-Provags-ID: V03:K0:pP8pM2IZmQD0oxQjz3/H9/nkeUY+dvOYI1tORtMvEqO5UqKEbXS 6UI1BTfagnZ7kZ5+jIF4w7saT3a3zgt1MvwMwS4k3dQ/xDJSJG4btCCXDWUdVlp+SlKkuJI a7RCzuDdIgn8I0AoSZkCfAe/HSyiES9X0bcXnyeKNsWwpKBlxjzoytlse2DaXuWmsuc+tOA mb8nb3wKmaCLSrOWfToTQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:3L2sAgrkHgU=:+NRzyOvoYkLwUX5BSgAKpt 7UMC7uWg5iHOpmUnQSf06Hl/ceuqFxx/2QbTmMglzAbGCryG0OFsH8SaTiEcrFReUzAKib9+g SDsxLVFtzPiOmZxiR6YqzWw3FT222exD9KW6NLNAIpOVYl8GUUYm0yrZyO9Zl2rUqN79Tr5bH HLE6hzZRt6drZ9Gnu+lFxlpns3qhKhDfkgKdQC/CwpMyxugxe6KpDTMLCwYFAVXmusccgUcel HK7QDuFcsRXFoGZUu9R/6nb9G/b5wzjME2TMrwjhjK0AzcZtWJ3WiyrHIOnlZGglFHeBLxgvk fWcdrooYoGqXc6J0MRF7SWP37zh6DOV1UrDQGwjwfriTQ/dM3914FVaE6c+8nE7rJeIQeukFH np67WTmFRqyiRU4fPWTg/9UX6sdNHaVQ4elmrkwX3vaUWS8U7b5tEYsVj+ViZXkjmbqI9WPqz V2As8Oq3HixLSLg3YKH5iLRMlAnUYCRlmHthh5vE6yvkJbgRf2AW8kgG9hrz3cdI9VliN1aDx +ml0JY7aX7q4E9AVh6NjDhi6UgrTLboFrqQz2P6XOyiYNbfGrpX8f87PBCXLgvcPfqf02Wjxg 88RermVcuwhG6+w4tGFUVUGBPwlfBEKMquerDgyPk5KVyp5rs1OzVEy2JzbU7OaHWZE0ro9n0 8kWGjP2mOdpBPVlqJnqFtydHbA/nyEmrGQcm80M/9VaGuCSIF2MGJ3fhvitj2E+D6Ftf5ACis i2lN9+JsIOazvb+TjZfORsLCzVADvO+LvuVtGss6HU0bfqbUlHZMiDS6Uaalk9DdtSocXbty 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:139989 Archived-At: > (frame-width) and (frame-height) give 80 and 78, respectively. And I > double-checked that xwininfo indeed says 79x77+100+0. (This is when > starting with -Q, --iconic, --geometry, --font, and my default > resources.) With Emacs you traditionally set (via 'set-frame-height' and 'set-frame-width') and retrieve (via 'frame-height' and 'frame-width') the size of a somehwat fictitious area which includes one scroll bar and fringes sometimes a toolbar and a menubar. With GTK builds, tool- and menubar are usually not counted so I don't understand the 78/77 difference in your case but the 80/79 difference should be explainable by the presence of a scrollbar. All values are rounded to the frame's default character size. Usually, comparing xwininfo output with what Emacs tells you is confusing at least. > If I grep all emacs-related resources from my xrdb file and reload it, > starting with the same command gives the same inconsistency between > frame-width/height and xwininfo. Perhaps the width issue is because > one character space is allocated to the scrollbar? I think so too. > But just to make sure we're talking about the same thing, in all of > these cases emacs is coming up with a correct window size after I > deiconify it. I'm not sure I understand the last sentence. Correct in the sense that the main window displays 80x78 characters? > Hmmm, though...I just discovered that "emacs -Q --iconic" produces a > different result: it creates an 80x35 frame (79x34 according to > xwininfo) even when my xrdb contains both an Emacs.geometry of > 80x78+100+0 and a slightly conflicting gnuemacs.geometry of > 80x78+1180+0. (I have no clue why I have both!) This implies that > there's something in my .emacs that's relevant. You mean there's something in your .emacs that gets you a different height: 80/79 without loading .emacs and 35/34 with loading .emacs? > I did some binary searching and narrowed it down to a relatively small > area. However, in the process I discovered that there must be a race, > because on a hunch I tried launching twice with no change in my > .emacs, and once was OK and once produced the narrow window. I'm confused now - is the 35/34 above the width or the height of the frame? > Anyway, I finally got down to the following two lines: > > (menu-bar-mode -1) > (set-default-font (x-get-resource "Font" "")) > With both of those present, I get the absurdly narrow frame. If I > remove the first, then I get a frame that's 38x78. If I leave the > first and remove the second, I get a teeny frame that's too small to > type in, but xwininfo reports it as 1x1 (so suppose emacs thinks it's > 2x2). And if I remove both, I get a properly sized frame. (This is > all with my xrdb restored, BTW.) Sounds weird. BTW what does evaluating (x-get-resource "Font" "") return? > But that's not the strangest part. I cut my .emacs down to JUST those > two lines, and things then worked fine. More testing eventually gave me > the following .emacs file (this is 100% of the contents): > > (if nil > (setq load-path (append > (mapcar > '(lambda (value) > (if (and (stringp value) > (not (string-match "^/usr/local/" value)) > (string-match "^/usr/" value)) > (replace-match "/usr/local/" t t value) > value)) > load-path) > load-path))) > (menu-bar-mode -1) > (set-default-font (x-get-resource "Font" "")) > > Obviously, the first bit of code doesn't get executed. But if I remove > it, launching in iconic mode works! Having it there makes stuff break. > > Note that the .emacs above is 532 bytes. Is there an ancient 512-byte > buffer somewhere? I tried replacing the "if nil" part with 512 > semicolons, but that didn't produce an error. We occasionally use(d) a 512 byte limit to search for the occurrence of something in a file but I see no connection to your case. > Color me confused... Maybe the best thing to do at this moment is that you try with a later version of Emacs, 25.3 at least. My GNU/Linux machine crashed a few years ago and I still did not restore my older Emacs versions including that of Emacs 24. Also, on Windows the --iconic switch did not even work with Emacs 24, so maybe in this area something has changed on GNU/Linux as well. If you upgrade, we could try to synchronize our observations better. Note that on GNU/Linux it's already an enormous pain to compare the behavior of the same version of Emacs under two different window managers. martin