From: Geoff Kuenning <geoff@cs.hmc.edu>
To: martin rudalics <rudalics@gmx.at>
Cc: 27923@debbugs.gnu.org
Subject: bug#27923: 24.3; -iconic switch screws up geometry
Date: Fri, 17 Nov 2017 00:59:34 -0800 [thread overview]
Message-ID: <pnishdd5lhl.fsf@bow.cs.hmc.edu> (raw)
In-Reply-To: <5A0EA33D.2080004@gmx.at> (martin rudalics's message of "Fri, 17 Nov 2017 09:52:13 +0100")
>> 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?
Yes, that's right. Whenever I refer to "works right" I mean that
if I launch with -iconic and then de-iconify, I get a window
that's the size I expect.
>> 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 didn't identify the source of the problem, but yes.
BTW, that email was a bit of a stream of consciousness: I was
typing it as I was doing experiments and being interrupted over
the course of a few hours.
>
>> 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?
Sorry, bad typing on my part. 35/34 was the height.
>> 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?
I'll give that a shot tomorrow.
>> 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.
It may not happen until the Christmas break, but I'm sure I can
manage to get the latest version installed. It would be wonderful
if the bug went away on its own!
--
Geoff Kuenning geoff@cs.hmc.edu
http://www.cs.hmc.edu/~geoff/
Substitute "damn" every time you're inclined to write "very;" your
editor will delete it and the writing will be just as it should
be.
-- Mark Twain
next prev parent reply other threads:[~2017-11-17 8:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 20:41 bug#27923: 24.3; -iconic switch screws up geometry Geoff Kuenning
2017-08-17 9:22 ` martin rudalics
[not found] ` <pniziawo843.fsf@bow.cs.hmc.edu>
2017-08-19 9:55 ` martin rudalics
2017-11-15 0:12 ` Geoff Kuenning
2017-11-16 9:04 ` martin rudalics
2017-11-16 9:13 ` Geoff Kuenning
2017-11-16 9:29 ` martin rudalics
2017-11-16 23:20 ` Geoff Kuenning
2017-11-17 8:53 ` martin rudalics
2017-11-16 23:16 ` Geoff Kuenning
2017-11-17 8:52 ` martin rudalics
2017-11-17 8:59 ` Geoff Kuenning [this message]
2017-11-17 9:23 ` martin rudalics
2017-11-17 9:31 ` Geoff Kuenning
2022-02-21 15:32 ` Lars Ingebrigtsen
2022-02-21 22:53 ` Geoff Kuenning
2022-02-22 1:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-22 13:24 ` Lars Ingebrigtsen
2022-02-23 9:28 ` martin rudalics
2022-02-23 22:17 ` Geoff Kuenning
2022-02-24 9:16 ` Lars Ingebrigtsen
2022-02-24 17:55 ` Geoff Kuenning
2022-02-24 18:07 ` Lars Ingebrigtsen
2022-02-24 9:19 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pnishdd5lhl.fsf@bow.cs.hmc.edu \
--to=geoff@cs.hmc.edu \
--cc=27923@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).