[Top][All Lists]

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

bug#4543: window-full-height-p

From: Eli Zaretskii
Subject: bug#4543: window-full-height-p
Date: Fri, 25 Sep 2009 16:38:54 +0300

> Date: Fri, 25 Sep 2009 14:59:51 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 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.

reply via email to

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