Here’s something nobody wants: You hit tab to indent some Python code and four little dots appear in the editor. You continue writing code and indenting a few times until sixteen little dots begin each new line of code. Then you need to dedent out and you find yourself having to carefully remove 8 little spaces that you never wanted in the first place.
This has to change. I don’t care why Rhino doesn’t like tabs, it has to find a way to deal with them. Grasshopper is a forward-thinking, flow-based, user-friendly interface and yet the GHPython editor is even worse than IDLE (which is itself trapped in the year 1999).
Presumably the GHPython editor has to support unicode anyway, so for the life of me I can’t imagine why you can’t store tabs even if it is just some kind of an ugly patch for the text editor. You only need ASCII for tabs, for crying out loud.
You can always convert to spaces when the code is executed, but there is no good reason to have forced tab → space conversions in a tab-centric language like Python.
FWIW Python is a space-indentation based language, as also mentioned in the PEP-8 coding guidelines for Python. IOW the Python way is to have 4 spaces for every indentation…
The Python editor is a small utility meant to help to get started writing scripts. You can use full-blown IDEs if you are a developer that is used to a particular platform. For VS tools for Python, we have a guide on even set up debugging, in addition to editing. It’s also possible to do this with other IDEs.
This being said, given the small utility we provide*, we are following PEP8 as @nathanletwory mentions. And, you can move left by 4 spaces using Shift+Tab on a normal cursor. If you select a few lines, and hit Shift+Tab, then the indentation of all those lines moves left of one level (4 spaces each). You can also select a few lines and add indentation by using selection+Tab.
I hope this last part helps, at least a little bit.
*@Alain has been working on a new text area control (the part of the editor where you type text) for Rhino 7 WIP. Maybe he can chime in regarding this particular topic.
It looks like you’re talking about Rhino for Windows. The default follows the PEP-8 recommendation of 4 spaces like mentioned above. There’s a Convert tabs to spaces setting in the Python Options dialog that may help.
There’s a new editor for Rhino for Mac that we’re working on. The default will be the same but it will be configurable.
You are absolutely correct about PEP-8, it does recommend spaces, although IIRC it is meant to apply to Python standard library development, not external projects. As such it based its reasoning on the trend for spaces at the time of its writing. In defense of spaces, Google’s style guide for Python also recommends spaces.
You may notice that Python’s own internal editor (IDLE) does not do a tab to space substitution on its users, nor do any other IDEs or editors that I have used.
User-configurable spacing absolutely works for me. As long as I can say “use tabs not spaces” I won’t get super pissed writing code in the GHPython editor!
Some of us come from Posix environments and despise spaces. To quote our benevolent stable genius GvR:
“My recommendation is to always use tabs on the Mac – then it will
look good on the Mac and at least parse correctly everywhere.
For the same reason I recommend always using tabs on Unix as well
(thus indenting by 8 positions there), but the majority of Python
users seem to be against me.”
I saw that you said that. I don’t see why any of us have to be affected by PEP-8 if we don’t want to be.
My entire point with this post is that it is regressive to force conversions to spaces in the GHPython editor when the user inputs tab. I threw a wrench in it by referring to Python as “tab-centric”!
The new text area control, as mentioned by @Alain,
so we are listening to your concerns.
Maybe can I ask a favor? Maybe next time can I ask to keep the tones a little more subtle? “I don’t care”, “This has to change”, “for the life of me” and “for crying out loud” are too much, especially because this is the first time you or anyone reports this: a “please” would work just as well. Also, try not to confuse “me/some” with “anybody” (this is a “faulty generalization” fallacy). That you don’t like spaces, is a good enough argument for us. To add to your cause, I don’t like spaces either.
This is great, thanks Giulio. Of course I’ll try to keep the tone friendlier next time, communicating over written text has the inherent downside of muddling tone. Cheeky and critical can become one and the same, my intention was the former.
I’d say please include menu options and keyboard shortcuts for shifting text and text passages left and right, which kind of makes it agnostic of whether the indentation is done with spaces or tabs.
On macOS, you can use either tabs or spaces in the GHPython editor, however it doesn’t seem to recognize 4 spaces from other editors, when copying and pasting, and then you have to go in an change every indentation manually or set the other editor to tabs, which it seems to get.
Hi,
We’re working on the next version of the editor where the tab size can be configured as well as whether tabs or spaces are inserted. When a file is opened the indentation settings will be based on its contents if detect indentation is set.
I logged the request to indent/unindent a selected block of text.
