[Top][All Lists]

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

Code cleanup -- inconsistent "width" and "height" etc.

From: Kim F. Storm
Subject: Code cleanup -- inconsistent "width" and "height" etc.
Date: 10 Apr 2003 03:51:44 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

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

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

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

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


Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

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