From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Unfortunate pixel width of one TAB Date: Mon, 27 Dec 2004 23:57:45 -0500 Message-ID: References: <41B331A7.2010406@iue.tuwien.ac.at> <200412271326.WAA20143@etlken.m17n.org> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1104210276 30359 80.91.229.6 (28 Dec 2004 05:04:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Dec 2004 05:04:36 +0000 (UTC) Cc: gritsch@iue.tuwien.ac.at, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 28 06:04:30 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cj9X4-0002TP-00 for ; Tue, 28 Dec 2004 06:04:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cj9ht-0006dd-QM for ged-emacs-devel@m.gmane.org; Tue, 28 Dec 2004 00:15:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cj9ha-0006bu-37 for emacs-devel@gnu.org; Tue, 28 Dec 2004 00:15:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cj9hW-0006Zp-TM for emacs-devel@gnu.org; Tue, 28 Dec 2004 00:15:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cj9hW-0006ZW-IA for emacs-devel@gnu.org; Tue, 28 Dec 2004 00:15:18 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cj9W3-0007Ot-Cj for emacs-devel@gnu.org; Tue, 28 Dec 2004 00:03:27 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Cj9QX-0004ro-6T; Mon, 27 Dec 2004 23:57:45 -0500 Original-To: Kenichi Handa In-reply-to: <200412271326.WAA20143@etlken.m17n.org> (message from Kenichi Handa on Mon, 27 Dec 2004 22:26:36 +0900 (JST)) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31511 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31511 > 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.