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