From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gustavo Barros Newsgroups: gmane.emacs.bugs Subject: bug#48058: tab-width's docstring Date: Tue, 27 Apr 2021 11:40:18 -0300 Message-ID: <87wnsnkcz1.fsf@gmail.com> References: <87a6pj50u6.fsf@gmail.com> <83eeevj0kt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4895"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.15; emacs 27.2 Cc: 48058@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 27 16:41:38 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbOuA-00010n-FX for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Apr 2021 16:41:38 +0200 Original-Received: from localhost ([::1]:45224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbOu9-0004X8-HR for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Apr 2021 10:41:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47302) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbOta-0004VS-QV for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 10:41:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38932) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lbOta-000213-03 for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 10:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lbOtZ-0002JI-SZ for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 10:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gustavo Barros Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Apr 2021 14:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48058 X-GNU-PR-Package: emacs Original-Received: via spool by 48058-submit@debbugs.gnu.org id=B48058.16195344308835 (code B ref 48058); Tue, 27 Apr 2021 14:41:01 +0000 Original-Received: (at 48058) by debbugs.gnu.org; 27 Apr 2021 14:40:30 +0000 Original-Received: from localhost ([127.0.0.1]:50478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbOt3-0002IR-Sx for submit@debbugs.gnu.org; Tue, 27 Apr 2021 10:40:30 -0400 Original-Received: from mail-qk1-f169.google.com ([209.85.222.169]:40863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbOt2-0002IE-LN for 48058@debbugs.gnu.org; Tue, 27 Apr 2021 10:40:29 -0400 Original-Received: by mail-qk1-f169.google.com with SMTP id q136so39202364qka.7 for <48058@debbugs.gnu.org>; Tue, 27 Apr 2021 07:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:references:user-agent:from:to:cc:subject:in-reply-to :message-id:date:mime-version; bh=d+QZM1v+psn9OyJ/kufnVZBqoROtu9TjyGJIj/2kLcc=; b=D6HyXAZ8kocFNNVEKez097FgkM0EsZUy6RPqZtQKPCih8jeSHf1JDjlLUE56uUJIQc NUbsYElhKJDgJX/PRJWgt3IEsdHxOuc7JbwR6WYYsgFhYMT6e6/VenxMQhW3OVKbN6hI wK4LSsBiwkLzlvxyRqyTs238b0Ccy6xscuX6RMKy0Z5xFr4i7WvUfFDyPEw37b7UggNi mEQjzJVANDEQ/23DtvcwgSUAfbQPwESjqIsKmtJEFuAdb94U7xLUaMJ/BLF55KBykRrN rEBlV4osG+4sSp0bd7A0s7uPLlGL3hcE26YG5v1uLel2g8gs+txPzEn5rdinAx48npcF 61fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version; bh=d+QZM1v+psn9OyJ/kufnVZBqoROtu9TjyGJIj/2kLcc=; b=An1a0C0u8kYAsbGfnnKl7CJxuNWVipuZ1Hsl5AkAs8B8z1KiWFG+SMU2TowB+IJtxU wj73f80xTMUuwwLUPxUKt2sXMyGYTsOJOZN6B8AEoVVP1ma6ymaYMJHRqu0fGF94LLe4 WSpdRnHLDlPSLMEQHNMRwSc8OYEsbYrIElKSzvTNh9axJy6DhIRxoOZgoll1uqEm1R8j +xJ9ba8Wnq4vmzacikfmffqqeLqYCt0Ui6weCMSgnF1vrufdi9SaIvTEBCJ+kJILSZjY k3oiE/eMeoXOS8P9Es55dRjhj+IOV3pz8spZdBixRsKfzHhD9r8r9YNOmrSVn/KPlVXQ C/Tw== X-Gm-Message-State: AOAM532bXKVjRPoSlwrZq7P7Pr1Ua2QWEvzkMMIYFdTl/7627qgjBqvK cHhgVwd3GSOnGmhuJLV55vH4dQJTUfGxaw== X-Google-Smtp-Source: ABdhPJxxO1Y8TbGyyztUOJipx/CMmTjcpRYw2+dn5TQ7uJkfJbaJmambyf+ynOytkk5/PWR3+5KdAQ== X-Received: by 2002:a37:46d5:: with SMTP id t204mr22716500qka.211.1619534422745; Tue, 27 Apr 2021 07:40:22 -0700 (PDT) Original-Received: from gusbrs-laptop ([212.102.61.109]) by smtp.gmail.com with ESMTPSA id c2sm3029519qkk.2.2021.04.27.07.40.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Apr 2021 07:40:22 -0700 (PDT) In-reply-to: <83eeevj0kt.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:205020 Archived-At: Hi Eli, On Tue, 27 Apr 2021 at 10:53, Eli Zaretskii wrote: >> From: Gustavo Barros >> 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.