[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unfortunate pixel width of one TAB
From: |
Richard Stallman |
Subject: |
Re: Unfortunate pixel width of one TAB |
Date: |
Mon, 27 Dec 2004 23:57:45 -0500 |
> 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.