[Top][All Lists]

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

bug#4543: window-full-height-p

From: martin rudalics
Subject: bug#4543: window-full-height-p
Date: Sat, 26 Sep 2009 11:45:41 +0200
User-agent: Thunderbird (Windows/20090302)

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.


reply via email to

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