bug#19482: Changing to big font cause display problem

bug#19482: Changing to big font cause display problem

[张海君]

Open emacs, and run the following code:
(set-frame-font "Menlo:size=30")

Then text in "*scratch*" buffer disappeared and I can't make the text visible with scrolling up or down.
After resizing Emacs's window size, text is visible.

It seems that after changing font size Emacs doesn't known the real window size and so can't display
correctly.

bug#19482: Changing to big font cause display problem

[martin rudalics]

> Open emacs, and run the following code:
> (set-frame-font "Menlo:size=30")
>
> Then text in "*scratch*" buffer disappeared and I can't make the text visible with scrolling up or down.
> After resizing Emacs's window size, text is visible.
>
> It seems that after changing font size Emacs doesn't known the real window size and so can't display
> correctly.

Can you still see this?  If so please tell us which version of Emacs you
use and how you built it.

Thanks, martin

bug#19482: Changing to big font cause display problem

[张海君]

Yes. 
Emacs Version: 24.4.90. Downloaded from http://emacsformacosx.com/builds.

> 在 2015年2月14日，02:28，martin rudalics <rudalics@gmx.at> 写道：
> 
>> Open emacs, and run the following code:
>> (set-frame-font "Menlo:size=30")
>> 
>> Then text in "*scratch*" buffer disappeared and I can't make the text visible with scrolling up or down.
>> After resizing Emacs's window size, text is visible.
>> 
>> It seems that after changing font size Emacs doesn't known the real window size and so can't display
>> correctly.
> 
> Can you still see this?  If so please tell us which version of Emacs you
> use and how you built it.
> 
> Thanks, martin

bug#19482: Changing to big font cause display problem

[martin rudalics]

> Yes.
> Emacs Version: 24.4.90. Downloaded from http://emacsformacosx.com/builds

Can you please do

M-: (window-dump-frame)

in that frame and post the result (from a buffer called
*window-frame-dump*) here.  If possible do that three times, once before
you issue the (set-frame-font "Menlo:size=30") once after it when you
don't see the *scratch* contents and once after you resized and see the
contents again.  BTW: Instead of resizing, maximizing the frame and
restoring its normal size should make the contents visible too.  Right?

Also can you try with the last of the so-called nightlies?  I doubt it
changes anything but maybe we can debug that problem better then.  I
have no Mac OS X here so the entire task of debugging this will rest on
you.

Thanks, martin

bug#19482: Changing to big font cause display problem

[张海君]

When I do that, emacs reports error:

Debugger entered--Lisp error: (void-function window-dump-frame)
  (window-dump-frame)
  eval((window-dump-frame) nil)
  eval-expression((window-dump-frame) nil)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)


> 在 2015年2月18日，22:05，martin rudalics <rudalics@gmx.at> 写道：
> 
>> Yes.
>> Emacs Version: 24.4.90. Downloaded from http://emacsformacosx.com/builds
> 
> Can you please do
> 
> M-: (window-dump-frame)
> 
> in that frame and post the result (from a buffer called
> *window-frame-dump*) here.  If possible do that three times, once before
> you issue the (set-frame-font "Menlo:size=30") once after it when you
> don't see the *scratch* contents and once after you resized and see the
> contents again.  BTW: Instead of resizing, maximizing the frame and
> restoring its normal size should make the contents visible too.  Right?
> 
> Also can you try with the last of the so-called nightlies?  I doubt it
> changes anything but maybe we can debug that problem better then.  I
> have no Mac OS X here so the entire task of debugging this will rest on
> you.
> 
> Thanks, martin

bug#19482: Changing to big font cause display problem

[martin rudalics]

> When I do that, emacs reports error:
>
> Debugger entered--Lisp error: (void-function window-dump-frame)
>    (window-dump-frame)
>    eval((window-dump-frame) nil)
>    eval-expression((window-dump-frame) nil)
>    call-interactively(eval-expression nil nil)
>    command-execute(eval-expression)

I'm too silly.  I meant

M-: (window--dump-frame)

Sorry for the confusion, martin

bug#19482: Changing to big font cause display problem

[张海君]

> 在 2015年2月19日，14:57，martin rudalics <rudalics@gmx.at> 写道：
> 
>> When I do that, emacs reports error:
>> 
>> Debugger entered--Lisp error: (void-function window-dump-frame)
>>   (window-dump-frame)
>>   eval((window-dump-frame) nil)
>>   eval-expression((window-dump-frame) nil)
>>   call-interactively(eval-expression nil nil)
>>   command-execute(eval-expression)
> 
> I'm too silly.  I meant
> 
> M-: (window--dump-frame)
> 
> Sorry for the confusion, martin

Three results:
----------------------------- (1) before issuing (set-frame-font "Menlo:size=30") ------------------------------------
frame pixel: 874 x 669   cols/lines: 87 x 35   units: 10 x 19
frame text pixel: 850 x 665   cols/lines: 85 x 35
tool: 0  scroll: 0  fringe: 20  border: 2  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 870 x 646   new: 646
char left: 0   top: 0   size: 87 x 34   new: 33
normal: 1.0 x 1.0   new: nil
body pixel: 850 x 628   char: 85 x 33
width left fringe: 10  left margin: 0  right margin: 0
width right fringe: 10  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 646   size: 870 x 19   new: 0
char left: 0   top: 34   size: 870 x 1   new: 0
normal: 1.0 x 1.0   new: ignore
body pixel: 850 x 19   char: 85 x 1
width left fringe: 10  left margin: 0  right margin: 0
width right fringe: 10  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ----------------------
frame pixel: 1552 x 1194   cols/lines: 86 x 35   units: 18 x 34
frame text pixel: 1530 x 1190   cols/lines: 85 x 35
tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 1548 x 1156   new: 1156
char left: 0   top: 0   size: 86 x 34   new: 33
normal: 1.0 x 1.0   new: nil
body pixel: 1530 x 1123   char: 85 x 33
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 33  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1156   size: 1548 x 34   new: 0
char left: 0   top: 34   size: 1548 x 1   new: 0
normal: 1.0 x 1.0   new: ignore
body pixel: 1530 x 34   char: 85 x 1
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

-------------------------- (3) after resizing the frame ----------------------
frame pixel: 1392 x 840   cols/lines: 77 x 24   units: 18 x 34
frame text pixel: 1370 x 836   cols/lines: 76 x 24
tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0

#<window 3 on *window-frame-dump*>   parent: nil
pixel left: 0   top: 0   size: 1388 x 802   new: 802
char left: 0   top: 0   size: 77 x 23   new: 22
normal: 1.0 x 1.0   new: nil
body pixel: 1370 x 769   char: 76 x 22
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 33  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 802   size: 1388 x 34   new: 0
char left: 0   top: 23   size: 1388 x 1   new: 0
normal: 1.0 x 1.0   new: ignore
body pixel: 1370 x 34   char: 76 x 1
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

--------------------------------------------------------------------------

My screen resolution is 1440x900.

bug#19482: Changing to big font cause display problem

[martin rudalics]

> ----------------------------- (1) before issuing (set-frame-font "Menlo:size=30") ------------------------------------
> frame pixel: 874 x 669   cols/lines: 87 x 35   units: 10 x 19
> frame text pixel: 850 x 665   cols/lines: 85 x 35
> tool: 0  scroll: 0  fringe: 20  border: 2  right: 0  bottom: 0
[...]
> ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ----------------------
> frame pixel: 1552 x 1194   cols/lines: 86 x 35   units: 18 x 34
> frame text pixel: 1530 x 1190   cols/lines: 85 x 35
> tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0
[...]
> -------------------------- (3) after resizing the frame ----------------------
> frame pixel: 1392 x 840   cols/lines: 77 x 24   units: 18 x 34
> frame text pixel: 1370 x 836   cols/lines: 76 x 24
> tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0
[...]
> My screen resolution is 1440x900.

IIUC this means that Emacs tries in `set-frame-font' to make your frame
larger than your display which sounds like a bad idea.

Try first to make the frame smaller before you call `set-frame-font'
such that the resizing step in that function stays within the limits of
the display and see whether the problem persists.

Next try instead of (3) to maximize the frame and then restore its
normal size, that is, the one after `set-frame-font', and see whether
the problem persists (here I would simply type M-F10 twice).

Finally, set the variable `frame-inhibit-implied-resize' to t, call
`set-frame-font' and see whether the problem persists.

martin

bug#19482: Changing to big font cause display problem

[张海君]

> 在 2015年2月21日，02:21，martin rudalics <rudalics@gmx.at> 写道：
> 
> IIUC this means that Emacs tries in `set-frame-font' to make your frame
> larger than your display which sounds like a bad idea.
> 
> Try first to make the frame smaller before you call `set-frame-font'
> such that the resizing step in that function stays within the limits of
> the display and see whether the problem persists.
> 
> Next try instead of (3) to maximize the frame and then restore its
> normal size, that is, the one after `set-frame-font', and see whether
> the problem persists (here I would simply type M-F10 twice).
> 
> Finally, set the variable `frame-inhibit-implied-resize' to t, call
> `set-frame-font' and see whether the problem persists.
> 
> martin

The two tries both make the problem disappear. Setting the variable `frame-inhibit-implied-resize' to t has no effect.
It seems that the variable is not defined in version 24.4.90.

bug#19482: Changing to big font cause display problem

[martin rudalics]

>> IIUC this means that Emacs tries in `set-frame-font' to make your frame
>> larger than your display which sounds like a bad idea.
>>
>> Try first to make the frame smaller before you call `set-frame-font'
>> such that the resizing step in that function stays within the limits of
>> the display and see whether the problem persists.
>>
>> Next try instead of (3) to maximize the frame and then restore its
>> normal size, that is, the one after `set-frame-font', and see whether
>> the problem persists (here I would simply type M-F10 twice).
>>
>> Finally, set the variable `frame-inhibit-implied-resize' to t, call
>> `set-frame-font' and see whether the problem persists.
>>
>> martin
>
> The two tries both make the problem disappear. Setting the variable `frame-inhibit-implied-resize' to t has no effect.
> It seems that the variable is not defined in version 24.4.90.

`frame-inhibit-implied-resize' is defined only in Emacs 25 so you would
have to test this with the "nightlies" I mentioned earlier.

Two more questions:

- After doing your `set-frame-font' how much of the frame do you see?
  Do you see the upper left corner, the frame's title?  Do you notice
  that the frame is larger than your display?  For example, if you can
  see the frame's title, you should not see the frame's echo area.

- When you "maximize the frame and then restore its normal size" does
  the frame have the size it had after the `set-frame-font' or did it
  change in some way?  What does (window--dump-frame) give here?

martin

bug#19482: Changing to big font cause display problem

[张海君]

> 在 2015年2月21日，19:44，martin rudalics <rudalics@gmx.at> 写道：
> 
> `frame-inhibit-implied-resize' is defined only in Emacs 25 so you would
> have to test this with the "nightlies" I mentioned earlier.
> 
> Two more questions:
> 
> - After doing your `set-frame-font' how much of the frame do you see?
>  Do you see the upper left corner, the frame's title?  Do you notice
>  that the frame is larger than your display?  For example, if you can
>  see the frame's title, you should not see the frame's echo area.
> 
> - When you "maximize the frame and then restore its normal size" does
>  the frame have the size it had after the `set-frame-font' or did it
>  change in some way?  What does (window--dump-frame) give here?
> 
> martin


I see the doc of the variable 'frame-inhibit-implied-resize'. The new behavior is not what I want.

I like the following behavior:
When setting font, emacs changes frame's size, but the new size is adjusted to keep the whole frame visible.
This is more useful.  


- After setting font:
There's one frame. Frame's height didn't exceed height of display. So I could see both the frame' title and the echo area.
Frame' width exceeded width of display. I could see the upper left corner, but not the right border of the frame.

- When "maximize the frame and then restore its normal size":
Frame's width changed too much. Frame's height changed slightly(less than height of one text line).

Dumped results:
------------------- maximized -------------------------------
frame pixel: 1392 x 840   cols/lines: 77 x 24   units: 18 x 34
frame text pixel: 1370 x 836   cols/lines: 76 x 24
tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 1388 x 802   new: 802
char left: 0   top: 0   size: 77 x 23   new: 21
normal: 1.0 x 1.0   new: nil
body pixel: 1370 x 769   char: 76 x 22
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 33  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 802   size: 1388 x 34   new: 0
char left: 0   top: 23   size: 1388 x 1   new: 1
normal: 1.0 x 1.0   new: ignore
body pixel: 1370 x 34   char: 76 x 1
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

------------------- restored ----------------------------
frame pixel: 1554 x 840   cols/lines: 86 x 24   units: 18 x 34
frame text pixel: 1532 x 836   cols/lines: 85 x 24
tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 1550 x 802   new: 646
char left: 0   top: 0   size: 86 x 23   new: 33
normal: 1.0 x 1.0   new: nil
body pixel: 1532 x 769   char: 85 x 22
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 33  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 802   size: 1550 x 34   new: 0
char left: 0   top: 23   size: 1550 x 1   new: 1
normal: 1.0 x 1.0   new: ignore
body pixel: 1532 x 34   char: 85 x 1
width left fringe: 9  left margin: 0  right margin: 0
width right fringe: 9  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0
---------------------------------------------------------------------

Emacs changes its frame size when setting font, but the frame size may be limited by window manager or something else.
So the frame's real size is not expected as emacs. Here emacs may get the real size and use the real size.

bug#19482: Changing to big font cause display problem

[martin rudalics]

> I like the following behavior:
> When setting font, emacs changes frame's size, but the new size is adjusted to keep the whole frame visible.
> This is more useful.

It's far from trivial to accomplish though.  Suppose you have some frame
sizes H1xV1 and a default font size F1.  Now you change the default font
to F2 and would get the relative sizes H2xV2 where, however, V2 exceeds
the size of your display.  So we adjust V2 (and maybe H2 as well) to fit
the frame into your display.  Next you change the font size back to F1
and probably expect to get the initial sizes H1 and V1 back.  But the
frame sizing code doesn't remember them ...

I do something comparable in the windows code where I maintain for each
window a nominal size (retrievable via `window-normal-size') but dislike
the associated maintenance burden profoundly.

And a final touch: On X and Windows I have a function called
`x-frame-geometry' which, far from perfect, allows to retrieve the sizes
of the part of a frame not managed by Emacs.  I don't have such a
function for the ns part of Emacs.  But to tell whether a frame can be
embedded into a display I need to know the size of the display and the
sizes of the decorations added by the window manager.  Could you write
such a function for ns?

> - After setting font:
> There's one frame. Frame's height didn't exceed height of display. So I could see both the frame' title and the echo area.
> Frame' width exceeded width of display. I could see the upper left corner, but not the right border of the frame.

This contradicts what you said earlier, namely

  ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ----------------------
  frame pixel: 1552 x 1194   cols/lines: 86 x 35   units: 18 x 34
  frame text pixel: 1530 x 1190   cols/lines: 85 x 35
  tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0

and

  My screen resolution is 1440x900.

1194 is certainly larger than 900 so you should either not see the title
bar or not see the echo area.  Can you clarify this issue?  Some strange
things seem to happen on Mac OS X.

> - When "maximize the frame and then restore its normal size":
> Frame's width changed too much. Frame's height changed slightly(less than height of one text line).
>
> Dumped results:
> ------------------- maximized -------------------------------
> frame pixel: 1392 x 840   cols/lines: 77 x 24   units: 18 x 34
> frame text pixel: 1370 x 836   cols/lines: 76 x 24
> tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0
>
> #<window 3 on *scratch*>   parent: nil
> pixel left: 0   top: 0   size: 1388 x 802   new: 802
> char left: 0   top: 0   size: 77 x 23   new: 21
> normal: 1.0 x 1.0   new: nil
> body pixel: 1370 x 769   char: 76 x 22
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 33  divider: 0
>
> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 802   size: 1388 x 34   new: 0
> char left: 0   top: 23   size: 1388 x 1   new: 1
> normal: 1.0 x 1.0   new: ignore
> body pixel: 1370 x 34   char: 76 x 1
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 0  divider: 0
>
> ------------------- restored ----------------------------
> frame pixel: 1554 x 840   cols/lines: 86 x 24   units: 18 x 34

And this seems to confirm what I said above: Restoring doesn't restore
the previous height which should be 1194 but keeps the frame maximized
vertically.  This seems to be an idiosyncrasy of the Mac OS code and we
should either find some reference (on the Web) where this behavior is
described or some Mac OS expert reading this would be so kind to help us
in this regard.

> frame text pixel: 1532 x 836   cols/lines: 85 x 24
> tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0
>
> #<window 3 on *scratch*>   parent: nil
> pixel left: 0   top: 0   size: 1550 x 802   new: 646
> char left: 0   top: 0   size: 86 x 23   new: 33
> normal: 1.0 x 1.0   new: nil
> body pixel: 1532 x 769   char: 85 x 22
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 33  divider: 0
>
> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 802   size: 1550 x 34   new: 0
> char left: 0   top: 23   size: 1550 x 1   new: 1
> normal: 1.0 x 1.0   new: ignore
> body pixel: 1532 x 34   char: 85 x 1
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 0  divider: 0
> ---------------------------------------------------------------------
>
> Emacs changes its frame size when setting font, but the frame size may be limited by window manager or something else.

Indeed.  The problem is to find out what the limits are.

> So the frame's real size is not expected as emacs. Here emacs may get the real size and use the real size.

Emacs should get the size eventually.  If you tried one of the Emacs 25
"nightlies", you should be able to find a variable called
`frame-size-history' there.  We could use that variable to trace back
the OS request and find out why Emacs doesn't process it correctly.

But still note: Even if we can trace this problem and solve it, the
problem remains that the frame's proportions are distorted by the
request and there's hardly a chance to get back the initial frame size
when you switch back to the initial font size.

martin

bug#19482: Changing to big font cause display problem

[张海君]

> 在 2015年2月22日，18:00，martin rudalics <rudalics@gmx.at> 写道：
> 
> It's far from trivial to accomplish though.  Suppose you have some frame
> sizes H1xV1 and a default font size F1.  Now you change the default font
> to F2 and would get the relative sizes H2xV2 where, however, V2 exceeds
> the size of your display.  So we adjust V2 (and maybe H2 as well) to fit
> the frame into your display.  Next you change the font size back to F1
> and probably expect to get the initial sizes H1 and V1 back.  But the
> frame sizing code doesn't remember them ...
> 
To me, I don't care about the initial sizes H1 and V1. Just try to keep the *current* columns and lines.
Maybe we can add a new value like 'smart to the variable frame-inhibit-implied-resize.

> 
> And a final touch: On X and Windows I have a function called
> `x-frame-geometry' which, far from perfect, allows to retrieve the sizes
> of the part of a frame not managed by Emacs.  I don't have such a
> function for the ns part of Emacs.  But to tell whether a frame can be
> embedded into a display I need to know the size of the display and the
> sizes of the decorations added by the window manager.  Could you write
> such a function for ns?
> 
Sorry, I'm not familiar with object-c. I'm just a basic user of Mac.


> This contradicts what you said earlier, namely
> 
>  ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ----------------------
>  frame pixel: 1552 x 1194   cols/lines: 86 x 35   units: 18 x 34
>  frame text pixel: 1530 x 1190   cols/lines: 85 x 35
>  tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0
> 
> and
> 
>  My screen resolution is 1440x900.
> 
> 1194 is certainly larger than 900 so you should either not see the title
> bar or not see the echo area.  Can you clarify this issue?  Some strange
> things seem to happen on Mac OS X.
That's the fact. Emacs doesn't know the real size of frame and is using a wrong frame size.
This must be the cause of the display problem.


> 
> And this seems to confirm what I said above: Restoring doesn't restore
> the previous height which should be 1194 but keeps the frame maximized
> vertically.  This seems to be an idiosyncrasy of the Mac OS code and we
> should either find some reference (on the Web) where this behavior is
> described or some Mac OS expert reading this would be so kind to help us
> in this regard.
Yes.

> 
> Indeed.  The problem is to find out what the limits are.
> 
>> So the frame's real size is not expected as emacs. Here emacs may get the real size and use the real size.
> 
> Emacs should get the size eventually.  If you tried one of the Emacs 25
> "nightlies", you should be able to find a variable called
> `frame-size-history' there.  We could use that variable to trace back
> the OS request and find out why Emacs doesn't process it correctly.
I will try the Emacs 25.

bug#19482: Changing to big font cause display problem

[martin rudalics]

> That's the fact. Emacs doesn't know the real size of frame and is using a wrong frame size.
> This must be the cause of the display problem.

So it seems that we have located the bug now.

>> Indeed.  The problem is to find out what the limits are.

First we have to find out whether and how your window manager does tell
us the limits and/or why Emacs apparently ignores them.

> I will try the Emacs 25.

Fine.  I'll tell you what to do when you're ready.

martin

bug#19482: Changing to big font cause display problem

[张海君]

> 在 2015年2月22日，19:32，martin rudalics <rudalics@gmx.at> 写道：
> 
>> That's the fact. Emacs doesn't know the real size of frame and is using a wrong frame size.
>> This must be the cause of the display problem.
> 
> So it seems that we have located the bug now.
> 
>>> Indeed.  The problem is to find out what the limits are.
> 
> First we have to find out whether and how your window manager does tell
> us the limits and/or why Emacs apparently ignores them.
> 
>> I will try the Emacs 25.
> 
> Fine.  I'll tell you what to do when you're ready.
> 
> martin

I just installed Emacs 25. It seems that this bug is fixed in this version. 
Download from: http://emacsformacosx.com/emacs-builds/Emacs-2015-02-21_01-40-42-3ebf063-universal.dmg

After issuing (set-frame-font "Menlo:size=30"), the dumped result:
---------------------------------------------------------------
frame pixel: 1553 x 844   cols/lines: 88 x 24   units: 18 x 35
frame text pixel: 1533 x 840   cols/lines: 85 x 24
tool: 0  scroll: 0/0  fringe: 16  border: 2  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 1549 x 805   new: 476
char left: 0   top: 0   size: 86 x 23   new: 33
normal: 1.0 x 1.0   new: nil
body pixel: 1533 x 770   char: 85 x 22
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 35  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 805   size: 1549 x 35   new: 0
char left: 0   top: 23   size: 1549 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1533 x 35   char: 85 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

Thank you.

bug#19482: Changing to big font cause display problem

[Jan D.]

> 22 feb 2015 kl. 11:54 skrev 张海君 <netjune@icloud.com>:
> 
> 
>> 在 2015年2月22日，18:00，martin rudalics <rudalics@gmx.at> 写道：

>> And a final touch: On X and Windows I have a function called
>> `x-frame-geometry' which, far from perfect, allows to retrieve the sizes
>> of the part of a frame not managed by Emacs.  I don't have such a
>> function for the ns part of Emacs.  But to tell whether a frame can be
>> embedded into a display I need to know the size of the display and the
>> sizes of the decorations added by the window manager.  Could you write
>> such a function for ns?
>> 
> Sorry, I'm not familiar with object-c. I'm just a basic user of Mac.

I added an implementation for NS.
When looking at the X version, this does not make sense (except from the redundant parantesis):

  outer_height = (FRAME_PIXEL_HEIGHT (f)
		  + FRAME_OUTER_TO_INNER_DIFF_Y (f)
		  + FRAME_OUTER_TO_INNER_DIFF_X (f));

What is the connection between height and DIFF_X?
It should probably be

  outer_height = FRAME_PIXEL_HEIGHT (f)
		  + 2 * FRAME_OUTER_TO_INNER_DIFF_Y (f);


	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

> After issuing (set-frame-font "Menlo:size=30"), the dumped result:
> ---------------------------------------------------------------
> frame pixel: 1553 x 844   cols/lines: 88 x 24   units: 18 x 35

Earlier you had a different default font height here (34 instead of 35):

  ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ----------------------
  frame pixel: 1552 x 1194   cols/lines: 86 x 35   units: 18 x 34

Strictly spoken we should be able to explain that.

martin

bug#19482: Changing to big font cause display problem

[martin rudalics]

 > I added an implementation for NS.

Thanks a lot.

 > When looking at the X version, this does not make sense (except from the redundant parantesis):

The parenthesis is here for indentation purposes only.

 >    outer_height = (FRAME_PIXEL_HEIGHT (f)
 > 		  + FRAME_OUTER_TO_INNER_DIFF_Y (f)
 > 		  + FRAME_OUTER_TO_INNER_DIFF_X (f));
 >
 > What is the connection between height and DIFF_X?
 > It should probably be
 >
 >    outer_height = FRAME_PIXEL_HEIGHT (f)
 > 		  + 2 * FRAME_OUTER_TO_INNER_DIFF_Y (f);

IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar
plus that of one decoration while FRAME_OUTER_TO_INNER_DIFF_X is just
the "width" of the decoration which I assumed equal on all other three
sides but the top one.  I probably should have written

   outer_height = (FRAME_PIXEL_HEIGHT (f)
		  + FRAME_OUTER_TO_INNER_DIFF_Y (f)
		  + border);

instead.  Either way I can't add FRAME_OUTER_TO_INNER_DIFF_Y twice.

However, this version works only because FRAME_OUTER_TO_INNER_DIFF_X
apparently never counts a tool bar on the left or the right.  And at
least here a maximized frame shows decorations only on two orthogonal
sides so the above is certainly not always correct.  Do you have any
better ideas?

martin

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

> 22 feb 2015 kl. 18:10 skrev martin rudalics <rudalics@gmx.at>:
> 
> IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar

Only for external toolbar.

> plus that of one decoration while FRAME_OUTER_TO_INNER_DIFF_X is just
> the "width" of the decoration which I assumed equal on all other three
> sides but the top one.  I probably should have written
> 
>  outer_height = (FRAME_PIXEL_HEIGHT (f)
> 		  + FRAME_OUTER_TO_INNER_DIFF_Y (f)
> 		  + border);
> 
> instead.  Either way I can't add FRAME_OUTER_TO_INNER_DIFF_Y twice.
> 
> However, this version works only because FRAME_OUTER_TO_INNER_DIFF_X
> apparently never counts a tool bar on the left or the right.

The define has just not been updated with something like FRAME_TOOLBAR_WIDTH:

#define FRAME_OUTER_TO_INNER_DIFF_X(f) \
     ((f)->output_data.x->x_pixels_outer_diff)
#define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
     ((f)->output_data.x->y_pixels_outer_diff   \
      + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))

>   And at
> least here a maximized frame shows decorations only on two orthogonal
> sides so the above is certainly not always correct.  Do you have any
> better ideas?

You can always compute them on the fly with something similar to what x_real_positions does and take into account the lower right corner as well as the upper left corner.

A bit offtopic for this bug anyway.

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 >> IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar
 >
 > Only for external toolbar.

... and external menubar, yes.  BTW, when do we get the menu bar in the
title bar?  One line less to count ...

 > The define has just not been updated with something like FRAME_TOOLBAR_WIDTH:
 >
 > #define FRAME_OUTER_TO_INNER_DIFF_X(f) \
 >       ((f)->output_data.x->x_pixels_outer_diff)
 > #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
 >       ((f)->output_data.x->y_pixels_outer_diff   \
 >        + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))

Sure.  But I probably can't change it without changing its clients as
well.

 >>    And at
 >> least here a maximized frame shows decorations only on two orthogonal
 >> sides so the above is certainly not always correct.  Do you have any
 >> better ideas?
 >
 > You can always compute them on the fly with something similar to what x_real_positions does and take into account the lower right corner as well as the upper left corner.

I don't get the borders reported separately so I always distribute the
space occupied by the one visible border among it and the non-existent
border.  Not a great deal obviously, but I'm sure that mouse position
calculations are off by a few pixels in that case.

 > A bit offtopic for this bug anyway.

True.

martin

bug#19482: Changing to big font cause display problem

[张海君]

> 在 2015年2月23日，01:09，martin rudalics <rudalics@gmx.at> 写道：
> 
>> After issuing (set-frame-font "Menlo:size=30"), the dumped result:
>> ---------------------------------------------------------------
>> frame pixel: 1553 x 844   cols/lines: 88 x 24   units: 18 x 35
> 
> Earlier you had a different default font height here (34 instead of 35):
> 
>  ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ----------------------
>  frame pixel: 1552 x 1194   cols/lines: 86 x 35   units: 18 x 34
> 
> Strictly spoken we should be able to explain that.
> 
> martin

Sorry, my mistake. 
I defined a command called "big-font" which actually issues  "(set-frame-font "Monospace:size=30")" (I just noticed this).
The command doesn't work in Emacs 25. So I have set different fonts for them. One is courier(18x34). The other is Menlo(18x35).
But the display problem is not affected.

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

martin rudalics skrev den 2015-02-22 19:52:
>  >> IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar
>  >
>  > Only for external toolbar.
>
> ... and external menubar, yes.  BTW, when do we get the menu bar in the
> title bar?  One line less to count ...

Sadly there is no standard for how to do this.  Ubuntu (and others) 
seems to be moving to having a global menubar a'la MacOS/OSX.
Then you never have to count it.  I think this is semiautomatic, but I 
wonder if Emacs takes it into account, I'll have to test it.

>
>  > The define has just not been updated with something like
> FRAME_TOOLBAR_WIDTH:
>  >
>  > #define FRAME_OUTER_TO_INNER_DIFF_X(f) \
>  >       ((f)->output_data.x->x_pixels_outer_diff)
>  > #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
>  >       ((f)->output_data.x->y_pixels_outer_diff   \
>  >        + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
>
> Sure.  But I probably can't change it without changing its clients as
> well.

I'm not sure.  There are only a few usages, and I think not taking 
toolbal width into account is probably a bug.  Will check this also.

>
>  >>    And at
>  >> least here a maximized frame shows decorations only on two orthogonal
>  >> sides so the above is certainly not always correct.  Do you have any
>  >> better ideas?
>  >
>  > You can always compute them on the fly with something similar to what
> x_real_positions does and take into account the lower right corner as
> well as the upper left corner.
>
> I don't get the borders reported separately so I always distribute the
> space occupied by the one visible border among it and the non-existent
> border.  Not a great deal obviously, but I'm sure that mouse position
> calculations are off by a few pixels in that case.
>

What I meant was that x_real_positions gets the upper left corner for 
the outer window and the inner window and calls the difference 
OUTER_TO_INNER_DIFF.  But you can take the width/height of the 
outer/inner window and also calculate exactly the diff of all sides.

	Jan D.

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

> 23 feb 2015 kl. 07:22 skrev Jan D. <jan.h.d@swipnet.se>:
> 
> Hi.
> 
> martin rudalics skrev den 2015-02-22 19:52:
>> >> IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar
>> >
>> > Only for external toolbar.
>> 
>> ... and external menubar, yes.  BTW, when do we get the menu bar in the
>> title bar?  One line less to count ...
> 
> Sadly there is no standard for how to do this.  Ubuntu (and others) seems to be moving to having a global menubar a'la MacOS/OSX.
> Then you never have to count it.  I think this is semiautomatic, but I wonder if Emacs takes it into account, I'll have to test it.

I could not get a definite answer to this as the semiautomatic move of the menubar doesn't happen anymore.  Maybe I need a setting.

> 
>> 
>> > The define has just not been updated with something like
>> FRAME_TOOLBAR_WIDTH:
>> >
>> > #define FRAME_OUTER_TO_INNER_DIFF_X(f) \
>> >       ((f)->output_data.x->x_pixels_outer_diff)
>> > #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
>> >       ((f)->output_data.x->y_pixels_outer_diff   \
>> >        + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
>> 
>> Sure.  But I probably can't change it without changing its clients as
>> well.
> 
> I'm not sure.  There are only a few usages, and I think not taking toolbal width into account is probably a bug.  Will check this also.

It is a bug, popups will popup at the wrong position.  We need to track all four sides.
I'm implementing that.

> 
>> 
>> >>    And at
>> >> least here a maximized frame shows decorations only on two orthogonal
>> >> sides so the above is certainly not always correct.  Do you have any
>> >> better ideas?
>> >
>> > You can always compute them on the fly with something similar to what
>> x_real_positions does and take into account the lower right corner as
>> well as the upper left corner.
>> 
>> I don't get the borders reported separately so I always distribute the
>> space occupied by the one visible border among it and the non-existent
>> border.  Not a great deal obviously, but I'm sure that mouse position
>> calculations are off by a few pixels in that case.
>> 
> 
> What I meant was that x_real_positions gets the upper left corner for the outer window and the inner window and calls the difference OUTER_TO_INNER_DIFF.  But you can take the width/height of the outer/inner window and also calculate exactly the diff of all sides.

But I still think you are confused about what is outer and inner window here.  In the macro OUTER_TO_INNER_DIFF outer refers to the window that the windowmanager puts as Emacs parent.  "Inner" here is actually the outermost Emacs created X window, and "outer" is the window manager window.
So outer contains the title bar, but this:

  outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border;
  outer_height = (FRAME_PIXEL_HEIGHT (f)
		  + FRAME_OUTER_TO_INNER_DIFF_Y (f)
		  + FRAME_OUTER_TO_INNER_DIFF_X (f));


is just plain wrong, because for you are calculating something that does not correspond to any real window.  For example, on Gnome 3 the window manager puts in a window that is 10 pixels wider on both sides, so it can do shadow effects.  But the border is still one or zero pixels.

So what you have calculated is not the window manager window sizes, because inner_to_outer width is not taken into account.  There actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the Gnome 3 case.  For Gtk+/Motif/Lucid, we create a window outside the frame (i.e. text editing part) that contains the tool bar if external, menu bar and scroll bar.  But that window is not this size either, the width would in general contain the scroll bar for example.

So what are you trying to calculate?  Is it the window manager window geometry, or the geometry of the largest Emacs created window?

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 > It is a bug, popups will popup at the wrong position.  We need to track all four sides.
 > I'm implementing that.

Thanks.

 > But I still think you are confused about what is outer and inner
 > window here.

For the purpose of `x-frame-geometry' the outer window of a frame on X
is the one returned by FRAME_OUTER_WINDOW.  The inner window is the one
whose size is given by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT.
`x-frame-geometry' should return in 'frame-outer-size' the size of the
_outer window_ including any external toolbar or menubar "attached to
that window" (I'm not interested in "floating" bars).  This way, Emacs
can check whether the outer window fits conceptually into the working
area of its display.

 > In the macro OUTER_TO_INNER_DIFF outer refers to the
 > window that the windowmanager puts as Emacs parent.  "Inner" here is
 > actually the outermost Emacs created X window, and "outer" is the
 > window manager window.  So outer contains the title bar,

IIUC the only problem is whether the "window manager window" does
contain the external toolbar/mmenubar.  The title bar and the external
borders are definitely part of the window manager window.

 > but this:
 >
 >    outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border;
 >    outer_height = (FRAME_PIXEL_HEIGHT (f)
 > 		  + FRAME_OUTER_TO_INNER_DIFF_Y (f)
 > 		  + FRAME_OUTER_TO_INNER_DIFF_X (f));
 >
 >
 > is just plain wrong, because for you are calculating something that
 > does not correspond to any real window.  For example, on Gnome 3 the
 > window manager puts in a window that is 10 pixels wider on both sides,
 > so it can do shadow effects.  But the border is still one or zero
 > pixels.

FRAME_OUTER_TO_INNER_DIFF_Y gives me only the offset of the top left
corner, that is, the difference of the top edge of the outer window and
the inner window.  I don't know how to get the difference between the
bottom edge of the Emacs window and the bottom edge of the outer window.
So I approximate.  This approximation obviously goes wrong when the left
and bottom borders are not the same size.  Can you tell me a better way?

 > So what you have calculated is not the window manager window sizes,
 > because inner_to_outer width is not taken into account.

FRAME_OUTER_TO_INNER_DIFF_X gives me the offset of the left edge of the
inner window wrt the outer window.  The only thing I can do is multiply
it by two.  As mentioned earlier, if these differences are not
symmetric, for example, because one border is larger than the other, the
information provided is wrong.  Again, it's the best approximation I can
come up with so far.

 > There
 > actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the
 > Gnome 3 case.

Are you sure?  Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10
pixels you mentioned above?

 > For Gtk+/Motif/Lucid, we create a window outside the
 > frame (i.e. text editing part) that contains the tool bar if external,
 > menu bar and scroll bar.  But that window is not this size either, the
 > width would in general contain the scroll bar for example.

That would be devastating.  Scroll bars are part of the inner window.

 > So what are you trying to calculate?  Is it the window manager window
 > geometry, or the geometry of the largest Emacs created window?

The sizes of the outer window aka window manager window.  The size of
the largest Emacs created window is returned by `x-frame-geometry' for
comparison purpose only (via 'frame-inner-size').

martin

bug#19482: Changing to big font cause display problem

[Jan D.]

martin rudalics skrev den 2015-02-25 08:34:
>  > It is a bug, popups will popup at the wrong position.  We need to
> track all four sides.
>  > I'm implementing that.
>
> Thanks.
>
>  > But I still think you are confused about what is outer and inner
>  > window here.
>
> For the purpose of `x-frame-geometry' the outer window of a frame on X
> is the one returned by FRAME_OUTER_WINDOW.  The inner window is the one
> whose size is given by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT.

Then you should never need to bother with _OUTER_TO_INNER_DIFF.

> `x-frame-geometry' should return in 'frame-outer-size' the size of the
> _outer window_ including any external toolbar or menubar "attached to
> that window" (I'm not interested in "floating" bars).  This way, Emacs
> can check whether the outer window fits conceptually into the working
> area of its display.
>
>  > In the macro OUTER_TO_INNER_DIFF outer refers to the
>  > window that the windowmanager puts as Emacs parent.  "Inner" here is
>  > actually the outermost Emacs created X window, and "outer" is the
>  > window manager window.  So outer contains the title bar,
>
> IIUC the only problem is whether the "window manager window" does
> contain the external toolbar/mmenubar.

It never does.  It only contains the title bar.

>  The title bar and the external
> borders are definitely part of the window manager window.

The title bar is, but borders are not.  It is entirely possible to set 
border on any X window, regardless of where it is in the hierarchy.
So the external borders Emacs sets is on the outmost Emacs window, not 
on the window manager window.

>
>  > but this:
>  >
>  >    outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border;
>  >    outer_height = (FRAME_PIXEL_HEIGHT (f)
>  >           + FRAME_OUTER_TO_INNER_DIFF_Y (f)
>  >           + FRAME_OUTER_TO_INNER_DIFF_X (f));
>  >
>  >
>  > is just plain wrong, because for you are calculating something that
>  > does not correspond to any real window.  For example, on Gnome 3 the
>  > window manager puts in a window that is 10 pixels wider on both sides,
>  > so it can do shadow effects.  But the border is still one or zero
>  > pixels.
>
> FRAME_OUTER_TO_INNER_DIFF_Y gives me only the offset of the top left
> corner, that is, the difference of the top edge of the outer window and
> the inner window.

You must specify what you mean by outer and inner. 
FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost Emacs 
created window and the window manager window.

>  I don't know how to get the difference between the
> bottom edge of the Emacs window and the bottom edge of the outer window.
> So I approximate.  This approximation obviously goes wrong when the left
> and bottom borders are not the same size.  Can you tell me a better way?

As I said, I'm implementing this.  But it seems you don't need this.  If 
you are only interested in the size of the Emacs created outmost window, 
OUTER_TO_INNER_DIFF does not apply.  Only borders do.

>
>  > So what you have calculated is not the window manager window sizes,
>  > because inner_to_outer width is not taken into account.
>
> FRAME_OUTER_TO_INNER_DIFF_X gives me the offset of the left edge of the
> inner window wrt the outer window.

Again, define inner and outer.  We are using confusing terminology.
I suggest
window manager window
Outmost Emacs created window.
Inner Emacs created window.

> The only thing I can do is multiply
> it by two.  As mentioned earlier, if these differences are not
> symmetric, for example, because one border is larger than the other, the
> information provided is wrong.  Again, it's the best approximation I can
> come up with so far.
>
>  > There
>  > actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the
>  > Gnome 3 case.
>
> Are you sure?  Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10
> pixels you mentioned above?

Yes they do.

>
>  > For Gtk+/Motif/Lucid, we create a window outside the
>  > frame (i.e. text editing part) that contains the tool bar if external,
>  > menu bar and scroll bar.  But that window is not this size either, the
>  > width would in general contain the scroll bar for example.
>
> That would be devastating.  Scroll bars are part of the inner window.

Not in the X sense, they are attached to the outmost Emacs created 
window.  Thats one of the reasons we have that window, the other is 
external menubar and external tool bar.

Only Emacs native scrollbar are attached to the inner Emacs window, as 
well as non-external (i.e. text) menu and non-external toolbar.

>
>  > So what are you trying to calculate?  Is it the window manager window
>  > geometry, or the geometry of the largest Emacs created window?
>
> The sizes of the outer window aka window manager window.  The size of
> the largest Emacs created window is returned by `x-frame-geometry' for
> comparison purpose only (via 'frame-inner-size').

But for frame-inner-size you subtract menu and tool bar.  So this is not 
the size of the largest Emacs created window.

What are you doing with these sizes?

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 >> For the purpose of `x-frame-geometry' the outer window of a frame on X
 >> is the one returned by FRAME_OUTER_WINDOW.  The inner window is the one
 >> whose size is given by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT.
 >
 > Then you should never need to bother with _OUTER_TO_INNER_DIFF.

Then how do I get the size of the outer window (the size of the object
returned by FRAME_OUTER_WINDOW)?

 >> IIUC the only problem is whether the "window manager window" does
 >> contain the external toolbar/mmenubar.
 >
 > It never does.  It only contains the title bar.

Are you sure?  External menu and tool bars bars are normally in between
title bar and the inner window so how can they not be counted?

 >>  The title bar and the external
 >> borders are definitely part of the window manager window.
 >
 > The title bar is, but borders are not.  It is entirely possible to set border on any X window, regardless of where it is in the hierarchy.
 > So the external borders Emacs sets is on the outmost Emacs window, not on the window manager window.

Where does Emacs set external borders?  Do we really control that?

 > You must specify what you mean by outer and
 > inner.

I did that and it's still cited at the top of this post.

 > FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost
 > Emacs created window and the window manager window.

No.  It's the diff between the _top edge_ of the outmost Emacs created
window and that of the window manager window (using your parlance).
What's missing is the diff between the _bottom edge_ of the outmost
created window and that of the window manager window.

 >>  I don't know how to get the difference between the
 >> bottom edge of the Emacs window and the bottom edge of the outer window.
 >> So I approximate.  This approximation obviously goes wrong when the left
 >> and bottom borders are not the same size.  Can you tell me a better way?
 >

 > As I said, I'm implementing this.  But it seems you don't need this.
 > If you are only interested in the size of the Emacs created outmost
 > window, OUTER_TO_INNER_DIFF does not apply.

I am interested in the size of the "window manager window".

 > Only borders do.

I also need title bar, external tool and menu bar.

 >>  > So what you have calculated is not the window manager window sizes,
 >>  > because inner_to_outer width is not taken into account.
 >>
 >> FRAME_OUTER_TO_INNER_DIFF_X gives me the offset of the left edge of the
 >> inner window wrt the outer window.
 >
 > Again, define inner and outer.  We are using confusing terminology.
 > I suggest
 > window manager window
 > Outmost Emacs created window.
 > Inner Emacs created window.

The last one is not needed in this discussion.  Can we agree that your
"window manager window" is the one returned by FRAME_OUTER_WINDOW?  And
that the "outmost Emacs created window" is the one whose sizes are
specified by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT?  If so, then

"outer window" is equivalent to "window manager window"

and

"inner window" is equivalent to "outmost Emacs created window"

 >> Are you sure?  Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10
 >> pixels you mentioned above?
 >
 > Yes they do.

Then my calculation should handle this case (and obviously seems to fail
for the external border at the bottom of such a frame).

 >> That would be devastating.  Scroll bars are part of the inner window.
 >
 > Not in the X sense, they are attached to the outmost Emacs created
 > window.  Thats one of the reasons we have that window, the other is
 > external menubar and external tool bar.

But their size is counted in the "inner window" aka "outmost Emacs
created window".  Otherwise we could not really handle a frame with
side-by-side windows where two or more scrollbars would have to be
counted.

 > Only Emacs native scrollbar are attached to the inner Emacs window,

I fail to understand you.  IMHO all scrollbars are attached to the
"inner window".  Scrollbars are part of an Emacs "window" not of an
Emacs "frame" on graphical systems.  To my knowledge, external scroll
bars exist only when embedding the Emacs frame somewhere else, for
example, on a terminal.

 > as well as non-external (i.e. text) menu and non-external toolbar.

These are part of the inner window.

 > But for frame-inner-size you subtract menu and tool bar.  So this is
 > not the size of the largest Emacs created window.

You're right.  What I earlier said about the value of 'frame-inner-size'
was probably misleading.  Let's forget about 'frame-inner-size' for the
moment, it's too confusing.

 > What are you doing with these sizes?

Give applications a possibility to calculate the maximimum size of a
frame so that it remains entirely visible within the work area of its
display.  This could be used, for example, to guarantee that setting the
default font doesn't make a frame larger than the display.

Also I want the sizes of external tool and menu bar for debugging things
like the various maximized/fullsize variants.

martin

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

> 25 feb 2015 kl. 11:33 skrev martin rudalics <rudalics@gmx.at>:
> 
> >> For the purpose of `x-frame-geometry' the outer window of a frame on X
> >> is the one returned by FRAME_OUTER_WINDOW.  The inner window is the one
> >> whose size is given by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT.
> >
> > Then you should never need to bother with _OUTER_TO_INNER_DIFF.
> 
> Then how do I get the size of the outer window (the size of the object
> returned by FRAME_OUTER_WINDOW)?
> 

There is a difference between FRAME_OUTER_WINDOW and the window manager window.  The window manager window is outside FRAME_OUTER_WINDOW, and its parent.
OUTER_TO_INNER gives the diff between the window manager window and FRAME_OUTER_WINDOW.  The size of FRAME_OUTER_WINDOW is FRAME_PIXEL_WIDTH/HEIGHT + borders.

> >> IIUC the only problem is whether the "window manager window" does
> >> contain the external toolbar/mmenubar.
> >
> > It never does.  It only contains the title bar.
> 
> Are you sure?

Like a gazillion percent sure.

>  External menu and tool bars bars are normally in between
> title bar and the inner window so how can they not be counted?

---------------------------------------------------------
|   Window manager window, title bar
| --------------------------------------------------------
| | Emacs outer window, menu bar            
| | tool bar
| | ------------------------------------------------------
| | | Emacs inner window, text and scrollbar
| | |

Things get more complicated for when Emacs is compiled without a toolkit (i.e. non-external menu bar) or the non-external toolbar.  For the no toolkit case, there is no Emacs outer window.
The non-external tool bar, the non-external menubar are in the inner window.  But toolkit menubar/toolbar are in the outer window.

> 
> >>  The title bar and the external
> >> borders are definitely part of the window manager window.
> >
> > The title bar is, but borders are not.  It is entirely possible to set border on any X window, regardless of where it is in the hierarchy.
> > So the external borders Emacs sets is on the outmost Emacs window, not on the window manager window.
> 
> Where does Emacs set external borders?  Do we really control that?
> 

In xfns.c, for the toolkit (Motif/Lucid case):

  XtSetArg (al[ac], XtNborderWidth, f->border_width); ac++;

for the non-toolkit, and tooltip case (xfns.c) in the call to XCreateWindow.
For the Gtk+ case we don't set any, the default is taken from wathever theme is in place.  The border is usually 0 pixel.


> > You must specify what you mean by outer and
> > inner.
> 
> I did that and it's still cited at the top of this post.
> 
> > FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost
> > Emacs created window and the window manager window.
> 
> No.  It's the diff between the _top edge_ of the outmost Emacs created
> window and that of the window manager window (using your parlance).

Correct.

> What's missing is the diff between the _bottom edge_ of the outmost
> created window and that of the window manager window.

Yes.

> 
> >>  I don't know how to get the difference between the
> >> bottom edge of the Emacs window and the bottom edge of the outer window.
> >> So I approximate.  This approximation obviously goes wrong when the left
> >> and bottom borders are not the same size.  Can you tell me a better way?
> >
> 
> > As I said, I'm implementing this.  But it seems you don't need this.
> > If you are only interested in the size of the Emacs created outmost
> > window, OUTER_TO_INNER_DIFF does not apply.
> 
> I am interested in the size of the "window manager window".

Ok.

> 
> > Only borders do.
> 
> I also need title bar, external tool and menu bar.

Please note that a window manager window is just one way a window manager can set a title bar.  There are other ways, esp. for composite managers, and (I guess) Wayland.
In these cases, there is no way we can know the size of the title bar.

> 
> >>  > So what you have calculated is not the window manager window sizes,
> >>  > because inner_to_outer width is not taken into account.
> >>
> >> FRAME_OUTER_TO_INNER_DIFF_X gives me the offset of the left edge of the
> >> inner window wrt the outer window.
> >
> > Again, define inner and outer.  We are using confusing terminology.
> > I suggest
> > window manager window
> > Outmost Emacs created window.
> > Inner Emacs created window.
> 
> The last one is not needed in this discussion.  Can we agree that your
> "window manager window" is the one returned by FRAME_OUTER_WINDOW?

No, because that is not true.

>  And
> that the "outmost Emacs created window" is the one whose sizes are
> specified by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT?

Yes, that is FRAME_OUTER_WINDOW.

>  If so, then
> 
> "outer window" is equivalent to "window manager window"

No.

> 
> and
> 
> "inner window" is equivalent to "outmost Emacs created window"
> 

No.  There are three windows involved, se figure above.

> >> Are you sure?  Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10
> >> pixels you mentioned above?
> >
> > Yes they do.
> 
> Then my calculation should handle this case (and obviously seems to fail
> for the external border at the bottom of such a frame).
> 
> >> That would be devastating.  Scroll bars are part of the inner window.
> >
> > Not in the X sense, they are attached to the outmost Emacs created
> > window.  Thats one of the reasons we have that window, the other is
> > external menubar and external tool bar.
> 
> But their size is counted in the "inner window" aka "outmost Emacs
> created window".  Otherwise we could not really handle a frame with
> side-by-side windows where two or more scrollbars would have to be
> counted.

I was wrong, scrollbars are on the inner window.  Don't know where I got that from.

> 
> > as well as non-external (i.e. text) menu and non-external toolbar.
> 
> These are part of the inner window.

Yes, the non-external are.  The external are not.

> 
> > But for frame-inner-size you subtract menu and tool bar.  So this is
> > not the size of the largest Emacs created window.
> 
> You're right.  What I earlier said about the value of 'frame-inner-size'
> was probably misleading.  Let's forget about 'frame-inner-size' for the
> moment, it's too confusing.
> 
> > What are you doing with these sizes?
> 
> Give applications a possibility to calculate the maximimum size of a
> frame so that it remains entirely visible within the work area of its
> display.  This could be used, for example, to guarantee that setting the
> default font doesn't make a frame larger than the display.
> 

This is a job for the window manager.  Some window managers constrain the size of Emacs, some do not.
Also, you do need to take into account things like panels that the desktop can contain, and handle the fact that the panels may be different on different workspaces and monitors.  Are you handling the case when Emacs is too high for one monitor but there is another monitor below that shows the rest?  Are you handling the same case, but this time the monitor below shows a different workspace and the rest is not shown below?

This is really a window manager function, we should not have it in Emacs at all.  If someone sets a font so large that Emacs is not fully visible, let them.  Tell them to get another window manager if they want Emacs constrained.  And how do we know what the user wants?  Someone might not want Emacs constrained (for example I don't).

> Also I want the sizes of external tool and menu bar for debugging things
> like the various maximized/fullsize variants.

That makes sense.

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 >> Then how do I get the size of the outer window (the size of the object
 >> returned by FRAME_OUTER_WINDOW)?
 >>
 >
 > There is a difference between FRAME_OUTER_WINDOW and the window manager window.  The window manager window is outside FRAME_OUTER_WINDOW, and its parent.
 > OUTER_TO_INNER gives the diff between the window manager window and FRAME_OUTER_WINDOW.  The size of FRAME_OUTER_WINDOW is FRAME_PIXEL_WIDTH/HEIGHT + borders.

With "borders" you mean external borders, I presume.  So in

#define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
      ((f)->output_data.x->y_pixels_outer_diff   \
       + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))

we calculate the height difference of the Emacs outer window and the
Emacs inner window where y_pixels_outer_diff in this context stands for
the external border only.  Correct?  And this

   /* These many pixels are the difference between the outer window (i.e. the
      left and top of the window manager decoration) and FRAME_X_WINDOW.  */
   int x_pixels_diff, y_pixels_diff;

is misleading because "outer window" here is not the same as
"FRAME_OUTER_WINDOW".  So I'm still not sure: What do
y_pixels_outer_diff and y_pixels_diff typically stand for?

 >>>> IIUC the only problem is whether the "window manager window" does
 >>>> contain the external toolbar/mmenubar.
 >>>
 >>> It never does.  It only contains the title bar.
 >>
 >> Are you sure?
 >
 > Like a gazillion percent sure.

OK.  Then we apparently have the following misunderstanding.  You seem
to say that the window manager window does not contain the Emacs outer
window but only the title bar.  I say that the window manager window
contains the title bar and the Emacs outer window.

 >>   External menu and tool bars bars are normally in between
 >> title bar and the inner window so how can they not be counted?
 >
 > ---------------------------------------------------------
 > |   Window manager window, title bar
 > | --------------------------------------------------------
 > | | Emacs outer window, menu bar
 > | | tool bar
 > | | ------------------------------------------------------
 > | | | Emacs inner window, text and scrollbar
 > | | |
 >

We're probably meaning the same thing but you do not include nested
windows, so for you the Emacs inner window is not part of the Emacs
outer window.  Now where do the external borders go in this drawing?  I
considered them part of the window manager window.  You apparently
consider them part of the Emacs outer window.  Right?

 > Things get more complicated for when Emacs is compiled without a
 > toolkit (i.e. non-external menu bar) or the non-external toolbar.  For
 > the no toolkit case, there is no Emacs outer window.

But it's still where the internal borders are?

 >> I also need title bar, external tool and menu bar.
 >
 > Please note that a window manager window is just one way a window
 > manager can set a title bar.  There are other ways, esp. for composite
 > managers, and (I guess) Wayland.  In these cases, there is no way we
 > can know the size of the title bar.

Then we can do nothing in these cases.

 >> Give applications a possibility to calculate the maximimum size of a
 >> frame so that it remains entirely visible within the work area of its
 >> display.  This could be used, for example, to guarantee that setting the
 >> default font doesn't make a frame larger than the display.
 >>
 >
 > This is a job for the window manager.  Some window managers constrain the size of Emacs, some do not.

If I deliberately set the frame size to some large value, there's
obviously no reason to constrain that.  But if I increase the default
font I'd probably want my frame stay within the bounds of the display.
At least the behavior described by the OP where the frame's height is
constrained by the display while the width isn't doesn't sound very
reasonable.

 > Also, you do need to take into account things like panels that the
 > desktop can contain, and handle the fact that the panels may be
 > different on different workspaces and monitors.  Are you handling the
 > case when Emacs is too high for one monitor but there is another
 > monitor below that shows the rest?  Are you handling the same case,
 > but this time the monitor below shows a different workspace and the
 > rest is not shown below?

No.  We already do not everywhere handle these cases correctly.  But my
restriction would be "safe" in the sense that my frame's size would
never exceed that of the frame we produce currently.

 > This is really a window manager function, we should not have it in
 > Emacs at all.  If someone sets a font so large that Emacs is not fully
 > visible, let them.  Tell them to get another window manager if they
 > want Emacs constrained.  And how do we know what the user wants?
 > Someone might not want Emacs constrained (for example I don't).

The OP proposed an option to do that.

martin

bug#19482: Changing to big font cause display problem

[Jan D.]

> 25 feb 2015 kl. 18:33 skrev martin rudalics <rudalics@gmx.at>:
> 
> >> Then how do I get the size of the outer window (the size of the object
> >> returned by FRAME_OUTER_WINDOW)?
> >>
> >
> > There is a difference between FRAME_OUTER_WINDOW and the window manager window.  The window manager window is outside FRAME_OUTER_WINDOW, and its parent.
> > OUTER_TO_INNER gives the diff between the window manager window and FRAME_OUTER_WINDOW.  The size of FRAME_OUTER_WINDOW is FRAME_PIXEL_WIDTH/HEIGHT + borders.
> 
> With "borders" you mean external borders, I presume.

Yes.

>  So in
> 
> #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
>     ((f)->output_data.x->y_pixels_outer_diff   \
>      + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
> 
> we calculate the height difference of the Emacs outer window and the
> Emacs inner window where y_pixels_outer_diff in this context stands for
> the external border only.  Correct?

No.  As currently defined, this is the difference at the top, so it includes the title bar if any. Also, I said the Gnome 3 window manager puts a 10 pixel area for shading purposes.  y_pixels_outer_diff contains these 10 pixels + borders.  Window managers may put extra decorations around a window, those are also included.  Only if the window manager adds nothing to the sides, and there is no title bar does y_pixels_outer_diff represent the border only.

>  And this
> 
>  /* These many pixels are the difference between the outer window (i.e. the
>     left and top of the window manager decoration) and FRAME_X_WINDOW.  */
>  int x_pixels_diff, y_pixels_diff;
> 
> is misleading because "outer window" here is not the same as
> "FRAME_OUTER_WINDOW".  So I'm still not sure: What do
> y_pixels_outer_diff and y_pixels_diff typically stand for?

y_pixels_outer_diff is typically the title bar height + the external border.  Nowdays there are few window managers that add decorations at the top except the title bar, but if they did, it would be added here (like the 10 pixel shading area).

y_pixels_diff is the offsets to the FRAME_X_WINDOW, not the FRAME_OUTER_WINDOW.
For the case with external menu bar and external tool bar at the top, y_pixels_diff is y_pixels_outer_diff + menu bar height + tool bar height. If there are no tool bar or menu bar, then they become the same.

> 
> >>>> IIUC the only problem is whether the "window manager window" does
> >>>> contain the external toolbar/mmenubar.
> >>>
> >>> It never does.  It only contains the title bar.
> >>
> >> Are you sure?
> >
> > Like a gazillion percent sure.
> 
> OK.  Then we apparently have the following misunderstanding.  You seem
> to say that the window manager window does not contain the Emacs outer
> window but only the title bar.

No, the window manager contains them both, the title bar above Emacs outer window.

>  I say that the window manager window
> contains the title bar and the Emacs outer window.

Right.

> 
> >>   External menu and tool bars bars are normally in between
> >> title bar and the inner window so how can they not be counted?
> >
> > ---------------------------------------------------------
> > |   Window manager window, title bar
> > | --------------------------------------------------------
> > | | Emacs outer window, menu bar
> > | | tool bar
> > | | ------------------------------------------------------
> > | | | Emacs inner window, text and scrollbar
> > | | |
> >
> 
> We're probably meaning the same thing but you do not include nested
> windows, so for you the Emacs inner window is not part of the Emacs
> outer window.

I do include nested windows in the picture above.  The inner window is nested inside the outer window, which in turn is nested inside the window manager window.

It is a containment relationship.  Ithe inner window is contained inside the outer window.
The outer window is contained inside the window manager window.

>  Now where do the external borders go in this drawing?  I
> considered them part of the window manager window.  You apparently
> consider them part of the Emacs outer window.  Right?

In X speak they are part of the outer window.  X handles external borders separate from windows, so you specify both width/height and border width when you create a window.  They are part of the outer window, because if you kill the window manager and run without any window manager, the borders are still there.

> 
> > Things get more complicated for when Emacs is compiled without a
> > toolkit (i.e. non-external menu bar) or the non-external toolbar.  For
> > the no toolkit case, there is no Emacs outer window.
> 
> But it's still where the internal borders are?

They are in the inner window.

> 
> >> I also need title bar, external tool and menu bar.
> >
> > Please note that a window manager window is just one way a window
> > manager can set a title bar.  There are other ways, esp. for composite
> > managers, and (I guess) Wayland.  In these cases, there is no way we
> > can know the size of the title bar.
> 
> Then we can do nothing in these cases.

Right.

> 
> >> Give applications a possibility to calculate the maximimum size of a
> >> frame so that it remains entirely visible within the work area of its
> >> display.  This could be used, for example, to guarantee that setting the
> >> default font doesn't make a frame larger than the display.
> >>
> >
> > This is a job for the window manager.  Some window managers constrain the size of Emacs, some do not.
> 
> If I deliberately set the frame size to some large value, there's
> obviously no reason to constrain that.  But if I increase the default
> font I'd probably want my frame stay within the bounds of the display.

Some window managers already do that for you.

> At least the behavior described by the OP where the frame's height is
> constrained by the display while the width isn't doesn't sound very
> reasonable.
> 
> > Also, you do need to take into account things like panels that the
> > desktop can contain, and handle the fact that the panels may be
> > different on different workspaces and monitors.  Are you handling the
> > case when Emacs is too high for one monitor but there is another
> > monitor below that shows the rest?  Are you handling the same case,
> > but this time the monitor below shows a different workspace and the
> > rest is not shown below?
> 
> No.  We already do not everywhere handle these cases correctly.  But my
> restriction would be "safe" in the sense that my frame's size would
> never exceed that of the frame we produce currently.

Then how do you allow for spanning between monitors?

> 
> > This is really a window manager function, we should not have it in
> > Emacs at all.  If someone sets a font so large that Emacs is not fully
> > visible, let them.  Tell them to get another window manager if they
> > want Emacs constrained.  And how do we know what the user wants?
> > Someone might not want Emacs constrained (for example I don't).
> 
> The OP proposed an option to do that.

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 >>   So in
 >>
 >> #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
 >>      ((f)->output_data.x->y_pixels_outer_diff   \
 >>       + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
 >>
 >> we calculate the height difference of the Emacs outer window and the
 >> Emacs inner window where y_pixels_outer_diff in this context stands for
 >> the external border only.  Correct?
 >
 > No.  As currently defined, this is the difference at the top, so it
 > includes the title bar if any. Also, I said the Gnome 3 window manager
 > puts a 10 pixel area for shading purposes.  y_pixels_outer_diff
 > contains these 10 pixels + borders.  Window managers may put extra
 > decorations around a window, those are also included.  Only if the
 > window manager adds nothing to the sides, and there is no title bar
 > does y_pixels_outer_diff represent the border only.

OK.  This is what I assumed initially.  So this macro specifies the
distance of the top of the Emacs inner window from the top of the window
manager window.

 >
 >>   And this
 >>
 >>   /* These many pixels are the difference between the outer window (i.e. the
 >>      left and top of the window manager decoration) and FRAME_X_WINDOW.  */
 >>   int x_pixels_diff, y_pixels_diff;
 >>
 >> is misleading because "outer window" here is not the same as
 >> "FRAME_OUTER_WINDOW".  So I'm still not sure: What do
 >> y_pixels_outer_diff and y_pixels_diff typically stand for?
 >

 > y_pixels_outer_diff is typically the title bar height + the external
 > border.  Nowdays there are few window managers that add decorations at
 > the top except the title bar, but if they did, it would be added here
 > (like the 10 pixel shading area).

So this is the distance of the top of the Emacs outer window from the
top of the window manager window plus the external border.

 > y_pixels_diff is the offsets to the FRAME_X_WINDOW, not the
 > FRAME_OUTER_WINDOW.  For the case with external menu bar and external
 > tool bar at the top, y_pixels_diff is y_pixels_outer_diff + menu bar
 > height + tool bar height. If there are no tool bar or menu bar, then
 > they become the same.

And how does this differ from FRAME_OUTER_TO_INNER_DIFF_Y?

 > I do include nested windows in the picture above.  The inner window is nested inside the outer window, which in turn is nested inside the window manager window.
 >
 > It is a containment relationship.  Ithe inner window is contained inside the outer window.
 > The outer window is contained inside the window manager window.
 >
 >>   Now where do the external borders go in this drawing?  I
 >> considered them part of the window manager window.  You apparently
 >> consider them part of the Emacs outer window.  Right?
 >
 > In X speak they are part of the outer window.  X handles external
 > borders separate from windows, so you specify both width/height and
 > border width when you create a window.  They are part of the outer
 > window, because if you kill the window manager and run without any
 > window manager, the borders are still there.

That's confusing.  OT1H they are part of the outer window and OTOH they
are drawn around the window manager window.  This makes nesting
impossible.  That is, the Emacs outer window cannot be contained in the
windows manager window

 >> But it's still where the internal borders are?
 >
 > They are in the inner window.

But we don't count them in `frame-text-height'.

 > Then how do you allow for spanning between monitors?

You mean someone who increases the default font would expect the frame
to span a second monitor.  That person would have to set the option in a
way that it doesn't constrain the frame's size.

martin

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

I redid the whole INNER_TO_OUTER thing, and now handle all sides.
The macros INNER_TO_OUTER are removed.

	Jan D.

> 25 feb 2015 kl. 19:25 skrev Jan D. <jan.h.d@swipnet.se>:
> 
> 
>> 25 feb 2015 kl. 18:33 skrev martin rudalics <rudalics@gmx.at>:
>> 
>>>> Then how do I get the size of the outer window (the size of the object
>>>> returned by FRAME_OUTER_WINDOW)?
>>>> 
>>> 
>>> There is a difference between FRAME_OUTER_WINDOW and the window manager window.  The window manager window is outside FRAME_OUTER_WINDOW, and its parent.
>>> OUTER_TO_INNER gives the diff between the window manager window and FRAME_OUTER_WINDOW.  The size of FRAME_OUTER_WINDOW is FRAME_PIXEL_WIDTH/HEIGHT + borders.
>> 
>> With "borders" you mean external borders, I presume.
> 
> Yes.
> 
>> So in
>> 
>> #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
>>    ((f)->output_data.x->y_pixels_outer_diff   \
>>     + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
>> 
>> we calculate the height difference of the Emacs outer window and the
>> Emacs inner window where y_pixels_outer_diff in this context stands for
>> the external border only.  Correct?
> 
> No.  As currently defined, this is the difference at the top, so it includes the title bar if any. Also, I said the Gnome 3 window manager puts a 10 pixel area for shading purposes.  y_pixels_outer_diff contains these 10 pixels + borders.  Window managers may put extra decorations around a window, those are also included.  Only if the window manager adds nothing to the sides, and there is no title bar does y_pixels_outer_diff represent the border only.
> 
>> And this
>> 
>> /* These many pixels are the difference between the outer window (i.e. the
>>    left and top of the window manager decoration) and FRAME_X_WINDOW.  */
>> int x_pixels_diff, y_pixels_diff;
>> 
>> is misleading because "outer window" here is not the same as
>> "FRAME_OUTER_WINDOW".  So I'm still not sure: What do
>> y_pixels_outer_diff and y_pixels_diff typically stand for?
> 
> y_pixels_outer_diff is typically the title bar height + the external border.  Nowdays there are few window managers that add decorations at the top except the title bar, but if they did, it would be added here (like the 10 pixel shading area).
> 
> y_pixels_diff is the offsets to the FRAME_X_WINDOW, not the FRAME_OUTER_WINDOW.
> For the case with external menu bar and external tool bar at the top, y_pixels_diff is y_pixels_outer_diff + menu bar height + tool bar height. If there are no tool bar or menu bar, then they become the same.
> 
>> 
>>>>>> IIUC the only problem is whether the "window manager window" does
>>>>>> contain the external toolbar/mmenubar.
>>>>> 
>>>>> It never does.  It only contains the title bar.
>>>> 
>>>> Are you sure?
>>> 
>>> Like a gazillion percent sure.
>> 
>> OK.  Then we apparently have the following misunderstanding.  You seem
>> to say that the window manager window does not contain the Emacs outer
>> window but only the title bar.
> 
> No, the window manager contains them both, the title bar above Emacs outer window.
> 
>> I say that the window manager window
>> contains the title bar and the Emacs outer window.
> 
> Right.
> 
>> 
>>>>  External menu and tool bars bars are normally in between
>>>> title bar and the inner window so how can they not be counted?
>>> 
>>> ---------------------------------------------------------
>>> |   Window manager window, title bar
>>> | --------------------------------------------------------
>>> | | Emacs outer window, menu bar
>>> | | tool bar
>>> | | ------------------------------------------------------
>>> | | | Emacs inner window, text and scrollbar
>>> | | |
>>> 
>> 
>> We're probably meaning the same thing but you do not include nested
>> windows, so for you the Emacs inner window is not part of the Emacs
>> outer window.
> 
> I do include nested windows in the picture above.  The inner window is nested inside the outer window, which in turn is nested inside the window manager window.
> 
> It is a containment relationship.  Ithe inner window is contained inside the outer window.
> The outer window is contained inside the window manager window.
> 
>> Now where do the external borders go in this drawing?  I
>> considered them part of the window manager window.  You apparently
>> consider them part of the Emacs outer window.  Right?
> 
> In X speak they are part of the outer window.  X handles external borders separate from windows, so you specify both width/height and border width when you create a window.  They are part of the outer window, because if you kill the window manager and run without any window manager, the borders are still there.
> 
>> 
>>> Things get more complicated for when Emacs is compiled without a
>>> toolkit (i.e. non-external menu bar) or the non-external toolbar.  For
>>> the no toolkit case, there is no Emacs outer window.
>> 
>> But it's still where the internal borders are?
> 
> They are in the inner window.
> 
>> 
>>>> I also need title bar, external tool and menu bar.
>>> 
>>> Please note that a window manager window is just one way a window
>>> manager can set a title bar.  There are other ways, esp. for composite
>>> managers, and (I guess) Wayland.  In these cases, there is no way we
>>> can know the size of the title bar.
>> 
>> Then we can do nothing in these cases.
> 
> Right.
> 
>> 
>>>> Give applications a possibility to calculate the maximimum size of a
>>>> frame so that it remains entirely visible within the work area of its
>>>> display.  This could be used, for example, to guarantee that setting the
>>>> default font doesn't make a frame larger than the display.
>>>> 
>>> 
>>> This is a job for the window manager.  Some window managers constrain the size of Emacs, some do not.
>> 
>> If I deliberately set the frame size to some large value, there's
>> obviously no reason to constrain that.  But if I increase the default
>> font I'd probably want my frame stay within the bounds of the display.
> 
> Some window managers already do that for you.
> 
>> At least the behavior described by the OP where the frame's height is
>> constrained by the display while the width isn't doesn't sound very
>> reasonable.
>> 
>>> Also, you do need to take into account things like panels that the
>>> desktop can contain, and handle the fact that the panels may be
>>> different on different workspaces and monitors.  Are you handling the
>>> case when Emacs is too high for one monitor but there is another
>>> monitor below that shows the rest?  Are you handling the same case,
>>> but this time the monitor below shows a different workspace and the
>>> rest is not shown below?
>> 
>> No.  We already do not everywhere handle these cases correctly.  But my
>> restriction would be "safe" in the sense that my frame's size would
>> never exceed that of the frame we produce currently.
> 
> Then how do you allow for spanning between monitors?
> 
>> 
>>> This is really a window manager function, we should not have it in
>>> Emacs at all.  If someone sets a font so large that Emacs is not fully
>>> visible, let them.  Tell them to get another window manager if they
>>> want Emacs constrained.  And how do we know what the user wants?
>>> Someone might not want Emacs constrained (for example I don't).
>> 
>> The OP proposed an option to do that.
> 
> 	Jan D.
> 
> 
> 
> 

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

> 25 feb 2015 kl. 20:00 skrev martin rudalics <rudalics@gmx.at>:
> 
> >>   So in
> >>
> >> #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
> >>      ((f)->output_data.x->y_pixels_outer_diff   \
> >>       + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
> >>
> >> we calculate the height difference of the Emacs outer window and the
> >> Emacs inner window where y_pixels_outer_diff in this context stands for
> >> the external border only.  Correct?
> >
> > No.  As currently defined, this is the difference at the top, so it
> > includes the title bar if any. Also, I said the Gnome 3 window manager
> > puts a 10 pixel area for shading purposes.  y_pixels_outer_diff
> > contains these 10 pixels + borders.  Window managers may put extra
> > decorations around a window, those are also included.  Only if the
> > window manager adds nothing to the sides, and there is no title bar
> > does y_pixels_outer_diff represent the border only.
> 
> OK.  This is what I assumed initially.  So this macro specifies the
> distance of the top of the Emacs inner window from the top of the window
> manager window.

Yes, but it is buggy as it does not take into accout the case of the tool bar at the bottom.

> 
> >
> >>   And this
> >>
> >>   /* These many pixels are the difference between the outer window (i.e. the
> >>      left and top of the window manager decoration) and FRAME_X_WINDOW.  */
> >>   int x_pixels_diff, y_pixels_diff;
> >>
> >> is misleading because "outer window" here is not the same as
> >> "FRAME_OUTER_WINDOW".  So I'm still not sure: What do
> >> y_pixels_outer_diff and y_pixels_diff typically stand for?
> >
> 
> > y_pixels_outer_diff is typically the title bar height + the external
> > border.  Nowdays there are few window managers that add decorations at
> > the top except the title bar, but if they did, it would be added here
> > (like the 10 pixel shading area).
> 
> So this is the distance of the top of the Emacs outer window from the
> top of the window manager window plus the external border.

Yes.

> 
> > y_pixels_diff is the offsets to the FRAME_X_WINDOW, not the
> > FRAME_OUTER_WINDOW.  For the case with external menu bar and external
> > tool bar at the top, y_pixels_diff is y_pixels_outer_diff + menu bar
> > height + tool bar height. If there are no tool bar or menu bar, then
> > they become the same.
> 
> And how does this differ from FRAME_OUTER_TO_INNER_DIFF_Y?

I don't know, I think they would be the same.

> 
> > I do include nested windows in the picture above.  The inner window is nested inside the outer window, which in turn is nested inside the window manager window.
> >
> > It is a containment relationship.  Ithe inner window is contained inside the outer window.
> > The outer window is contained inside the window manager window.
> >
> >>   Now where do the external borders go in this drawing?  I
> >> considered them part of the window manager window.  You apparently
> >> consider them part of the Emacs outer window.  Right?
> >
> > In X speak they are part of the outer window.  X handles external
> > borders separate from windows, so you specify both width/height and
> > border width when you create a window.  They are part of the outer
> > window, because if you kill the window manager and run without any
> > window manager, the borders are still there.
> 
> That's confusing.  OT1H they are part of the outer window and OTOH they
> are drawn around the window manager window.

No, the border is drawn around the outer window.

>  This makes nesting
> impossible.  That is, the Emacs outer window cannot be contained in the
> windows manager window

The only purpose for a window manager windon is to contain other applications top level windows.

> 
> >> But it's still where the internal borders are?
> >
> > They are in the inner window.
> 
> But we don't count them in `frame-text-height'.

Ok.  That makes sense though, the inner border is not text.

> 
> > Then how do you allow for spanning between monitors?
> 
> You mean someone who increases the default font would expect the frame
> to span a second monitor.  That person would have to set the option in a
> way that it doesn't constrain the frame's size.

But if you want to span when the second monitor is connected, but constrain when there is only one?
There are so many corner cases here.  There will be bug reports if Emacs tries to constrain stuff.
The only one that has the full picture is the window manager, so it is its job, not Emacs.

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 >> That's confusing.  OT1H they are part of the outer window and OTOH they
 >> are drawn around the window manager window.
 >
 > No, the border is drawn around the outer window.

Here the border appears above the title bar so it's drawn around the
window manager window.  Do you really see the external border below the
title bar?

 > But if you want to span when the second monitor is connected, but constrain when there is only one?
 > There are so many corner cases here.  There will be bug reports if Emacs tries to constrain stuff.
 > The only one that has the full picture is the window manager, so it is its job, not Emacs.

Then strictly spoken `set-default-font' should not ask the window
manager to change the size of our window.

martin

bug#19482: Changing to big font cause display problem

[martin rudalics]

 > I redid the whole INNER_TO_OUTER thing, and now handle all sides.
 > The macros INNER_TO_OUTER are removed.

Thanks.  I'm a bit lost currently because there seem to be problems
here, at least with my GTK+3 build on the Xfce desktop.  I've tried to
debug x_real_pos_and_offsets with emacs -Q but still am not able to find
out what's wrong.  Maybe you can help with the following two issues.

(1) `x-frame-geometry' reports an external border width of zero for a
     normal, non-maximized frame.  That's clearly wrong, the width is 5
     pixels.  I have no idea how to track down what XGetWindowAttributes
     retrieves here.

(2) `x-frame-geometry' reports a title height of 5.  This is wrong - the
     title height is 20 pixels.  I don't yet understand how
     x_real_pos_and_offsets works but I strongly suppose that

       if (top_offset_y) *top_offset_y = -outer_x;

     should be

       if (top_offset_y) *top_offset_y = -outer_y;

     at least.

Also, these two assignments

   outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border + right_off + left_off;
   outer_height = FRAME_PIXEL_HEIGHT (f) + 2 * border + top_off + bottom_off;

should _not_ use FRAME_PIXEL_HEIGHT and FRAME_PIXEL_WIDTH because that
would mean that I counter-check our calculations of frame sizes from
these calculations.  What we should use here are the 'width' and 'height'
attributes as returned by XWindowAttributes.

I haven't checked yet but do we conceptually assume that

FRAME_PIXEL_WIDTH (f) == atts.width
FRAME_PIXEL_HEIGHT (f) == atts.height

Or does something additionally come into play here?

Thanks, martin

bug#19482: Changing to big font cause display problem

[Jan D.]

> 27 feb 2015 kl. 09:30 skrev martin rudalics <rudalics@gmx.at>:
> 
> >> That's confusing.  OT1H they are part of the outer window and OTOH they
> >> are drawn around the window manager window.
> >
> > No, the border is drawn around the outer window.
> 
> Here the border appears above the title bar so it's drawn around the
> window manager window.  Do you really see the external border below the
> title bar?

No, but thats because I have a hard time finding a window manager that does not override the border width and sets it to 0, jsu because it looks bad.  What you see is probably not the border, but the window manager decorations.

> 
> > But if you want to span when the second monitor is connected, but constrain when there is only one?
> > There are so many corner cases here.  There will be bug reports if Emacs tries to constrain stuff.
> > The only one that has the full picture is the window manager, so it is its job, not Emacs.
> 
> Then strictly spoken `set-default-font' should not ask the window
> manager to change the size of our window.

That is a separate issue.  It is up tp the application if it want to request a new size.  But it is up to the window manager if it wants to grant or constrain that request.

	Jan D.

bug#19482: Changing to big font cause display problem

[Jan D.]

> 27 feb 2015 kl. 09:30 skrev martin rudalics <rudalics@gmx.at>:
> 
> > I redid the whole INNER_TO_OUTER thing, and now handle all sides.
> > The macros INNER_TO_OUTER are removed.
> 
> Thanks.  I'm a bit lost currently because there seem to be problems
> here, at least with my GTK+3 build on the Xfce desktop.  I've tried to
> debug x_real_pos_and_offsets with emacs -Q but still am not able to find
> out what's wrong.  Maybe you can help with the following two issues.
> 
> (1) `x-frame-geometry' reports an external border width of zero for a
>    normal, non-maximized frame.  That's clearly wrong, the width is 5
>    pixels.  I have no idea how to track down what XGetWindowAttributes
>    retrieves here.

As I said in another mail, this is probably the window manager decorations, not a window border.  5 pixels is a large window border, but a reasonable window manager decoration.
However, I added the window manager window border to the calculations, but I suspect it is 0 all the time.
In theory it could be something else.

> 
> (2) `x-frame-geometry' reports a title height of 5.  This is wrong - the
>    title height is 20 pixels.  I don't yet understand how
>    x_real_pos_and_offsets works but I strongly suppose that
> 
>      if (top_offset_y) *top_offset_y = -outer_x;
> 
>    should be
> 
>      if (top_offset_y) *top_offset_y = -outer_y;
> 
>    at least.
> 

Typo, fixed now.

> Also, these two assignments
> 
>  outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border + right_off + left_off;
>  outer_height = FRAME_PIXEL_HEIGHT (f) + 2 * border + top_off + bottom_off;
> 
> should _not_ use FRAME_PIXEL_HEIGHT and FRAME_PIXEL_WIDTH because that
> would mean that I counter-check our calculations of frame sizes from
> these calculations.  What we should use here are the 'width' and 'height'
> attributes as returned by XWindowAttributes.

Indeed.

> 
> I haven't checked yet but do we conceptually assume that
> 
> FRAME_PIXEL_WIDTH (f) == atts.width
> FRAME_PIXEL_HEIGHT (f) == atts.height
> 
> Or does something additionally come into play here?

attts.height contains the external menu bar and tool bar, but PIXEL_HEIGHT does not.  I did not think that one through.

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 >> (1) `x-frame-geometry' reports an external border width of zero for a
 >>     normal, non-maximized frame.  That's clearly wrong, the width is 5
 >>     pixels.  I have no idea how to track down what XGetWindowAttributes
 >>     retrieves here.
 >
 > As I said in another mail, this is probably the window manager decorations, not a window border.  5 pixels is a large window border, but a reasonable window manager decoration.
 > However, I added the window manager window border to the calculations, but I suspect it is 0 all the time.
 > In theory it could be something else.

In my book the border is that thing I have to drag in order to resize a
window with the mouse.  Is that wrong?  Does that mean that the border
reported by XGetWindowAttributes is not the same as the border reported
by XGetGeometry?  In this case we should probably not ignore the eight
argument of the latter.

 >> (2) `x-frame-geometry' reports a title height of 5.  This is wrong - the
 >>     title height is 20 pixels.  I don't yet understand how
 >>     x_real_pos_and_offsets works but I strongly suppose that
 >>
 >>       if (top_offset_y) *top_offset_y = -outer_x;
 >>
 >>     should be
 >>
 >>       if (top_offset_y) *top_offset_y = -outer_y;
 >>
 >>     at least.
 >>
 >
 > Typo, fixed now.

Thanks.

 >> Also, these two assignments
 >>
 >>   outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border + right_off + left_off;
 >>   outer_height = FRAME_PIXEL_HEIGHT (f) + 2 * border + top_off + bottom_off;
 >>
 >> should _not_ use FRAME_PIXEL_HEIGHT and FRAME_PIXEL_WIDTH because that
 >> would mean that I counter-check our calculations of frame sizes from
 >> these calculations.  What we should use here are the 'width' and 'height'
 >> attributes as returned by XWindowAttributes.
 >
 > Indeed.
 >
 >>
 >> I haven't checked yet but do we conceptually assume that
 >>
 >> FRAME_PIXEL_WIDTH (f) == atts.width
 >> FRAME_PIXEL_HEIGHT (f) == atts.height
 >>
 >> Or does something additionally come into play here?
 >
 > attts.height contains the external menu bar and tool bar, but PIXEL_HEIGHT does not.  I did not think that one through.

OK.  I'll try to play around with these.

martin

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi. 



> 27 feb 2015 kl. 20:49 skrev martin rudalics <rudalics@gmx.at>:
> 
> >> (1) `x-frame-geometry' reports an external border width of zero for a
> >>     normal, non-maximized frame.  That's clearly wrong, the width is 5
> >>     pixels.  I have no idea how to track down what XGetWindowAttributes
> >>     retrieves here.
> >
> > As I said in another mail, this is probably the window manager decorations, not a window border.  5 pixels is a large window border, but a reasonable window manager decoration.
> > However, I added the window manager window border to the calculations, but I suspect it is 0 all the time.
> > In theory it could be something else.
> 
> In my book the border is that thing I have to drag in order to resize a
> window with the mouse.  Is that wrong?  Does that mean that the border
> reported by XGetWindowAttributes is not the same as the border reported
> by XGetGeometry?  In this case we should probably not ignore the eight
> argument of the latter.

The thing you drag to resize is not the X11 window border, it is a decoration drawn by the window manager in the window manager window. The border from XGetGeometry is the same as the one in XGetWindowAttributes.

     Jan D. 

bug#19482: Changing to big font cause display problem

[martin rudalics]

Hi Jan

For my Gtk+ frame I currently get the following values for
(x-frame-geometry):

(frame-outer-size 762 . 729)
(external-border-size 0 . 0)
(title-height . 25)
(menu-bar-external . t)
(menu-bar-size 752 . 25)
(tool-bar-external . t)
(tool-bar-position . top)
(tool-bar-size 752 . 44)
(frame-inner-size 752 . 630)

Now the sum of inner frame, tool bar, menu bar and title bar heights
gets me 724 (630 + 44 + 25 + 25) which means there are five pixels
missing wrt to the height of the outer frame.  These are obviously from
the bottom of the frame (bottom_off being 5 here) while apparently the
five pixels of the decoration at the top of the frame are not counted in
top_off.  The 5 + 5 missing pixels on the left and right of the frame
come from left_off and right_off, respectively.  The results for Lucid,
Motif and without toolkit frames are similar.

So I'd like to conclude that the size of my decorations are 5 everywhere
but I cannot find the 5 pixels from the decoration at the top.  25
pixels for the title bar sound reasonable, it appears quite as large as
the menu bar.  Any ideas?

Thanks, martin

bug#19482: Changing to big font cause display problem

[Jan D.]

martin rudalics skrev 2015-03-01 16:14:
> Hi Jan
>

Hi.

> For my Gtk+ frame I currently get the following values for
> (x-frame-geometry):
>
> (frame-outer-size 762 . 729)
> (external-border-size 0 . 0)
> (title-height . 25)
> (menu-bar-external . t)
> (menu-bar-size 752 . 25)
> (tool-bar-external . t)
> (tool-bar-position . top)
> (tool-bar-size 752 . 44)
> (frame-inner-size 752 . 630)
>
> Now the sum of inner frame, tool bar, menu bar and title bar heights
> gets me 724 (630 + 44 + 25 + 25) which means there are five pixels
> missing wrt to the height of the outer frame.  These are obviously from
> the bottom of the frame (bottom_off being 5 here) while apparently the
> five pixels of the decoration at the top of the frame are not counted in
> top_off.  The 5 + 5 missing pixels on the left and right of the frame
> come from left_off and right_off, respectively.  The results for Lucid,
> Motif and without toolkit frames are similar.
>
> So I'd like to conclude that the size of my decorations are 5 everywhere
> but I cannot find the 5 pixels from the decoration at the top.  25
> pixels for the title bar sound reasonable, it appears quite as large as
> the menu bar.  Any ideas?
>

We can only calculate the difference between Emacs top and the window 
manager window top. So the 5 pixels you are looking for are part of 
title-height.  title-height should really be named "whatever the window 
manager window puts above the top of our Emacs window".  It can be title 
bar, title bar + decoration, or just about anything.  We can't know.

	Jan D.

bug#19482: Changing to big font cause display problem

[张海君]

In Emacs 24.4.91, this bug still exist. Will it be fixed in 24.5?

bug#19482: Changing to big font cause display problem

[martin rudalics]

 > In Emacs 24.4.91, this bug still exist. Will it be fixed in 24.5?

I don't have any clue what might have made it disappear in Emacs 25.
Maybe Jan can help (I suppose he made the corresponding change).

You could try to bisect Emacs 25 and find the most recent build where it
did not work.  But the subsequent change might be to big in order to get
safely applied to Emacs 24.5 so I cannot really recommend it.

martin

bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

> 10 mar 2015 kl. 19:47 skrev martin rudalics <rudalics@gmx.at>:
> 
> > In Emacs 24.4.91, this bug still exist. Will it be fixed in 24.5?
> 
> I don't have any clue what might have made it disappear in Emacs 25.
> Maybe Jan can help (I suppose he made the corresponding change).

I know which change it is, but it is a bit late for 24.5.  After all, it is no crash.  A small resize corrects the frame.

> 
> You could try to bisect Emacs 25 and find the most recent build where it
> did not work.  But the subsequent change might be to big in order to get
> safely applied to Emacs 24.5 so I cannot really recommend it.

It is not big, but as it involves resizing it may have consequences.

	Jan D.

bug#19482: Changing to big font cause display problem

[martin rudalics]

 > I know which change it is, but it is a bit late for 24.5.  After all,
 > it is no crash.  A small resize corrects the frame.

Could you please install a reference to this bug either in the ChangeLog
or in the code?  Then we could close this bug.

Thanks, martin

bug#19482: Changing to big font cause display problem

[Eli Zaretskii]

> Date: Thu, 12 Mar 2015 11:13:57 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 张海君 <netjune@icloud.com>,
> 	19482@debbugs.gnu.org
> 
>  > I know which change it is, but it is a bit late for 24.5.  After all,
>  > it is no crash.  A small resize corrects the frame.
> 
> Could you please install a reference to this bug either in the ChangeLog
> or in the code?  Then we could close this bug.

I think we should wait until 24.5 is released (should be soonish), and
then backport the fix to the emacs-24 branch.  _Then_ we can close the
bug.

Thanks.

bug#19482: Changing to big font cause display problem

[Jan D.]

> 12 mar 2015 kl. 11:13 skrev martin rudalics <rudalics@gmx.at>:
> 
> > I know which change it is, but it is a bit late for 24.5.  After all,
> > it is no crash.  A small resize corrects the frame.
> 
> Could you please install a reference to this bug either in the ChangeLog
> or in the code?  Then we could close this bug.

Done.

	Jan D.