Incorrect TAB width

Incorrect TAB width

[Bertrand Petit]

[-- Attachment #1.1.1: Type: text/plain, Size: 3211 bytes --]


	Hello,

	I recently upgraded my X11 server from XFree86 4.2.0 to 4.5.0
and noticed that emacs' display has some indentation problems. I
located the trouble to the displayed width of a tabulation.

	The following code (also attached) demonstrates the bug:

(setq default-frame-alist
      '((font . "-b&h-luxi mono-medium-r-normal-*-*-140-*-*-m-*-iso8859-1")))

(insert (make-string tab-width ?\ ))
(insert (format "| %d spaces\n" tab-width))
(insert "	| one tabulation\n")

when loaded at startup (emacs -q -l tab-bug.el), the on-screen buffer
should display two vertically aligned pipes, they are not! The pipe
following the tabulation is on the right of the pipe following eight
spaces. It is illustrated in the joined partial screen capture.

	For reference I compared the behavior of xedit. Set the same
font for the main xedit widget with the following command-line:

echo "xedit.paned.hpane.vpane.editWindow.textSink.font: \
-b&h-luxi mono-medium-r-normal-*-*-140-*-*-m-*-iso8859-1" | xrdb

(Do not perform this change using editres as xedit does not update
it's measurement of the tabulation width when the text widget font is
changed). Type height spaces pipe newline tab pipe. The two pipes are
vertically alligned as expected.

	The bug was also reproduced with the following font logical
descriptors:

-ibm-courier-medium-r-normal-*-*-140-*-*-m-*-iso8859-1
-bitstream-bitstream vera sans mono-medium-r-normal-*-*-140-*-*-m-*-iso8859-1
-monotype-courier new-medium-r-normal-*-*-140-*-*-c-*-iso8859-1
-b&h-lucida console-medium-r-normal-*-*-140-*-*-c-*-iso8859-1
-b&h-lucida sans typewriter-medium-r-normal-*-*-140-*-*-m-*-iso8859-1
-jmk-neep-medium-r-normal-*-*-140-*-*-c-*-iso8859-1

but not with the following XLFDs:

-schumacher-clean-medium-r-normal-*-*-120-*-*-c-*-iso8859-1
-adobe-courier-medium-r-normal-*-*-140-*-*-m-*-iso8859-1
-adobe-courier-medium-r-normal-*-*-150-*-*-m-*-iso8859-1
-misc-fixed-medium-r-semicondensed-*-*-120-*-*-c-*-iso8859-1
-sony-fixed-medium-r-normal-*-*-150-*-*-c-*-iso8859-1
-bitstream-terminal-medium-r-normal-*-*-140-*-*-c-*-iso8859-1

	It seems that bitmap fonts does not trigger the bug while
vector-based fonts do trigger it. There is one exception: the Courier
from Adobe.

	The bug was no there with XFree86 4.2.0, it appeared while
using emacs 21.3 after updating to XFree86 4.5.0. I then updated emacs
to 21.4a and it is still there. I also observed it on a host running
XFree86 4.3.0 and emacs 21.3. The 4.3.0 display server has direct
access to the fonts while the 4.5.0 display uses the X font server
coming from the same build.

	I also compiled emacs version 22.0.50 and also observed the
bug on this HEAD version on the XFree 4.5.0 server.

	Where this bug comes from? The X11 server or emacs? I inclined
to think that the origin is emacs as xedit and xterm are not affected.

-- 
%!PS
297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100
180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180
0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont
240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage

[-- Attachment #1.1.2: tab-bug.el --]
[-- Type: text/plain, Size: 218 bytes --]


(setq default-frame-alist
      '((font . "-b&h-luxi mono-medium-r-normal-*-*-140-*-*-m-*-iso8859-1")))

(insert (make-string tab-width ?\ ))
(insert (format "| %d spaces\n" tab-width))
(insert "	| one tabulation\n")

[-- Attachment #1.2: Type: application/pgp-signature, Size: 187 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Incorrect TAB width

[Richard Stallman]

This is an important problem, and I think we need to fix it.  I cannot
reproduce it myself, since I don't have a new version of X.

It surprises me that any any version of X can tell whether the Emacs
buffer contains tabs or spaces.  Emacs handles tabs by displaying
spaces (or at least, it used to); by the time the X server gets
involved, there should be no difference.  If Emacs even looks
at the fonts' width for tab, that seems to be a bug.

So if you can find out where Emacs even pays attention to what the
font says or does for a tab character, that should be a start at
debugging this problem.

Re: Incorrect TAB width

[Bertrand Petit]

[-- Attachment #1.1: Type: text/plain, Size: 2038 bytes --]

On Mon, Jun 13, 2005 at 11:03:14AM -0400, Richard Stallman wrote:
> This is an important problem, and I think we need to fix it.

	I agree. This bug leads to incorrect indentations. I am not
alone with this trouble, a message in emacs-devel on the 17th of
December, 2004, also describes the same problem:

<URL:http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00650.html>

>  I cannot reproduce it myself, since I don't have a new version of
> X.

	We can arrange for a private access to my font server if it
may help you.

> It surprises me that any any version of X can tell whether the Emacs
> buffer contains tabs or spaces.

	I suppose something has changed in the way the font metrics
are conveyed to the display client. 

> If Emacs even looks at the fonts' width for tab, that seems to be a
> bug.

	It seems so. The tabulation width calculation method was
reported on the 27th of December, 2004, by Kenichi Handa:

  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)

<URL:http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00884.html>

> So if you can find out where Emacs even pays attention to what the
> font says or does for a tab character, that should be a start at
> debugging this problem.

	For emacs 21.4a the tab width calculation is located for X11
displays at the 1982nd ligne of xdisp.c and at the 2200th line of
w32disp.c for ms-windows.

-- 
%!PS
297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100
180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180
0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont
240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage

[-- Attachment #1.2: Type: application/pgp-signature, Size: 187 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Incorrect TAB width

[Richard Stallman]

	    We can arrange for a private access to my font server if it
    may help you.

It would not be feasible for me to access it, but maybe someone else
here can.

	    It seems so. The tabulation width calculation method was
    reported on the 27th of December, 2004, by Kenichi Handa:

      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)

As I thought, it is not using the width of tab in the font.  However,
I wonder if the problem is that the width of canonical character width
of the font does not equal the width of a space?