bug#4543: window-full-height-p

bug#4543: window-full-height-p

[Glenn Morris]

Severity: wishlist

I would like a window-full-height-p function, analogous to
window-full-width-p.

It is difficult to extract this information from frame-height and
window-height for pretty much the same reasons as are used in the
Elisp manual to justify the existence of window-full-width-p. The
value of frame-height depends on the X-toolkit in use, whether there
is a minibuffer, and whether the menu- and tool- bars are on (see
bug#4535).

For example, a quick grep reveals this code in mh-maybe-show in
mh-e/mh-show.el, which is wrong in some circumstances for the reasons
explained above:

(if (not (= (1+ (window-height)) (frame-height))) ;not horizontally split

There seem to be a few similar instances. Perhaps some of them should
be using window-safely-shrinkable-p or some other test, but there are
some times when I really want to know if a window is full-height.

bug#4543: window-full-height-p

[martin rudalics]

 > I would like a window-full-height-p function, analogous to
 > window-full-width-p.

Would

(defun window-full-height-p (&optional window)
   (unless window
     (setq window (selected-window)))
   (= (window-height window)
      (window-height (frame-root-window (window-frame window)))))

fit?

martin

bug#4543: window-full-height-p

[Glenn Morris]

martin rudalics wrote:

> Would
>
> (defun window-full-height-p (&optional window)
>   (unless window
>     (setq window (selected-window)))
>   (= (window-height window)
>      (window-height (frame-root-window (window-frame window)))))
>
> fit?

Seems to work fine for me, thanks. window-full-width-p has a simple C
implementation, but perhaps the same thing is not possible for height?

bug#4543: window-full-height-p

[martin rudalics]

 > window-full-width-p has a simple C
 > implementation,

`window-full-width-p' is based on the definition

   /* Total width of frame F, in columns (characters),
      including the width used by scroll bars if any.  */

   #define FRAME_TOTAL_COLS(f) ((f)->total_cols)

from frame.h whose semantics I don't understand.  Not really simple.

 > but perhaps the same thing is not possible for height?

Hardly.  Also I suppose you don't want the return value include the
minibuffer height.  At least the comment in

     (if (not (= (1+ (window-height)) (frame-height))) ;not horizontally split

seems to suggest that (it confuses horizontally and vertically, BTW).

martin

bug#4543: window-full-height-p

[Eli Zaretskii]

> Date: Fri, 25 Sep 2009 09:40:11 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 4543@emacsbugs.donarmstrong.com
> 
>  > window-full-width-p has a simple C
>  > implementation,
> 
> `window-full-width-p' is based on the definition
> 
>    /* Total width of frame F, in columns (characters),
>       including the width used by scroll bars if any.  */
> 
>    #define FRAME_TOTAL_COLS(f) ((f)->total_cols)
> 
> from frame.h whose semantics I don't understand.  Not really simple.

Maybe I can help.  What is the difficulty with the semantics of this
attribute of a frame?

>  > but perhaps the same thing is not possible for height?
> 
> Hardly.

What's wrong with this (taken from frame.c:frame-parameters) as the
frame height:

  height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f));

and then subtract from it the height of the minibuffer window?

The C variable `minibuf_window' should give you the Lisp object that
holds the minibuffer window, and its `total_lines' attribute should
give you the height of that window.  Or am I missing something?

bug#4543: window-full-height-p

[martin rudalics]

 >> `window-full-width-p' is based on the definition
 >>
 >>    /* Total width of frame F, in columns (characters),
 >>       including the width used by scroll bars if any.  */
 >>
 >>    #define FRAME_TOTAL_COLS(f) ((f)->total_cols)
 >>
 >> from frame.h whose semantics I don't understand.  Not really simple.
 >
 > Maybe I can help.  What is the difficulty with the semantics of this
 > attribute of a frame?

It's merely how this is set in `change_frame_size_1' which does

   SET_FRAME_COLS (f, newwidth);

where

#define SET_FRAME_COLS(f, val)						\
      (FRAME_COLS (f) = (val),						\
       (f)->total_cols = FRAME_TOTAL_COLS_ARG (f, FRAME_COLS (f)))

and

#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.  If we
define a frame as a collection of windows and frame-width as the width
of the widest window in that frame, things are deceptively simple.  But
the calculations sketched above are a little over my head.

 > What's wrong with this (taken from frame.c:frame-parameters) as the
 > frame height:
 >
 >   height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f));

new_text_lines is for a pending size change and zero otherwise.  You
probably mean text_lines whose precise semantics I don't know - what are
canonical characters?

 > and then subtract from it the height of the minibuffer window?
 >
 > The C variable `minibuf_window' should give you the Lisp object that
 > holds the minibuffer window, and its `total_lines' attribute should
 > give you the height of that window.  Or am I missing something?

Then why not use the height of the frame-root-window directly?  No need
to subtract one value from the other.

martin

bug#4543: window-full-height-p

[Eli Zaretskii]

> Date: Fri, 25 Sep 2009 14:59:51 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 4543@emacsbugs.donarmstrong.com, rgm@gnu.org
> 
> It's merely how this is set in `change_frame_size_1' which does
> 
>    SET_FRAME_COLS (f, newwidth);
> 
> where
> 
> #define SET_FRAME_COLS(f, val)						\
>       (FRAME_COLS (f) = (val),						\
>        (f)->total_cols = FRAME_TOTAL_COLS_ARG (f, FRAME_COLS (f)))
> 
> and
> 
> #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 ...

Well, maybe I'm missing something, but this seems quite clear to me.
SET_FRAME_COLS sets both f->text_cols and f->total_cols, the former
counts the width of only the text area of the display, the latter
counts the total frame area that includes the scroll bars and the
fringe.  Both the scroll bar and the fringe may be absent, the most
trivial example is the text terminal display.

> What are the scrollbars of a frame, I'm asking myself.  If we
> define a frame as a collection of windows and frame-width as the width
> of the widest window in that frame, things are deceptively simple.  But
> the calculations sketched above are a little over my head.

If a frame has scroll bars, they are all of the same size, so counting
this on the frame level seems reasonable.

>  > What's wrong with this (taken from frame.c:frame-parameters) as the
>  > frame height:
>  >
>  >   height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f));
> 
> new_text_lines is for a pending size change and zero otherwise.  You
> probably mean text_lines

I don't see any reason not to use new_text_lines as well: first, you
will be consistent with frame-parameters (a Good Thing, IMO), and
second, your code will work even if redisplay didn't yet kick in.

> what are canonical characters?

Each line on the display can have its own height, remember?  For
example, look at a single-window frame whose window displays an
"*info*" buffer -- there are several lines that use a larger fonts,
and take more screen estate than others.  You don't want such a window
to screw up window-height or frame-height, do you?

So to get this right, Emacs measures these in units of canonical
characters, which are characters from the frame's default font.  I
think the size of this canonical character is given by the font info,
but I'm not sure.

>  > and then subtract from it the height of the minibuffer window?
>  >
>  > The C variable `minibuf_window' should give you the Lisp object that
>  > holds the minibuffer window, and its `total_lines' attribute should
>  > give you the height of that window.  Or am I missing something?
> 
> Then why not use the height of the frame-root-window directly?  No need
> to subtract one value from the other.

Fine, if you can get this efficiently in C.

bug#4543: window-full-height-p

[martin rudalics]

 > Well, maybe I'm missing something, but this seems quite clear to me.
 > SET_FRAME_COLS sets both f->text_cols and f->total_cols, the former
 > counts the width of only the text area of the display, the latter
 > counts the total frame area that includes the scroll bars and the
 > fringe.

It doesn't.  Make a frame with two side-by-side windows with scrollbars.
Only one scrollbar is counted in f->total_cols.  f->total_cols is an
artifact whose purpose escapes me so far.  And fringe sizes can be set
on a per window basis, so counting them seems completely useless.

 > Both the scroll bar and the fringe may be absent, the most
 > trivial example is the text terminal display.

In that case f->text_cols equals f->total_cols so we can use the former.

 >> What are the scrollbars of a frame, I'm asking myself.  If we
 >> define a frame as a collection of windows and frame-width as the width
 >> of the widest window in that frame, things are deceptively simple.  But
 >> the calculations sketched above are a little over my head.
 >
 > If a frame has scroll bars, they are all of the same size, so counting
 > this on the frame level seems reasonable.

When I have two side-by-side windows and toggle scroll-bar-mode the
frame resizes by exactly the same amount as if it had only one window.
So the size available for displaying text within windows changes
relatively to the number of side-by-side window I have when toggling
scroll-bar mode.  This is not reasonable.  I'd prefer the frame size to
not change at all when I toggle scroll-bar-mode.  If it is supposed to
change, then all windows would have to change their total width too.

 >>  > What's wrong with this (taken from frame.c:frame-parameters) as the
 >>  > frame height:
 >>  >
 >>  >   height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f));
 >>
 >> new_text_lines is for a pending size change and zero otherwise.  You
 >> probably mean text_lines
 >
 > I don't see any reason not to use new_text_lines as well: first, you
 > will be consistent with frame-parameters (a Good Thing, IMO), and
 > second, your code will work even if redisplay didn't yet kick in.

The code is supposed to work when no size change is pending and the
comment in frame.h says that new_text_lines is zero in that case.

 >> what are canonical characters?
 >
 > Each line on the display can have its own height, remember?  For
 > example, look at a single-window frame whose window displays an
 > "*info*" buffer -- there are several lines that use a larger fonts,
 > and take more screen estate than others.  You don't want such a window
 > to screw up window-height or frame-height, do you?

Honestly, I never want my frame size to change unless I explicitly ask
it to do so.  And I never care about the size of my frame measured in
lines or columns.  What does annoy me is that a maximized Emacs frame
changes its size when I toggle scroll-bars or resize the minibuffer.
And IIUC this problem is not restricted to Windows.

 > So to get this right, Emacs measures these in units of canonical
 > characters, which are characters from the frame's default font.  I
 > think the size of this canonical character is given by the font info,
 > but I'm not sure.

 >> Then why not use the height of the frame-root-window directly?  No need
 >> to subtract one value from the other.
 >
 > Fine, if you can get this efficiently in C.

Why in C?  It's a simple lookup written in Elisp.

martin

bug#4543: window-full-height-p

[Eli Zaretskii]

> Date: Fri, 25 Sep 2009 17:04:10 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 4543@emacsbugs.donarmstrong.com, rgm@gnu.org
> 
>  > Well, maybe I'm missing something, but this seems quite clear to me.
>  > SET_FRAME_COLS sets both f->text_cols and f->total_cols, the former
>  > counts the width of only the text area of the display, the latter
>  > counts the total frame area that includes the scroll bars and the
>  > fringe.
> 
> It doesn't.  Make a frame with two side-by-side windows with scrollbars.
> Only one scrollbar is counted in f->total_cols.  f->total_cols is an
> artifact whose purpose escapes me so far.  And fringe sizes can be set
> on a per window basis, so counting them seems completely useless.

Look, you asked to explain the subtleties of the code, and I think I
did, as best I could.  I hope what the code does is now clear.
Whether it makes sense or should be modified, is another matter.

bug#4543: window-full-height-p

[martin rudalics]

 > Look, you asked to explain the subtleties of the code, and I think I
 > did, as best I could.  I hope what the code does is now clear.

I was impolite.  Please accept my apologies and my belated thanks for
your explanations.

 > Whether it makes sense or should be modified, is another matter.

Indeed.

martin

bug#4543: window-full-height-p

[Stefan Monnier]

> When I have two side-by-side windows and toggle scroll-bar-mode the
> frame resizes by exactly the same amount as if it had only one window.
> So the size available for displaying text within windows changes
> relatively to the number of side-by-side window I have when toggling
> scroll-bar mode.  This is not reasonable.  I'd prefer the frame size to
> not change at all when I toggle scroll-bar-mode.  If it is supposed to
> change, then all windows would have to change their total width too.

Yes, that's clearly not the right behavior.  If you want to change
things so that the scrollbar&fringes are counted in "windows" but not in
"frames" to try and avoid these problems, feel free to try.

> Honestly, I never want my frame size to change unless I explicitly ask
> it to do so.  And I never care about the size of my frame measured in
> lines or columns.  What does annoy me is that a maximized Emacs frame
> changes its size when I toggle scroll-bars or resize the minibuffer.

Agreed.  The fact that sizes are counted in "characters" is also
undesirable for GUI frames.  At some point I suggested to just force the
"canonical character size" to always be 1x1, but IIUC this would
be inefficient.  IIRC, Kim Storm had done some preliminary work towards
getting rid of this "canonical character size" issue.  I'd be a good
change (would solve several minor problems we have, with wasted pixels
here and there).


        Stefan

bug#4543: window-full-height-p

[martin rudalics]

 >> When I have two side-by-side windows and toggle scroll-bar-mode the
 >> frame resizes by exactly the same amount as if it had only one window.
 >> So the size available for displaying text within windows changes
 >> relatively to the number of side-by-side window I have when toggling
 >> scroll-bar mode.  This is not reasonable.  I'd prefer the frame size to
 >> not change at all when I toggle scroll-bar-mode.  If it is supposed to
 >> change, then all windows would have to change their total width too.
 >
 > Yes, that's clearly not the right behavior.  If you want to change
 > things so that the scrollbar&fringes are counted in "windows" but not in
 > "frames" to try and avoid these problems, feel free to try.

Scroll bars and fringes _are_ counted in the "windows" code and do not
affect the frame size.  Otherwise changing scroll bars in a single
window frame would resize the frame as well, just try

(set-window-scroll-bars nil 200 'right)

and see that the frame width remains alone.  So the only problem I see
is with change_frame_size.

martin

bug#4543: window-full-height-p

[Stefan Monnier]

> #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.


        Stefan

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

bug#4543: window-full-height-p

[Eli Zaretskii]

> Date: Sat, 26 Sep 2009 11:45:41 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 4543@emacsbugs.donarmstrong.com
> 
> 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.

Why doesn't it make sense?  The computed value of new_frame_total_cols
is used to enlarge only the frame's root window:

  if (new_frame_total_cols != FRAME_TOTAL_COLS (f))
    {
      set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2);

And for the root window, FRAME_TOTAL_COLS is correct, I think.  The
window configuration, however complex, does not affect the root
window, does it?

> 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.

I think it does, yes.  In any case, the code in change_frame_size_1
_is_ run on text-only terminals (or should I say for frames on
text-only terminals, since we have multi-tty now).

bug#4543: window-full-height-p

[martin rudalics]

 > Why doesn't it make sense?  The computed value of new_frame_total_cols
 > is used to enlarge only the frame's root window:
 >
 >   if (new_frame_total_cols != FRAME_TOTAL_COLS (f))
 >     {
 >       set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2);
 >
 > And for the root window, FRAME_TOTAL_COLS is correct, I think.  The
 > window configuration, however complex, does not affect the root
 > window, does it?

With Emacs -Q I can evaluate

(set-window-scroll-bars nil 0 nil)

to remove the scroll bar from the *scratch* window keeping the window
size unaltered.  When I now evaluate

(scroll-bar-mode -1)

the width of the frame shrinks and with it the number of columns used
for text in the *scratch* window.  This doesn't make sense.

 >> 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.
 >
 > I think it does, yes.  In any case, the code in change_frame_size_1
 > _is_ run on text-only terminals (or should I say for frames on
 > text-only terminals, since we have multi-tty now).

Fine.  I wasn't entirely sure about

   dos_set_window_size (&newheight, &newwidth);

which IIUC does adjust the width value via

   *rows = ScreenRows ();

so this eventually does get related back to the frame's root window.

martin

bug#4543: window-full-height-p

[Eli Zaretskii]

> Date: Sat, 26 Sep 2009 15:41:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 4543@emacsbugs.donarmstrong.com, monnier@IRO.UMontreal.CA
> 
>  > Why doesn't it make sense?  The computed value of new_frame_total_cols
>  > is used to enlarge only the frame's root window:
>  >
>  >   if (new_frame_total_cols != FRAME_TOTAL_COLS (f))
>  >     {
>  >       set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2);
>  >
>  > And for the root window, FRAME_TOTAL_COLS is correct, I think.  The
>  > window configuration, however complex, does not affect the root
>  > window, does it?
> 
> With Emacs -Q I can evaluate
> 
> (set-window-scroll-bars nil 0 nil)
> 
> to remove the scroll bar from the *scratch* window keeping the window
> size unaltered.  When I now evaluate
> 
> (scroll-bar-mode -1)
> 
> the width of the frame shrinks and with it the number of columns used
> for text in the *scratch* window.  This doesn't make sense.

Agreed.  But I must be missing something because I don't see how this
behavior is related to the code you quoted above.

>  >> 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.
>  >
>  > I think it does, yes.  In any case, the code in change_frame_size_1
>  > _is_ run on text-only terminals (or should I say for frames on
>  > text-only terminals, since we have multi-tty now).
> 
> Fine.  I wasn't entirely sure about
> 
>    dos_set_window_size (&newheight, &newwidth);
> 
> which IIUC does adjust the width value via
> 
>    *rows = ScreenRows ();
> 
> so this eventually does get related back to the frame's root window.

That's true, but only if the original newheight or newwidth are not
supported by the underlying video hardware.  If they are supported,
then they are left at their computed values.

And the DOS display does not support scroll bars anyway.

bug#4543: window-full-height-p

[martin rudalics]

 >>  > Why doesn't it make sense?  The computed value of new_frame_total_cols
 >>  > is used to enlarge only the frame's root window:
 >>  >
 >>  >   if (new_frame_total_cols != FRAME_TOTAL_COLS (f))
 >>  >     {
 >>  >       set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2);
 >>  >
 >>  > And for the root window, FRAME_TOTAL_COLS is correct, I think.  The
 >>  > window configuration, however complex, does not affect the root
 >>  > window, does it?
 >>
 >> With Emacs -Q I can evaluate
 >>
 >> (set-window-scroll-bars nil 0 nil)
 >>
 >> to remove the scroll bar from the *scratch* window keeping the window
 >> size unaltered.  When I now evaluate
 >>
 >> (scroll-bar-mode -1)
 >>
 >> the width of the frame shrinks and with it the number of columns used
 >> for text in the *scratch* window.  This doesn't make sense.
 >
 > Agreed.  But I must be missing something because I don't see how this
 > behavior is related to the code you quoted above.

Indeed.  The above quotation should have started with

 >> 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.

in order to make clear that the assignment to new_frame_total_cols is
reponsible for the behavior I sketched.  Or the fact that setting
`scroll-bar-mode' may trigger frame-resizing in the first place.

martin

bug#4543: window-full-height-p

[Eli Zaretskii]

> Date: Sat, 26 Sep 2009 21:01:36 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 4543@emacsbugs.donarmstrong.com, monnier@IRO.UMontreal.CA
> 
>  >>  > Why doesn't it make sense?  The computed value of new_frame_total_cols
>  >>  > is used to enlarge only the frame's root window:
>  >>  >
>  >>  >   if (new_frame_total_cols != FRAME_TOTAL_COLS (f))
>  >>  >     {
>  >>  >       set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2);
>  >>  >
>  >>  > And for the root window, FRAME_TOTAL_COLS is correct, I think.  The
>  >>  > window configuration, however complex, does not affect the root
>  >>  > window, does it?
>  >>
>  >> With Emacs -Q I can evaluate
>  >>
>  >> (set-window-scroll-bars nil 0 nil)
>  >>
>  >> to remove the scroll bar from the *scratch* window keeping the window
>  >> size unaltered.  When I now evaluate
>  >>
>  >> (scroll-bar-mode -1)
>  >>
>  >> the width of the frame shrinks and with it the number of columns used
>  >> for text in the *scratch* window.  This doesn't make sense.
>  >
>  > Agreed.  But I must be missing something because I don't see how this
>  > behavior is related to the code you quoted above.
> 
> Indeed.  The above quotation should have started with
> 
>  >> 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.
> 
> in order to make clear that the assignment to new_frame_total_cols is
> reponsible for the behavior I sketched.

We are looping: the more complex window configurations are irrelevant
for the root window, I think.

>  Or the fact that setting `scroll-bar-mode' may trigger
> frame-resizing in the first place.

What I'm missing is how the code fragments you show are related to the
problematic behavior when `scroll-bar-mode' is toggled.

bug#4543: window-full-height-p

[martin rudalics]

 > We are looping: the more complex window configurations are irrelevant
 > for the root window, I think.

Because I tried to come up with a simple, easily repeatable example that
does not need a more complex configuration.

 > What I'm missing is how the code fragments you show are related to the
 > problematic behavior when `scroll-bar-mode' is toggled.

Since I never understood the mechanism handling frame parameters I can
only conjecture that it's x_set_scroll_bar_width (the handler for the
scroll-bar-width parameter) calling change_frame_size which causes this.

But the basic problem is that handling scroll bar sizes on the frame
level cannot make sense because the mechanism doing that wouldn't know

(1) whether an individual window has scrollbars and how large they are,

(2) the number of side-by-side windows in any horizontal bisection of
     the frame.

Even if that knowledge were present, there still remain configurations
where adjusting the frame size can't DTRT.  Consider the following two
examples with slightly "more complex configurations":

Example 1: Split the window of a single-window frame into two windows
one above the other and remove the scrollbar in _one_ of the emanating
windows.  Toggle scroll-bar-mode.  Whatever toggling does to adjust the
frame size it will be wrong for one of the windows.

Example 2: Split the window of a single-window frame into two windows
one above the other.  Now split the upper window into two side-by-side
windows.  If you now toggle scroll-bar-mode and try to correctly account
for the scrollbars in the side-by-side windows, the lower window will
grow or shrink by an additional column.

martin

bug#4543: window-full-height-p

[Glenn Morris]

I'm sorry, I think I may have caused things to get a bit side-tracked.
I would be very happy with your initial solution.

martin rudalics wrote:

> Also I suppose you don't want the return value include the
> minibuffer height.

Yes, you are correct. A window in a frame with a minibuffer should
still be able to be "full-height".

> seems to suggest that (it confuses horizontally and vertically, BTW).

I always have to think about which is which. See, to split a window
"vertically", you draw a horizontal separator across the middle...

bug#4543: window-full-height-p

[martin rudalics]

 > I always have to think about which is which. See, to split a window
 > "vertically", you draw a horizontal separator across the middle...

These terms _are_ confusing.  But I'd also like to get rid of the term
`split-window'.  What a user wants is a new window below or right of
some specified one or maybe at the top or the bottom of the frame.  I'd
prefer `create-window' with a window, size, and placement argument.

martin

bug#4543: window-full-height-p

[Stefan Monnier]

>> seems to suggest that (it confuses horizontally and vertically, BTW).
> I always have to think about which is which. See, to split a window
> "vertically", you draw a horizontal separator across the middle...

It's worse for me: even thinking doesn't help me resolve the ambiguity,
because I think both interpretations make sense.  So I always end up
doing C-h k C-x 2 to see what that operation (which I know well)
is called.

It might be worthwhile trying to come up with a different terminology
that doesn't suffer from that ambiguity.  E.g. use "left-right" for
one and "up-down" for the other.


        Stefan

bug#4543: window-full-height-p

[Glenn Morris]

> martin rudalics wrote:

>> (defun window-full-height-p (&optional window)
>>   (unless window
>>     (setq window (selected-window)))
>>   (= (window-height window)
>>      (window-height (frame-root-window (window-frame window)))))

Please could this be installed?

bug#4543: window-full-height-p

[martin rudalics]

 >>> (defun window-full-height-p (&optional window)
 >>>   (unless window
 >>>     (setq window (selected-window)))
 >>>   (= (window-height window)
 >>>      (window-height (frame-root-window (window-frame window)))))
 >
 > Please could this be installed?

I have a number of problems with this:

(1) The name is problematic.  Note that `window-full-width-p' has no
such problem because when it returns t the window is as wide as the
containing frame.

(2) It might give unexpected results when invoked with the minibuffer
window as argument.  Again `window-full-width-p' has no such problems.

(3) It must be rewritten as soon as someone implements horizontal
scrollbars ;-)

Currently, getting (and setting) the sizes of windows (or frames) is a
mess.  Consider, for example, `split-window': If you use `window-width'
on its argument WINDOW in order to pre-calculate the SIZE argument you
almost certainly end up doing the wrong thing.

Personally, I use a function `window-size' to return the total size of a
window thus avoiding such confusions:

DEFUN ("window-size", Fwindow_size, Swindow_size, 0, 2, 0,
        doc: /* Return total number of lines of WINDOW.
WINDOW defaults to the selected window.  The return values includes any
header- or mode-line.  Optional argument HORIZONTAL non-nil means return
total number of columns of WINDOW.  In this case the return value
includes any scroll-bars of WINDOW.  */)
      (window, horizontal)
      Lisp_Object window, horizontal;
{
   if (!NILP (horizontal))
     return decode_any_window (window)->total_cols;
   else
     return decode_any_window (window)->total_lines;
}

Anyway, if you can think of a better name (which should resolve (1) and
(2)) and a comment wrt (3) feel free to install it.  I'm currently a bit
reluctant to install because my internet connection has been unreliable
over the past weeks.

martin

bug#4543: window-full-height-p

[Stefan Monnier]

>>>> (defun window-full-height-p (&optional window)
>>>> (unless window
>>>> (setq window (selected-window)))
>>>> (= (window-height window)
>>>> (window-height (frame-root-window (window-frame window)))))
>> 
>> Please could this be installed?

> I have a number of problems with this:

> (1) The name is problematic.  Note that `window-full-width-p' has no
> such problem because when it returns t the window is as wide as the
> containing frame.

> (2) It might give unexpected results when invoked with the minibuffer
> window as argument.  Again `window-full-width-p' has no such problems.

I think the name is OK, but the docstring needs to clearly explain what
is the intended behavior (which, I must say, I do not know, but I guess
it's something like "the frame is not split top-down", except we're
talking about a window).  It's more important to make sure that
the docstring is clear and describes a useful behavior, than to make
sure it describes the actual behavior of its current implementation.

> (3) It must be rewritten as soon as someone implements horizontal
> scrollbars ;-)

That's OK: this code is (now) available for 0 efforts, so rewriting it
wouldn't mean that much effort has been wasted.

> Personally, I use a function `window-size' to return the total size of a
> window thus avoiding such confusions:

> DEFUN ("window-size", Fwindow_size, Swindow_size, 0, 2, 0,
>        doc: /* Return total number of lines of WINDOW.
> WINDOW defaults to the selected window.  The return values includes any
> header- or mode-line.  Optional argument HORIZONTAL non-nil means return
> total number of columns of WINDOW.  In this case the return value
> includes any scroll-bars of WINDOW.  */)
>      (window, horizontal)
>      Lisp_Object window, horizontal;
> {
>   if (!NILP (horizontal))
>     return decode_any_window (window)->total_cols;
>   else
>     return decode_any_window (window)->total_lines;
> }

Seems reasonable.  Where do you use it?


        Stefan

bug#4543: window-full-height-p

[martin rudalics]

 > I think the name is OK, but the docstring needs to clearly explain what
 > is the intended behavior (which, I must say, I do not know, but I guess
 > it's something like "the frame is not split top-down", except we're
 > talking about a window).  It's more important to make sure that
 > the docstring is clear and describes a useful behavior, than to make
 > sure it describes the actual behavior of its current implementation.

I could come up with something like

(defun window-full-height-p (&optional window)
   "Return t if WINDOW is as high as the root window of its frame.
WINDOW defaults to the selected window.

This function returns t if and only if there is no other window
above WINDOW and there is either no other window below WINDOW or
the minibuffer window appears right below WINDOW."
   (unless window
     (setq window (selected-window)))
   (= (window-height window)
      (window-height (frame-root-window (window-frame window)))))

but maybe Glenn has a better idea.

 >> Personally, I use a function `window-size' to return the total size of a
 >> window thus avoiding such confusions:
 >
 >> DEFUN ("window-size", Fwindow_size, Swindow_size, 0, 2, 0,
 >>        doc: /* Return total number of lines of WINDOW.
 >> WINDOW defaults to the selected window.  The return values includes any
 >> header- or mode-line.  Optional argument HORIZONTAL non-nil means return
 >> total number of columns of WINDOW.  In this case the return value
 >> includes any scroll-bars of WINDOW.  */)
 >>      (window, horizontal)
 >>      Lisp_Object window, horizontal;
 >> {
 >>   if (!NILP (horizontal))
 >>     return decode_any_window (window)->total_cols;
 >>   else
 >>     return decode_any_window (window)->total_lines;
 >> }
 >
 > Seems reasonable.  Where do you use it?

Most everywhere.  There's no sense reasoning about fringes, margins or
scrollbars when reasoning about sizes of windows or frames.  The only
function I could think of where counting text columns might have been
useful is `split-window' ...

martin

bug#4543: window-full-height-p

[Glenn Morris]

martin rudalics wrote:

> (defun window-full-height-p (&optional window)
>   "Return t if WINDOW is as high as the root window of its frame.
> WINDOW defaults to the selected window.
>
> This function returns t if and only if there is no other window
> above WINDOW and there is either no other window below WINDOW or
> the minibuffer window appears right below WINDOW."

I would just say something like:

  "Return non-nil if WINDOW is not the result of a vertical split.
WINDOW defaults to the selected window.  (This function is not
appropriate for minibuffers.)"

bug#4543: window-full-height-p

[martin rudalics]

 >   "Return non-nil if WINDOW is not the result of a vertical split.
 > WINDOW defaults to the selected window.  (This function is not
 > appropriate for minibuffers.)"

This looks good.  Please install it.

Thanks, martin