various issues when trying to work on code that uses tabs
See original GitHub issueThese are small, separate, but related issues so I’ll lump them into one GitHub issue for now. If you would like me to split them off into two issues, let me know.
- Tab to space conversion is prompted every time the user continues an indent
- Tabs are one character but treated as two indents semantically
Tab to space conversion is prompted every time the user continues an indent
Problem steps
- Paste the following code which uses tabs:
for x in range(3):
print(x + 1)
for y in range(3):
- When prompted, choose not to replace tabs with spaces.
- Press enter at the end of line 2.
- Press enter on the last line (now line 4)
Expected behavior
At step 3, \n\t
is inserted is inserted. At step 4, \n\t\t
is inserted.
Actual behavior
- At step 3, the user is prompted to replace tabs with spaces. If they decide not to,
\n\t
is inserted. - At step 4, the user is prompted to replace tabs with spaces. If they decide not to,
\n\t\t
is inserted.
Remarks
This seems to be the editor trying to maintain consistency with the existing code, per the user’s preference, while also forgetting that the user already decided not to convert tabs to spaces before in the same file. Suggested fix: recording somewhere (in memory or in a config file) that the user would prefer to keep tabs on paste. Alternative fix: warn when pasting tabs, and convert them to spaces no matter what.
While the intention is perhaps to discourage the use of tabs, this behavior comes off as heavy handed, to the point of actively being user-hostile. Tabs are discouraged by Thonny because the language discourages them, but Python also requires consistent indentation. Syntax takes precedence over style, so if it’s not inconsistent behavior, it would seem to be inconsistent rationale.
Tabs are one character but treated as two indents semantically
Problem steps
- Manually insert a tab character, using a clipboard or an IME.
- When prompted, press “no” to not replace tabs with 4 spaces.
- Press backspace on the tab character.
- Note that the tab character is rendered as two indents, which is inconsistent with the behavior of replacing tab keypresses with one indent.
- Save the file.
Expected behavior
The entire tab character is deleted and the file is empty.
Actual behavior
Step (2) inserts one tab character, but since it’s rendered as two “indents”, pressing backspace turns it into one indent, and the file contains one tab character.
Remarks
Render a tab character as one indent (4 character widths / one tabstop). If you really want to distinguish them, display an indent marker, like this:
Notes
I don’t want to start a flame war here =)
I respect the position of being opinionated for simplicity and for the sake of guiding beginners towards Good Practice and therefore not supporting tabs for indentation. However, I think it should be possible and not cumbersome for a beginner to contribute to codebases that already use tabs. If that use-case is out of scope for this project, feel free to close this issue. I am willing to try to fix these issues, if all contributors would rather not touch The Character That Shall Not Be Named.
Issue Analytics
- State:
- Created 3 years ago
- Comments:10 (6 by maintainers)
Actually I don’t have strong feelings about tab. It was just easier to ignore them, because using tabs for indentation in Tkinter’s Text widget is not really straightforward (#982). I’ve now learned that several users want or need to use tabs (#656, #505, #869, #599, #548).
I’d be really glad if you could sort out any of the issues mentioned here!
I guess it’s done now. I added comments about what I did under #599. Please reopen if you think there is something more to be done.