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

[Kenichi Handa]

In article <address@hidden>, address@hidden (Kim F. Storm) writes:
>>  But, as I wrote, Lisp APIs are already using
>>  ...-width/...-height for columns and lines.  Even if we
>>  implement pixel-base APIs in the future, we can't change the
>>  current ones, then we'll use ...-pixel-width...-pixel-height
>>  for the new APIs.  In that case, having a different
>>  convention in C code is not good.

> So there is no hope of cleaning up the current mess ?

> How can we ever make progress towards removing the column/lines
> limitation on frame and window dimensions if we cannot find
> a way to clean up the current naming mess?

Now we have two problems as to the naming; inconsistency and
unclearness.  I think fixing the former is more important
than fixing the latter.

Always using _WIDTH (or -width) for columns and _PIXEL_WIDTH
(or -pixel-width) for pixels is to fix inconsistency, but
using _COLS or _CANON_WIDTH for columns is to fix
unclearness.

You wrote:
> 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.

It seems that this CONFIG vs ACTUAL itself is a good idea
for fixing unclearness without introducing inconsistency.

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

This TEXT vs TOTAL is also a good idea.

By the way, I've just found this inconsistency.
frame-width -> not including scroll bars and fringes
frame-pixel-width -> including them

Perhaps, we should make them obsolete aliases of
frame-text-width and frame-total-pixel-width respectively.

---
Ken'ichi HANDA
address@hidden