unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Gustavo Barros <gusbrs.2016@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 48058@debbugs.gnu.org
Subject: bug#48058: tab-width's docstring
Date: Tue, 27 Apr 2021 11:40:18 -0300	[thread overview]
Message-ID: <87wnsnkcz1.fsf@gmail.com> (raw)
In-Reply-To: <83eeevj0kt.fsf@gnu.org>

Hi Eli,

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

>> From: Gustavo Barros <gusbrs.2016@gmail.com>
>> Date: Tue, 27 Apr 2021 10:11:30 -0300
>> 
>> In Emacs 27.2 the docstring for `tab-width' reads:
>> 
>> "Distance between tab stops (for display of tab characters), in 
>> columns. 
>> NOTE: This controls the display width of a TAB character, and not the 
>> size of an indentation step."
>> 
>> But this seems to contradict to the ubiquitous role in actual 
>> indentation the option currently plays.  It is used by `insert-tab' 
>> directly.  `tab-to-tab-stop' uses it if `tab-stop-list' is nil, as it 
>> is 
>> by default.  `indent-relative' may use `tab-to-tab-stop'.  And, 
>> through 
>> `indent-relative' and `insert-tab', `tab-width' also affects 
>> `indent-for-tab-command'.
>
> Can you explain where you see the contradiction, exactly?
>
> If the indentation command (which is subject to major-mode
> differences, btw) actually inserts one or more TAB characters, then
> those TABs will look on display according to tab-width, of course, and
> that's not in any contradiction to what the doc string says.  The doc
> string says something different: that an indentation step is not
> necessarily the number of columns that tab-width says, because a major
> mode can decide that it indents with spaces instead, for example
> (texinfo-mode, for example, does precisely that).

So indeed, I might be missing something.  But I really cannot combine 
what the docstring says and what the option actually does, so I'll try 
to explain why I think that's the case.  And I'll either learn something 
or, if my confusion may potentially affect other people, leave the 
docstring clearer somehow.

The docstring explicitly says `tab-width' "controls the display width of 
a TAB character, and not the size of an indentation step".  And btw, I 
know the actual behavior of indentation is subject to major-mode 
differences.  And also of some user options.

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?

As far as I get, what `tab-width' is doing it is being used as the 
default width of an indentation step regardless of whether this 
indentation is done with a TAB character or with spaces.  And, of 
course, this also matches the display width of the TAB character.  But 
the docstring reads to me as explicitly denying the first role.

Does this make sense?  Or, at least, could I convey why I am confused by 
the docstring?

Best regards,
Gustavo.





  reply	other threads:[~2021-04-27 14:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 13:11 bug#48058: tab-width's docstring Gustavo Barros
2021-04-27 13:53 ` Eli Zaretskii
2021-04-27 14:40   ` Gustavo Barros [this message]
2021-04-27 15:02     ` Eli Zaretskii
2021-04-27 15:14       ` Gustavo Barros
2021-04-27 15:32         ` Eli Zaretskii
2021-04-29 17:05           ` Stefan Kangas
2021-04-29 17:35             ` Eli Zaretskii
2021-04-29 20:14               ` Gustavo Barros
2021-04-29 22:53                 ` Stefan Kangas
2021-04-30  0:44                   ` Gustavo Barros
2021-04-30  7:18                   ` Eli Zaretskii
2021-04-30 10:20                     ` Stefan Kangas
2021-04-30 10:49                       ` Eli Zaretskii
2021-04-30 12:00                         ` Gustavo Barros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnsnkcz1.fsf@gmail.com \
    --to=gusbrs.2016@gmail.com \
    --cc=48058@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).