bug#4543: window-full-height-p

[martin rudalics]

Stefan Monnier schrieb:
>> #define FRAME_TOTAL_COLS_ARG(f, width)         \
>>      ((width)                                  \
>>       + FRAME_SCROLL_BAR_COLS (f)              \
>>       + FRAME_FRINGE_COLS (f))
>> and
>
>> #define FRAME_SCROLL_BAR_COLS(f)                       \
>>      (FRAME_HAS_VERTICAL_SCROLL_BARS (f)               \
>>       ? FRAME_CONFIG_SCROLL_BAR_COLS (f)               \
>>       : 0)
>
>> etc ...  What are the scrollbars of a frame, I'm asking myself.
>
> I agree it's rather odd to see such window properties counted
> for frames.  There's probably some ugly counter-balancing calculations
> in the window-size code.

I doubt that.  The window-size code handles scroll bars and fringes on a
per window/buffer basis and fits them (recursively) within the size it's
given by change_frame_size_1 as

      set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2);

So whether and how scroll bars and/or fringes are displayed ignores
anything done in change_frame_size_1.  The problem I see is that the
value for new_frame_total_cols calculated by change_frame_size_1 as

  /* Compute width of windows in F.
     This is the width of the frame without vertical scroll bars.  */
  new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth);

  /* Round up to the smallest acceptable size.  */
  check_frame_size (f, &newheight, &newwidth);

doesn't make sense for more complex window configurations.  I'm not
sure, however, whether text-only terminals inherently rely on these
calculations.  So the question I essentially ask is whether the number
of total columns of a frame's root-window invariantly equals the width
of that frame over all possible terminals.

martin