unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 4543@emacsbugs.donarmstrong.com
Subject: bug#4543: window-full-height-p
Date: Fri, 25 Sep 2009 16:38:54 +0300	[thread overview]
Message-ID: <83my4jta8h.fsf@gnu.org> (raw)
In-Reply-To: <4ABCBEC7.70901@gmx.at>

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





  reply	other threads:[~2009-09-25 13:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24  3:28 bug#4543: window-full-height-p Glenn Morris
2009-09-24  7:04 ` martin rudalics
2009-09-25  6:18   ` Glenn Morris
2009-09-25  7:40     ` martin rudalics
2009-09-25  9:27       ` Eli Zaretskii
2009-09-25 12:59         ` martin rudalics
2009-09-25 13:38           ` Eli Zaretskii [this message]
2009-09-25 15:04             ` martin rudalics
2009-09-25 15:55               ` Eli Zaretskii
2009-09-25 19:05                 ` martin rudalics
2009-09-25 20:16               ` Stefan Monnier
2009-09-26  9:45                 ` martin rudalics
2009-09-25 14:37           ` Stefan Monnier
2009-09-26  9:45             ` martin rudalics
2009-09-26 11:28               ` Eli Zaretskii
2009-09-26 13:41                 ` martin rudalics
2009-09-26 16:27                   ` Eli Zaretskii
2009-09-26 19:01                     ` martin rudalics
2009-09-26 20:17                       ` Eli Zaretskii
2009-09-27  7:49                         ` martin rudalics
2009-09-25 17:23       ` Glenn Morris
2009-09-25 19:05         ` martin rudalics
2009-09-25 20:10         ` Stefan Monnier
2009-10-02  7:12     ` Glenn Morris
2009-10-02  8:39       ` martin rudalics
2009-10-02 13:30         ` Stefan Monnier
2009-10-02 15:56           ` martin rudalics
2009-10-02 18:37             ` Glenn Morris
2009-10-03  8:20               ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83my4jta8h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=4543@emacsbugs.donarmstrong.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).