GNU bug report logs - #48058
tab-width's docstring

Previous Next

Package: emacs;

Reported by: Gustavo Barros <gusbrs.2016 <at> gmail.com>

Date: Tue, 27 Apr 2021 13:12:02 UTC

Severity: minor

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: 48058 <at> debbugs.gnu.org
Subject: bug#48058: tab-width's docstring
Date: Tue, 27 Apr 2021 18:02:05 +0300
> From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
> Cc: 48058 <at> debbugs.gnu.org
> Date: Tue, 27 Apr 2021 11:40:18 -0300
> 
> Let's say `emacs-lisp-mode', and let's say I've `indent-tabs-mode' set 
> to nil.  Calling `tab-to-tab-stop' will actually insert 8 spaces in my 
> buffer, as per the default `tab-width'.  If `tab-always-indent' is nil, 
> this also extends to `indent-for-tab-command'.  There is no "TAB 
> character" involved, and also no issue about what is its "display 
> width".  As far as I understand it, what `tab-width' is determining is 
> precisely the "indentation step".  Or am I getting this wrong?

This is major mode dependent.  Try the same in C mode, for example,
and you will see the difference.  The function that indents the line
is specific to the major mode.  If you want to understand why you see
what you see in emacs-lisp-mode, look at lisp-indent-line.

But even in emacs-lisp-mode, what did you expect to happen instead?
(indent-tabs-mode, btw, just uses spaces instead of TABs, but it still
inserts the amount of spaces equivalent to a TAB where otherwise a TAB
would have been inserted.)




This bug report was last modified 4 years and 23 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.