unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Subject: Code cleanup -- inconsistent "width" and "height" etc.
Date: 10 Apr 2003 03:51:44 +0200	[thread overview]
Message-ID: <5xhe97dsr3.fsf@kfs2.cua.dk> (raw)


Looking through the C code, the words width and height are not used
consistently.  Sometimes they are in columns/lines (canonical units),
and sometimes they are in pixels.

Similar for top/left specs (they are in pixels for a frame and
in canonical units for a window).

Some variables/macros like FRAME_SCROLL_BAR_COLS and
FRAME_SCROLL_BAR_WIDTH are pretty confusing, as they are both measured
in columns, but the first gives the "configured width" unconditionally
while the second may return zero if scroll bars are not shown, and
otherwise equals FRAME_SCROLL_BAR_COLS...

And things like FRAME_WIDTH and FRAME_WINDOW_WIDTH are also confusing.
Both are measured in columns, but the former does not include the
width of scroll bars and fringes.

Compare this to "WINDOW_DISPLAY_PIXEL_WIDTH" which is another way of
naming a macro which does not include scroll bars or fringes (thus
implicating that a macro named WINDOW_PIXEL_WIDTH would return the
total width of the window).


I would like to fix such discrepancies as follows:

Things measured in columns/lines are named as _CANON_WIDTH and
_CANON_HEIGHT resp., while things measured in pixels are named as
_PIXEL_WIDTH and _PIXEL_HEIGHT resp.

To differentiate between macros which return a value unconditionally,
and macros which return the value only if some condition, I propose
to name them as e.g. FRAME_CONFIG_SCROLL_BAR_CANON_WIDTH and
FRAME_ACTUAL_SCROLL_BAR_CANON_WIDTH.

For things which differs by including or not including e.g. scroll
bars and fringes I propose using e.g. FRAME_TEXT_CANON_WIDTH (or
FRAME_DISPLAY_CANON_WIDTH) and FRAME_TOTAL_CANON_WIDTH.


It is a tedious work to clean this up, but the current state of the
source code is pretty messy, and cleaning it up would make an
important step (I think) towards lifting some of the restrictions we
currently have on measuring everything in columns and lines (since it
makes the code clearer to read, and thus easier to change correctly).

DWYT?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

             reply	other threads:[~2003-04-10  1:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-10  1:51 Kim F. Storm [this message]
2003-04-10  0:11 ` Code cleanup -- inconsistent "width" and "height" etc Kenichi Handa
2003-04-10  1:32 ` Miles Bader
2003-04-10 13:50   ` Kim F. Storm
2003-04-10 12:10     ` Kenichi Handa
2003-04-11  0:08       ` Kim F. Storm
2003-04-10 23:27         ` Miles Bader
2003-04-11  0:34         ` Kenichi Handa
2003-04-11 23:45           ` Richard Stallman
2003-04-12  2:19             ` Kenichi Handa
2003-04-11  8:51     ` Richard Stallman

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=5xhe97dsr3.fsf@kfs2.cua.dk \
    --to=storm@cua.dk \
    /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).