From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Unfortunate pixel width of one TAB Date: Mon, 27 Dec 2004 22:26:36 +0900 (JST) Message-ID: <200412271326.WAA20143@etlken.m17n.org> References: <41B331A7.2010406@iue.tuwien.ac.at> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1104154053 24398 80.91.229.6 (27 Dec 2004 13:27:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 27 Dec 2004 13:27:33 +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 Mon Dec 27 14:27:25 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 1CiuuC-00006I-00 for ; Mon, 27 Dec 2004 14:27:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Civ50-0003BT-4t for ged-emacs-devel@m.gmane.org; Mon, 27 Dec 2004 08:38:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Civ4e-0003At-Oh for emacs-devel@gnu.org; Mon, 27 Dec 2004 08:38:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Civ4e-0003AW-2g for emacs-devel@gnu.org; Mon, 27 Dec 2004 08:38:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Civ4d-0003AT-Ui for emacs-devel@gnu.org; Mon, 27 Dec 2004 08:38:12 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CiutU-0002nr-7X; Mon, 27 Dec 2004 08:26:43 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.12.3/8.12.3/Debian-7.1) with ESMTP id iBRDQbWL025177; Mon, 27 Dec 2004 22:26:37 +0900 Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id iBRDQaq22034; Mon, 27 Dec 2004 22:26:36 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id WAA20143; Mon, 27 Dec 2004 22:26:36 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sun, 26 Dec 2004 23:10:11 -0500) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3.50 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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:31458 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31458 In article , Richard Stallman writes: > When using a proportional font the pixel width of one TAB is "tab-width > times average_char_pixel_width". When editing files which contain tabs > and spaces for indenting, this leads to some bad alignment. > If would be nice if the pixel width of one TAB could be set to something > like "tab-width times space_pixel_width". > 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. See this example lines (the first line has three spaces after "wwwww", and the next line has one TAB after "wwwww", the last line is just TAB and "a"): wwwww a wwwww a a Provided that space width is 5 pixels and "w" width is 10 pixels, the "a" of the first line is at 65 pixels from the left, but the "a" of the second line is at 80 pixels from the left, and the "a" of third lines is at 40 pixels from the left. > This ought to be an easy change, but I would have to spend half an > hour learning the background knowledge to make it. > Does anyone know enough about accessing fonts > to be able to do this change quickly? Handa, can you do > it quickly? > Please respond if you take care of this. Even if that method doesn't solve the alignment problem, I agree that current way of tab-width calculation is not good. Tab width is calculated as this (x_produce_glyphs): int tab_width = it->tab_width * FRAME_COLUMN_WIDTH (it->f); and, x_new_font sets the column width (i.e. the canonical character width) of a frame as this: FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f)); and FONT_WIDTH is defined as this: #define FONT_WIDTH(f) ((f)->max_bounds.width) That's why when we change the default font to a proportional font, the frame gets too wide. 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. 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. This change will result in not perfect but more adequate tab width for proportional fonts. But, shouldn't we postpone such a change until the next release? --- Ken'ichi HANDA handa@m17n.org