unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Gustavo Barros <gusbrs.2016@gmail.com>
To: Stefan Kangas <stefan@marxist.se>
Cc: 48058@debbugs.gnu.org
Subject: bug#48058: tab-width's docstring
Date: Thu, 29 Apr 2021 21:44:26 -0300	[thread overview]
Message-ID: <87r1issis5.fsf@gmail.com> (raw)
In-Reply-To: <CADwFkmkwiSXt1Wnt74qTxbaraSjM1Y8d9PyFOdsU2Cr17cU9wA@mail.gmail.com>

Hi Stefan,

On Thu, 29 Apr 2021 at 19:53, Stefan Kangas <stefan@marxist.se> wrote:

> tags 48058 + patch
> thanks
>
> Gustavo Barros <gusbrs.2016@gmail.com> writes:
>
>>>> Perhaps we could change the docstring note along the lines of:
>>>>
>>>>     NOTE: Some major modes use this variable to determine an
>>>>     indentation
>>>>     step, but Emacs itself only uses this to display the width of a
>>>>     TAB
>>>>     character.
>>>>
>>>> Would something like that make sense?
>>>
>>> Something like that, yes.  Perhaps just making the original text 
>>> less
>>> definitive will do as well.
>>
>> Just chiming in to say I'm following the discussion attentively, but
>> have nothing to add.  Both Stefan's and Eli's suggestions look like
>> improvements to me.  And I'll be happy with what you come up with.
>
> How does the attached patch look?

Thanks, I do think it is an improvement, and had granted that in my 
previous message.  And I also think the role I can play in this 
discussion is to provide some perspective on why it is difficult to get 
this docstring right for someone less acquainted with the fine prints of 
how indentation works.  With that in mind, I tried to come up with 
something which would make it more clear to one such person.  I hope I 
didn't get it wrong in so doing.  It is the following:

"`tab-width' controls the display width of a TAB character and the width 
of a tab step if it uses spaces instead of TAB characters, according to 
user options and major-mode settings.  In most major modes the 
indentation step is derived from the langage's semantics and is 
independent of `tab-width', but some major-modes use it to control the 
size of an indentation step."

Three things I hope to have added there which are not in the current 
docstring or in your patch.  It is not just major-mode, user options 
influence too how `tab-width' is used.  It is also not just 
"indentation", since a manual tab added by `tab-to-stop' or by 
`indent-for-tab-command' (if `tab-always-indent' is nil) will use 
`tab-width'.  It is also not just "display of TAB character width", 
since `tab-width' will determine the number of spaces inserted if 
`indent-tabs-mode' is nil.  And I grant I may be wrong in any number of 
these three things.  But if I'm not, I do think they deserve mention.

Again, this is not a "proposal", this is just what I miss there that I 
believe makes it hard to get what `tab-width' does (if you don't already 
know).  And I think one of the things I failed to understand correctly, 
even when I opened this report, and the discussion with Eli helped me 
get a little better, is the term "indentation step".  If I understand it 
better now, it is aimed at referring only to "major-mode specific 
indentation of a semantic character".  Thus I included the term "tab 
step" as opposed to "indentation step", meaning a manually added "tab" 
(character or corresponding spaces).  This may seem obvious to most on 
this list, but I missed my step (pun intended) right there.  And I 
cannot even claim noobness (though I'll probably be guilty as charged).

Best regards,
Gustavo.





  reply	other threads:[~2021-04-30  0:44 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
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 [this message]
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=87r1issis5.fsf@gmail.com \
    --to=gusbrs.2016@gmail.com \
    --cc=48058@debbugs.gnu.org \
    --cc=stefan@marxist.se \
    /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).