From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 16923@debbugs.gnu.org
Subject: bug#16923: 24.3.50; reression: `set-frame-size' loses mode line
Date: Thu, 6 Mar 2014 10:25:30 -0800 (PST) [thread overview]
Message-ID: <8be91728-fcea-4e74-afff-db6a55b52985@default> (raw)
In-Reply-To: <5318AFD9.4000208@gmx.at>
> > I was pretty sure that the mode line also disappears in some cases
> > when moving to a different node. But I definitely do not see that
> > now, so I guess I was mistaken about that.
>
> (1) The mode line disappears only when the frame size remains the same.
> Check this please via the arguments you pass (to `set-frame-size' or
> whatever you use).
>
> (2) Everything else is drawn correctly, there's no area with background
> space only, as you claimed earlier.
>
> Is that correct (from your experience, so far)? You might want to
> attach a screenshot.
Yes, that is what I was saying. However, testing by printing the sizes
as messages shows that I was wrong (once again). The mode line can
disappear, it seems, either when the size is the same or when it
increases.
Here are some debug messages, where ====== means the size was not changed
and /////// means that it was changed. The old and new sizes are also
noted.
These resizings were not associated with losing the mode line:
CUR: (81 63)
NEW: (76 63)
//////////////////////
CUR: (76 61)
NEW: (81 63)
//////////////////////
These, immediately after those, were:
CUR: (81 61)
NEW: (81 63)
//////////////////////
CUR: (81 63)
NEW: (81 63)
====================
That is, the mode line was lost when the height changed from 61 to 63,
and it remained lost when the size was not changed, on the next call
to `set-frame-size'.
In the following sequence of resizings, starting with a visible mode
line, only this change caused the mode line to disappear. And it
reappeared at the next resizing.
CUR: (72 20)
NEW: (72 22)
----------------
CUR: (81 63)
NEW: (72 63)
//////////////////////
CUR: (72 61)
NEW: (72 53)
//////////////////////
CUR: (72 51)
NEW: (72 62)
//////////////////////
CUR: (72 60)
NEW: (72 63)
//////////////////////
CUR: (72 61)
NEW: (72 22)
//////////////////////
CUR: (72 20)
NEW: (72 22)
//////////////////////
CUR: (72 22)
NEW: (72 47)
//////////////////////
---------------
That was using Info. Note that though the `height' parameter value was
slightly increased when the mode line was lost, I saw no apparent change
in the frame size. Dunno what that means.
> > Actually, now I can repro it more simply, without using Info. In my
> > setup, if I do M-: (fit-frame) more than once in the same frame, the
> > mode line sometimes disappears. For most buffers/frames, it disappears.
> > But not always. It does not disappear for `list-faces-display', for
> > some reason. (It does disappear for `list-colors-display'.)
With this test of repeating M-: (fit-frame), this is what I see. The
(240 2) messages are from inputting (fit-frame) into the minibuffer frame,
for M-:. The minibuffer frame is 240 chars wide and 2 chars high.
Evaluating...
CUR: (95 62)
NEW: (95 73)
//////////////////////
Buffer `*Pp Eval Output*' is in mode `Emacs-Lisp'. For info on the mode: `C-h m'.
nil
CUR: (240 2)
NEW: (240 2)
====================
Evaluating...
CUR: (95 71)
NEW: (95 73)
//////////////////////
Buffer `*Pp Eval Output*' is in mode `Emacs-Lisp'. For info on the mode: `C-h m'.
nil
Again, there was no apparent change in the frame height, in spite of the
change in `height' parameter value. The first frame-fit, from height 62
to 73, did represent a size change. The second, from 71 to 73, did not
show any size change. The only change I noticed was the mode line
disappearing.
> Add the following function to your .emacs ...
>
> (defun window--resize-root-window
> (window delta horizontal ignore pixelwise)
> ...)
>
> ... and post the contents of the buffer *window-frame-dump* after a
> fatal resize operation here (but make sure to not resize any frame again
> _before_ getting hold of that buffer's contents!!!).
I tried that, but buffer *window-frame-dump* never was filled with any
text. And I never saw any "fatal resize". IOW, evaluating that defun
did not have any effect that I noticed. I did still continue to
observe the behavior I have recorded above, however. IOW, the mode line
continued to disappear in the same way, with no changes that I could
see.
Do I need to do something more than just evaluate that defun? Do
I need to restart Emacs and do that first or something? (You mentioned
putting it in .emacs, instead of just evaluating it. I just evaluated
it.)
next prev parent reply other threads:[~2014-03-06 18:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-02 20:05 bug#16923: 24.3.50; reression: `set-frame-size' loses mode line Drew Adams
2014-03-02 20:51 ` Eli Zaretskii
2014-03-03 8:29 ` martin rudalics
2014-03-03 14:43 ` Drew Adams
2014-03-03 18:37 ` martin rudalics
2014-03-03 19:17 ` Drew Adams
2014-03-03 19:43 ` martin rudalics
2014-03-03 21:07 ` Drew Adams
2014-03-04 8:08 ` martin rudalics
2014-03-04 18:45 ` Drew Adams
2014-03-05 7:26 ` martin rudalics
2014-03-05 15:43 ` Drew Adams
2014-03-05 16:02 ` Juanma Barranquero
2014-03-05 18:20 ` martin rudalics
2014-03-05 18:32 ` Drew Adams
2014-03-05 19:28 ` martin rudalics
2014-03-05 19:42 ` Drew Adams
2014-03-05 19:53 ` martin rudalics
2014-03-05 21:23 ` Drew Adams
2014-03-06 17:26 ` martin rudalics
2014-03-06 18:25 ` Drew Adams [this message]
2014-03-06 18:54 ` martin rudalics
2014-03-06 20:51 ` Drew Adams
2014-03-06 21:26 ` martin rudalics
2014-03-06 21:51 ` Drew Adams
2014-03-07 7:39 ` martin rudalics
2014-03-07 16:48 ` Drew Adams
2014-03-07 17:48 ` martin rudalics
2014-03-07 18:09 ` Drew Adams
2014-03-07 18:36 ` martin rudalics
2014-03-07 19:13 ` Drew Adams
2014-03-08 9:11 ` martin rudalics
2014-03-08 15:34 ` Drew Adams
2014-03-08 15:48 ` Eli Zaretskii
2014-03-08 18:59 ` martin rudalics
2014-03-08 18:59 ` martin rudalics
2014-03-08 19:12 ` Drew Adams
2014-03-08 19:54 ` martin rudalics
2014-03-08 22:51 ` Drew Adams
2014-03-09 13:56 ` martin rudalics
2014-03-09 16:35 ` Drew Adams
2014-03-09 18:13 ` martin rudalics
2014-03-09 19:14 ` Drew Adams
2014-03-10 9:04 ` martin rudalics
2014-03-28 15:29 ` Drew Adams
2014-03-28 19:28 ` martin rudalics
2019-08-15 1:08 ` Lars Ingebrigtsen
2019-08-15 1:32 ` Drew Adams
2014-03-05 20:05 ` Eli Zaretskii
2014-03-03 15:54 ` Eli Zaretskii
[not found] <<b3d29ce8-c0cb-442e-9e6d-fda3d349c778@default>
[not found] ` <<834n3gtjco.fsf@gnu.org>
2014-03-02 21:53 ` Drew Adams
[not found] ` <<53143D5C.7020000@gmx.at>
[not found] ` <<a2349e72-8172-4652-a980-890f813bc623@default>
[not found] ` <<5314CBE1.6050905@gmx.at>
[not found] ` <<04dda5ae-8b70-42f5-ae09-c1d05ebc9297@default>
[not found] ` <<5314DB5D.50709@gmx.at>
[not found] ` <<29b76228-778a-4aea-8fe4-5abedb5b6795@default>
[not found] ` <<531589F3.1050300@gmx.at>
[not found] ` <<70615a8e-3923-40c3-bfbc-af0a305cd6df@default>
[not found] ` <<5316D1B5.8040801@gmx.at>
[not found] ` <<a2e7f767-2129-4d48-97f4-18b8fbfd6af7@default>
[not found] ` <<53176AF2.9010800@gmx.at>
[not found] ` <<edc5b3cb-8cbd-47fa-aa9e-be9372c43863@default>
[not found] ` <<53177AEF.9050106@gmx.at>
[not found] ` <<83d2i0qulk.fsf@gnu.org>
2014-03-05 21:02 ` Drew Adams
2014-03-06 3:41 ` Eli Zaretskii
[not found] ` <<3f31643f-2638-4ada-8dc4-b3069f3a82fc@default>
[not found] ` <<531780D7.6070109@gmx.at>
[not found] ` <<291bd9d5-923f-440a-821a-06f585557e67@default>
[not found] ` <<5318AFD9.4000208@gmx.at>
[not found] ` <<8be91728-fcea-4e74-afff-db6a55b52985@default>
[not found] ` <<5318C478.1090007@gmx.at>
[not found] ` <<0f1c6cae-f9cd-4a2b-a662-bcc4116daafc@default>
[not found] ` <<5318E810.7000705@gmx.at>
[not found] ` <<dbc69634-37da-4dcf-a7c6-6c43184b4b6c@default>
[not found] ` <<531977B2.8030109@gmx.at>
[not found] ` <<f46ec99a-8a39-44f2-bf49-7845e1461a3e@default>
[not found] ` <<531A0655.5040400@gmx.at>
[not found] ` <<5e0232ee-58e3-42a3-8102-e12e8e605b2b@default>
[not found] ` <<531A11BE.5070300@gmx.at>
[not found] ` <<738285f8-0119-49cd-b5b5-7e9607fadff3@default>
[not found] ` <<531ADEBC.9030200@gmx.at>
[not found] ` <<1cb471a0-5db3-4c77-90ff-ed8aa2c9bd0b@default>
[not found] ` <<83lhwkpu87.fsf@gnu.org>
2014-03-08 15:56 ` Drew Adams
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=8be91728-fcea-4e74-afff-db6a55b52985@default \
--to=drew.adams@oracle.com \
--cc=16923@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).