bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line


From: Drew Adams
Subject: bug#16923: 24.3.50; reression: `set-frame-size' loses mode line
Date: Sat, 8 Mar 2014 14:51:54 -0800 (PST)

> This means that the frame size changes across the "------------" on line
> 91.  And it changes again across the next two "------------"'s.  Can you
> explain that?

I'm not sure I get your drift.  But as I said, IIRC, each time I hit
`s RET' there was a call to `fit-frame', hence to `set-frame-size'.

If `s' caused the Info node to change to a node of a different size,
then naturally the resulting frame size would be different.

> If it's caused by the window manager, then you should
> notice that the heights don't fit already there (you got 51 lines
> instead of the 59 you requested).

What shows a request of 59 and a result of 51?  I see `51' on line 93,
which I guess you are saying is the resulting frame size (?).  But
resulting from what size request?  Where do you see the `59' as an
indication of what size was requested?

What I think I see instead is this:

3 calls to w32* before the resize request, showing a height of 51,
followed by 3 more calls to w32* after the resize request, showing
a height of 59 (starting on line 138).  But I don't see, in the
dump output, anything that indicates what size was requested with
`set-frame-size'.

This is what I said about that in my report about it:

   When fit-frame was called, it printed ------------.
   Then it called `window--dump-frame' 3 times.
   Then it fit the frame.
   Then it called `window--dump-frame' 3 times again.
   `window--dump-frame' inserted a form feed, then the data.

And this is an extract of the code I used:

 (with-current-buffer (get-buffer-create "*window-frame-dump*")
   (insert "------------\n"))
 (window--dump-frame)
 (window--dump-frame)
 (window--dump-frame)
 (set-frame-size...)
 (window--dump-frame)
 (window--dump-frame)
 (window--dump-frame)

IIRC, it is only the last resize request in throw-bug-16923.txt
that resulted in the loss (or half loss) of the mode line.  The
dump data for the last resize request shows that none of the data
changed as a result of that request.  The sizes do not change, as
they should not change (IIRC, the same node was involved).

IOW, IIUC, the dump data do not show the problem (bug).  The
problem is not, AFAICT, the resulting size.  The problem is that
the mode line is missing (or half missing - I don't recall now
which screenshot corresponds to the dump text).

In sum, sorry, but I'm just not following you well enough.  If
you would like me to do something, or draw a conclusion, or
provide some more information, please clarify/elaborate.

> If it's not caused by the window manager I don't know.

If what is not caused by the window mgr?  If there is no frame
size change and there should not be any frame size change, then
how can the window mgr be at fault?  The problem is that the
mode line disappears.  Without a change in frame size in this case.
How can the window mgr be responsible for a mode line display
malfunction?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]