tab-width documentation: no mention of special handling of 0

tab-width documentation: no mention of special handling of 0

[Edward Welbourne]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-03-22 on raven, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The help on tab-width says: <quote>

tab-width's value is 0
Local in buffer *grep*; global value is 8

Documentation:
*Distance between tab stops (for display of tab characters), in columns.
Automatically becomes buffer-local when set in any fashion.

</quote> but, when tab-width is set to 0, the default, 8, gets used in
its place (quite sensible in its own way :^) rather than hiding all
tab characters. [I was using it on M-x grep-find's output so I could
read the code found without it mostly being off-screen to my right,
what with the long filenames being added before the often deep
indentation ... a tab-width of 1 does adequately, though.]

The documentation of tab-width should mention the special handling of
0; or 0 should really be handled the way the doc says it will be.

This is not a life-threatening, or even urgent, bug !

Recent input:
M-x M-p <return> M-p <return> 1 <return> M-x M-p <return> 
M-p <return> 0 <return> M-x M-p <return> M-p <return> 
1 <return> C-x 3 C-h v t a b - w i d t h <return> M-x 
M-p <return> M-p <return> 0 <return> C-n C-n C-n C-n 
C-M-f C-M-f C-M-f C-f C-f C-f C-f C-p C-b C-b C-b C-b 
C-b C-b C-b C-b C-n C-b C-f C-f M-x M-p <return> M-p 
<return> 1 <return> M-x M-p <return> M-p <return> 0 
<return> C-h v M-p <return> M-x M-p <return> M-p <return> 
1 <return> M-x r e p o <tab> r <tab> <return>

Recent messages:
Mark set [2 times]
Making completion list...
Mark saved where search started
Mark set
Mark saved where search started
Mark set [2 times]
Loading pp...done
Type C-x 4 b RET to restore the other window.  C-M-v to scroll the help.
Making completion list...
Loading emacsbug...done

Re: tab-width documentation: no mention of special handling of 0

[Richard Stallman]

    The documentation of tab-width should mention the special handling of
    0; or 0 should really be handled the way the doc says it will be.

There is no need to document everything a program does to cope
with unreasonable data values, and trying to do so would just
be clutter.  But thanks for raising the issue.