Godot: Copy and pasting code into editor causing indent error after modifying the code

[Tim-MCC]

OS : Windows

_Steps to reproduce:_
Copy and paste a code from godot documentation into the editor i used the code from here (http://docs.godotengine.org/en/3.0/tutorials/io/saving_games.html#saving-and-reading-data)
Now everything looks good with no issue and you can also run the code
But try to add a line of code anywhere between the code lines
You get indent error

_Steps to solve_
You need to select all the white spaces on each lines of codes you pasted from beginning of the line up to the code and then re indent with tabs individually

If it throws the error the moment you paste the code you would immediately find out what's up and try to strip out everything but this way you get confused and would think it's something that you did

[eon-s]

The error is right, docs indentation uses spaces (it may be a limitation of the site) and that print line uses a tab, indentation is different for GDScript even if it _looks_ at the same level.

I do not know if documentation site code snippets can use tabs instead of spaces, but after pasting you can press ctrl+shift+X with nothing selected to convert all spaces to tabs (see edit menu on script editor).

[willvincent]

Maybe the editor should auto-convert indents on paste.

[nobuyukinyuu]

I believe there's options to auto-convert indents upon saving in the editor settings. Having an option to do this upon pasting would be nice, too.

[Tim-MCC]

Or at the parser

[vnen]

Or at the parser

Don't know what you mean, the parser never changes the source code.

[Tim-MCC]

@vnen I mean to never actually change the code but to treat prior tab and spaces the same at the parser, that sounds more elegant to me, but of course that depends on what's compiler's relationship with this matter, might be required to align that too

[willvincent]

Played a little bit with implementing a 'convert indent on paste' option.. I got it to work if using the menu: Edit -> Paste option, but it does not work when using the keyboard shortcut... also adds an extra undo level which probably isn't ideal.

Seems like it ought to be doable as is, but it doesn't work as expected, so in my limited understanding of the codebase it looks like maybe for this to work properly the convert to spaces and convert to tabs methods would need to be moved to the parent editor object so that they occur at a lower level.

Since there is a problem with mixed tab/space indention this probably should be a feature though.

[vnen]

@Timberland-7

I mean to never actually change the code but to treat prior tab and spaces the same at the parser,

I see what you mean now, but that would be awful, honestly. First that 4 spaces = 1 tab is totally dependent on the tab size you have defined in your text editor. It would look bad if it's anything different, to the point of being unreadable since GDScript defines blocks based on indentation.

The solution here is really to fix when pasting, it should be an editor feature, no need to change the language.

[Tim-MCC]

@vnen respectfully you are wrong, the way you think of it is not the way how it works and here's the proof :

it always looks for the indent weight by looking at the first one occurring within each code block individually.

Now what's the catch with "on pasting" method? It's about the different between environmental approaches vs systematic and the problem mostly relies in compatibility and portability, and for this specific case i can think of three scenarios for now and these are not limited to copy and pasting but coding style and plus that:

1. Someone would likes to use their own favorite editor to edit or even write the script, or use both the same time ( ex having the script in sublime/vscode in one display and the design tab on Godot in another in professional setup )
2. This is just one single case but let's say if we keep implementing more solutions like this at the editor level, once later on Godot decided to replace the editor with something else say more feature-rich one then everything needs to be migrated to the new one
3. Code sharing and live code sharing ( i assume the "on pasting" approach won't cut it here )

The solution :
Godot unconsciously already has everything in place, the problem relies only in adopting spaces and tabs together in a block so as we have the tab weight of the block we get the equal value of weight in spaces as well and wherever there's spaces it checks the matching and vice versa.

[nobuyukinyuu]

It would seem to me that the behavior of the parser when approaching tabs vs. spaces is easier to describe now than it would be if its behavior were to treat them interchangeably within a code block. Keeping the solution at the editor level also keeps the description of the indentation behavior consistent with what everyone already knows about it, particularly (assuming it works the same there) those coming from Python. Meanwhile, treating spaces and tabs the same the way you describe it would tie the compiler to editor settings, not to mention how it would treat conversion of indentation levels which don't fall cleanly to a whole division.

Implementing a systematic change to deal with poor consistency in style conventions in-block feels a little like putting the cart before the horse, and I'm sure that particular horse has been beaten to death already in the Python discussion lists anyway. 😌 I would suggest taking a look at some of the discussions over there to see what they have had to say about it over the years.

(I say this even though I still run into indentation errors all the time after pasting snippets...)

[vnen]

@Timberland-7

it always looks for the indent weight by looking at the first one occurring within each code block individually.

Yes, I never said otherwise. It looks for the amount of space characters in the first line and matches the next ones based on that. You can also use 4 spaces in one line and 4 tabs in the next:

But that's not a problem with the parser nor with the language. If you configure your editor to show a tab with only one space, you won't see any difference. And that's my point, you can't consider that 1 tab is 4 spaces always, because that's a setting of the editor. E.g. with tab = 1 space:

Would the second picture be correct but the first not?

About your points:

1. Someone would likes to use their own favorite editor to edit or even write the script, or use both the same time ( ex having the script in sublime/vscode in one display and the design tab on Godot in another in professional setup )

I'm not sure how it is detrimental. Every full-featured code editor (like Sublime and VS Code) have the function to convert indentation already. Just configure the editors to suit your needs.

1. This is just one single case but let's say if we keep implementing more solutions like this at the editor level, once later on Godot decided to replace the editor with something else say more feature-rich one then everything needs to be migrated to the new one

If you mean a third-party editor, they probably have this function (and probably others that Godot lack). If you mean a first-party one, we would have to migrate everything anyway. But this is a hypothetical scenario, we won't have any progress if we only think "what if". By this line of thought we should stop adding features to the script editor, in case we decide to move on later...

1. Code sharing and live code sharing ( i assume the "on pasting" approach won't cut it here )

Not sure what you mean here. If you mean getting snippets on forums or something, you'd have to copy and paste anyway. If you are sharing with your team, you would need to agree on a style convention (otherwise workflow would be terrible, especially with VCS). And your solution wouldn't cut anyway if one person had configured 1 tab = 2 spaces in the editor and the other let the default of 1 tab = 4 spaces.

---

Essentially you are trying to solve problems that don't exist, while the problem that does exist (pasting code from the docs) have a simple solution already proposed (fix indentation on paste).

[willvincent]

Mixing tabs & spaces is problematic, at least in editor -- but more than that, even if it didn't throw syntax errors, it's sloppy coding and the solution to normalize to either spaces or tabs on paste would resolve the issue pretty cleanly, and ought to be fairly straightforward to implement.

I gave it a little trial (as noted above) and had it working from the menu item, but couldn't get it working when using the keyboard shortcut, not sure why... also my first pass at it added an extra undo level which isn't ideal.But the basic solution of normalizing indent on paste is the most logical to me.

We've already got settings to select whether to use tabs or spaces for indent, as well as indent size. We also have the "convert on save" setting, adding an optional "convert indent on paste" setting just makes sense.

[Tim-MCC]

@nobuyukinyuu @vnen

Let's not forget that my point was to reach a solution for cases that it doesn't cut the pasting event to fire as well, like i send you a script file which i used spaces in and when you open it and try to modify it with tabs and vice versa.

@nobuyukinyuu

Keeping the solution at the editor level also keeps the description of the indentation behavior consistent with what everyone already knows about it

That's a good point you brought, let's refer to what and how it happened and add some psychology in here, what most people know and are used to the most ( working in an editor without having anything personalized ) is to "automatically" assume if the indent "looks" right then it should work right, many things have changed since 1990 and how our mind function and perceives things is constantly changing accordingly as well, we're more visual than ever, what/how we see things is the way we expect them to work and to make sense of rather than rely on what we should know about them and be aware of.

Just for what it's worth at least it worth the imagination to take a moment with rather than sealing it with a cart and a horse. Not everything that we're used to can we say are at the best could be ever, and besides, user-first approaches are the key at this age we're living.
The web for instance could be different, it could be like having an 'element to portable format' (like svg now) compiler at the server so we never would have run into everyday browser compatibility issues again at least at viewing-experience perspective.
It's off the point but Systematic approach is a mindset no matter if it worth the particular case or not but at the end it would.

@vnen

The problem here was that Godot's default indent type setting unlike most of the editors I'm used to work with is based on tabs factor ( and i personally haven't/needed to noticed such a weird option before ) which means 1 level of indent = 1 space = 1 tab = x of spaces which has confused me, now if it be changed to based on spaces all the problems arising from user's unconscious would go away and how the indent levels looks visually will be always the result expected, WYSIWYG.
And with how i experienced this issue and how it all started in mind then this way i would never have had run into this.

Of course the "on pasting" is up for the spin if people are interested in but in my case the change in default indent type setting in editor setting was it and covers all the cases i mentioned in last comment as well.

[willvincent]

So maybe it should also normalize on _open_ as well as on save. Perhaps it makes sense to implement .editorconfig support

[Tim-MCC]

@willvincent On paste , on open and also changing default indent type value from tabs to spaces is crucial.

[Zireael07]

@Timberland-7: respectfully, most programming IDEs have indent settings based on spaces (1 tab = x spaces)

[akien-mga]

I don't think indentation should be changed when opening, once a file is saved, its indentation should be preserved. If it doesn't match the style guide of a project, it's up to the devs to fix it if they want (but in many situations you don't want, e.g. if it's a thirdparty asset that uses a different style than yours, you'd better keep it unmodified it you want to sync upstream changes in the future).

Changing indentation on paste is enough, no need to overengineer the feature. If there's a need for more, it can be addressed later on, but for now the main issue is to prevent people from unwillingly introducing wrongly indented code via copy-paste, which happens a lot since our docs use spaces and the default GDScript style uses tabs.

also adds an extra undo level which probably isn't ideal.

That's the standard behaviour in IDEs I use, so it's fine. Sometimes the IDE will mess up the code you paste by changing its indentation while you wanted it preserved, so that extraneous undo step lets you go back to the original pasted code.

[Tim-MCC]

@akien-mga

If it doesn't match the style guide of a project, it's up to the devs to fix it if they want (but in many situations you don't want, e.g. if it's a thirdparty asset that uses a different style than yours, you'd better keep it unmodified it you want to sync upstream changes in the future).

I see what you're saying but the benefit of not preserving it, is more than preserving it and in so many more cases while working with thirdparty assets and codes provided through tutorials. you are mostly likely to modify the codes you've gotten from somewhere.
So how about this, we ask the user whether they want to fix the indentation or preserve the default each time when either there's a pasting or opening file and indentation does not match, we can do it either on-demand (on paste and on open) or ( i like this one more ) : within the indentation error that's thrown there could be a "fix it" button ( see the attached image ).
_Further this can be an option on setting section to choose if you want to automatically have your indentation setting applied on every situation._

[vnen]

I see what you're saying but the benefit of not preserving it, is more than preserving it and in so many more cases while working with thirdparty assets and codes provided through tutorials. you are mostly likely to modify the codes you've gotten from somewhere.

I don't agree with the point about benefits of not preserving the style.

If I'm following in a tutorial, I'll probably leave the style as the original. Hardly ever I use it as base for anything. And if one wants to do it and change the style, is up to them to fix the formatting (from which indentation is just a part, there's naming convention as well, among other things). If you're copying and pasting from a tutorial, then the "on paste" method is enough.

If I'm using third-party code, I'll probably not change it at all if possible. It helps me update it if the original is changed. Depending on the size of the code it becomes unpractical (I may even introduce bugs by making some mistakes).

Now, if you are adapting third-party code to your own project, you are either copy/pasting them (which is solved by the format on paste method) or you are opening an existing code (which can be fixed by the already existing functions in the editor to convert indent style).

So how about this, we ask the user whether they want to fix the indentation or preserve the default each time when either there's a pasting or opening file and indentation does not match, we can do it either on-demand (on paste and on open) or ( i like this one more ) : within the indentation error that's thrown there could be a "fix it" button ( see the attached image ).

I don't how often such automatic fix would be correct. And when it's not correct it will probably lead to more problems, since the code will be syntactically correct but won't do what you expect. Much easier to track a syntax error than a logical one (especially when you are dealing with third-party code, which is the point here).

---

I have missed the previous comment, lemme address it as well:

The problem here was that Godot's default indent type setting unlike most of the editors I'm used to work with is based on tabs factor ( and i personally haven't/needed to noticed such a weird option before ) which means 1 level of indent = 1 space = 1 tab = x of spaces which has confused me, now if it be changed to based on spaces all the problems arising from user's unconscious would go away and how the indent levels looks visually will be always the result expected, WYSIWYG.

The discussion tabs vs. spaces goes a long way and it is very much language-dependent (and may times editor-dependent for older languages). Whether one is bad and other is good is not the point here. Godot always had tabs for default and there's no real need to change it now, most users deal fine with it.

The indentation as block-marker (which I believe is what refer to as "tabs factor") is part of the language, not the editor, and it's not an option. It works the same as Python. Many languages will simply ignore whitespace, that's probably why you never had problems with it in your previous experience.

And with how i experienced this issue and how it all started in mind then this way i would never have had run into this.

If everything was reversed (i.e. editor used spaces, copied code used tabs), you would experience the exact same issue.

Of course the "on pasting" is up for the spin if people are interested in but in my case the change in default indent type setting in editor setting was it and covers all the cases i mentioned in last comment as well.

You can change the indentation to use spaces in the Editor Settings, if that's what you prefer. I don't really see a point to change the default setting.

[akien-mga]

I agree with @vnen, and I reiterate, arbitrarily changing indentation when opening a file is no-go. I never saw any IDE do that, and I don't know what it's use case would be.

When I do want to change the indentation of a whole file in my IDE, I usually cut everything and paste again, thus using the "change indentation on paste" feature my IDE has. In Godot you actually even have a feature to change it without having to use this trick, but this trick would be available if the "on paste" fix is implemented.

[Tim-MCC]

Let's kindly cut it short as the deal is not as big as the discussion is getting.

About the first part whether having the "on open" functionality or not i don't have a fight here, that was more of a simple suggestion and i even didn't started that. Later on i was more after cases like when you get a game template from marketplace or somewhere, use it as the base and start working on top of that ( + experimenting situations ), and you are mostly about the cases like integrating new codes into current project. Maybe it's not worth it, i can agree.

@vnen About the second part ( everything after the hr break ), I'm not getting into any of the comments over again, just i should say that you misjudged and missed out on what i really was trying to say. And no it wasn't about block-marker. And no, "some languages ignoring whitespace" is not why i hadn't have problem with it.

---

Still I would insist on having _Spaces_ as the default indent type instead of _Tabs_ or somebody please name some of the IDEs ( at least semi-popular ) that use tabs as default setting and I'll appreciate it or saying that Godot likes it this way would not make much sense because it's good to always follow some market standards.

[akien-mga]

Still I would insist on having Spaces as the default indent type instead of Tabs or somebody please name some of the IDEs ( at least semi-popular ) that use tabs as default setting and I'll appreciate it or saying that Godot likes it this way would not make much sense because it's good to always follow some market standards.

You never give up, do you? Here are some examples for you: Eclipse, KDevelop, Kate/Kwrite, Notepadqq...

And to quote you:

Let's kindly cut it short as the deal is not as big as the discussion is getting.

So please stop arguing about this, and the default indentation setting is completely out of scope of this issue which should strictly be addressed by implementing a feature to convert indentation on paste, and that's all.

[nobuyukinyuu]

@Timberland-7 Visual Studio, when editing Visual Basic

[Tim-MCC]

And no one assumed I'm talking about Game engines here by IDEs, right?

You never give up, do you?

Is it about me giving up or hearing what the guy says, maybe he got something there?!!

Coming from PM and UX background beside coding, i see some other areas here which you might not, my whole idea was that from the list of top 50 game engines and no matter what platform it's related to ( I'm including here all from unity to coronalab ) , with only very few you might run into this tab indentation behavior and i understand that for the languages most of them use, off-side rule is not a thing, and that is specifically what that matters here ! there is a great game engine shaping up named Godot which could attract everyone from all sides regardless of previous engine, programming skills, background and platform, there is a huge chance most of the target audiences are not the type YOU THINK ( nerds starting from 1990 with Pascal, C and Python ) so in this case what would be the best solution to avoid unintentional indentation troubles with a software with true diverse audiences is to forget about what we think we know ( where others might not ) and make it as WYSIWYG [ What you see is what you get ] and that can be done here by having Spaces as default option BECAUSE with that option set, under ANY circumstances and not just copy and pasting, when you try to reindent the code no matter with using tab or space, always the way that the indent levels of your code blocks LOOK visually in your code is the way that the parser is fine with. So without even having some unnecessary -on paste- functionalities, the first thing anyone will try to do is to reindent their codes and they do it unconsciously by making the indent levels look fixed visually, which can not go wrong if indentation setting is spaces but can go wrong if it's tabs.

and that's all.

Yes it is. I'm out
Good luck !

[akien-mga]

Well, don't care much about your tabs vs spaces holy war, but if you don't want us to keep this issue focused on what we agreed to do (converting indentation to tabs or spaces - based on project settings - on paste operation), I'll close it and open a new issue focusing on what we want implemented.

And for the love of Guido, please do use dots to separate your sentences.

[akien-mga]

For those who care about the actual feature that has to be implemented: #19285.