bug#48058: tab-width's docstring

[Gustavo Barros]

On Tue, 27 Apr 2021 at 12:02, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Gustavo Barros <gusbrs.2016@gmail.com>
> > Cc: 48058@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.)

I didn't expect anything different to happen.  It is just that 
`tab-width' is determining more than just the "display width of the TAB 
character": if you (or the major-mode for you) are indenting with spaces 
the content of the buffer is different according to `tab-width', it not 
just a matter of "display".

But I see your point, and perhaps the docstring is clearer to someone 
more seasoned than myself, and avoids other pitfalls along the way which 
I do not even see.  Hopefully, it will feel just as clear to me someday. 
;-)

Thanks for answering, and feel free to close.

Best regards,
Gustavo.