Re: Unfortunate pixel width of one TAB

[Richard Stallman]

    > Do you mean, the width of a space in the current font?
    > That seems like the right behavior for it.

    I don't think that solves the problem.

You're talking about a different problem, which is more difficult.
It deals with a broader range of cases.

You're right that adjusting the space with correctly
won't solve the problem you have in mind.
But it will solve a smaller problem, and it is correct to do.

    When we change FONT_WIDTH to return the width of space
    glyph, the current tab width problem will be solved.  But,
    as FRAME_COLUMN_WIDTH is also a base of calculating the
    frame width, such a change leads to too narrow frame width.

So let's not change FONT_WIDTH.
We can change the computation for tabs
without changing FONT_WIDTH.

Or we can change FONT_WIDTH, but also change FRAME_COLUMN_WIDTH
so that it no longer uses FONT_WIDTH, so that FRAME_COLUMN_WIDTH
will behave the same as now.

    Perhaps, the following modification will do:

    (1) Make FONT_WIDTH return the average width of a font.
    This will result in the more adequate frame width.

    (2) Make a new macro FONT_SPACE_WIDTH that returns the width
    of space glyph of the font of the frame.  We can make a new
    member `space_width' in the struct frame and make x_new_font
    sets it value.

    (3) Calculate tab width based on FONT_SPACE_WIDTH.

That might be good.  Or we could do this without changing FONT_WIDTH.
That means do just 2 and 3, not 1.

    But, shouldn't we postpone such a change until the next
    release?

This is a bug fix.  We should do it now.