emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Incorrect TAB width


From: Bertrand Petit
Subject: Incorrect TAB width
Date: Sun, 12 Jun 2005 15:22:53 +0200
User-agent: Mutt/1.4.2i

        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: tab-bug.el
Description: Text document

Attachment: pgpkY36wXKOkk.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]