From: Noam Postavsky <npostavs@gmail.com>
To: Carlos Pita <carlosjosepita@gmail.com>
Cc: Robert Pluim <rpluim@gmail.com>, 32120@debbugs.gnu.org
Subject: bug#32120: 26.1; In python.el tab-width should default to 4
Date: Fri, 29 Mar 2019 23:17:14 -0400 [thread overview]
Message-ID: <87pnq9830l.fsf@gmail.com> (raw)
In-Reply-To: <CAELgYhcHZBfmhhjQS5WFzKhzFNpzs4xhRJM3dGfac8+z7KsOMg@mail.gmail.com> (Carlos Pita's message of "Wed, 11 Jul 2018 14:25:57 -0300")
Carlos Pita <carlosjosepita@gmail.com> writes:
>> Right. What is your justification for wanting this to be 4?
>> Python generally discourages tabs, but when they are present, seems to
>> follow the historical convention mapping them to 8 spaces.
>> https://docs.python.org/3/reference/lexical_analysis.html#indentation
>>
>> Tabs are replaced (from left to right) by one to eight spaces such
>> that the total number of characters up to and including the
>> replacement is a multiple of eight (this is intended to be the same
>> rule as used by Unix).
> Sure, I don't want to enter tab characters at all, I just want to
> rigidly indent using 4-space tab stops. And setting tab-width to 4 and
> indent-tabs-mode to nil makes C-x Tab S-Right do just that.
> Some months later, I'm insisting on this.
>
> I don't see any point in setting the default to 8 when:
>
> 1. PEP 8 clearly states: use 4 spaces per indentation level.
> 2. Python mode specific rigid indentation mechanism defaults to 4 spaces.
>
> AFAICS the only thing you get by setting tab-width to 8 is
> incompatibility of emacs standard rigid indentation mechanism (M-x
> Tab) with both 1 and 2. I think it's important to play well with
> standard facilities (despite python mode providing it's own variant)
> and, in any case, there is no good reason, no trade off, not to do it.
Seems clear to me that the proper solution is simply to rebind C-x Tab
S-left/right to use python-indent-shift-left/right. That will solve the
actual problem you experience, without incorrectly showing any existing
tab charaters as 4 spaces.
next prev parent reply other threads:[~2019-03-30 3:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-10 22:05 bug#32120: 26.1; In python.el tab-width should default to 4 Carlos Pita
2018-07-11 9:33 ` Robert Pluim
2018-07-11 13:50 ` Carlos Pita
2018-07-11 17:19 ` Glenn Morris
2018-07-11 17:25 ` Carlos Pita
2018-07-11 20:15 ` Glenn Morris
2018-07-11 20:23 ` Carlos Pita
2019-03-30 3:17 ` Noam Postavsky [this message]
2019-03-30 3:25 ` Carlos Pita
2019-03-30 12:52 ` Noam Postavsky
2019-03-30 13:33 ` Carlos Pita
2019-03-30 13:37 ` Carlos Pita
2019-01-07 3:13 ` bug#32120: Carlos Pita
2019-09-13 11:03 ` bug#32120: 26.1; In python.el tab-width should default to 4 Stefan Kangas
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=87pnq9830l.fsf@gmail.com \
--to=npostavs@gmail.com \
--cc=32120@debbugs.gnu.org \
--cc=carlosjosepita@gmail.com \
--cc=rpluim@gmail.com \
/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).