trice clean inconsistency

[KammutierSpule]

I'm experience running trice tool on different containers, somehow, they "clean differently" In one system it cleans to Trice(<space>".... on other system I got the removed Trice("....

I'm not sure what are the differences on my system that may be causing this.

[rokath]

Are all used Trice tool versions are identical? There is a switch -spacing for trice insert but not for trice clean what may be an error. I cannot check this right now.

[rokath]

The switch -spacing is now renamed into -spaceAfterOpeningBrace, or short -w, and exists now for trice i and trice c in branch devel.

[KammutierSpule]

thanks! Can you clarify what was the previous default behavior of insert and clean, and now what is the default behavior?

[rokath]

One can write trice("hi");

• After trice i we have trice(iD(123), "hi". (default)
• Or after trice i -w we have trice(<space>iD(123), "hi".

Or the other way around with trice(iD(123), "hi");

• After trice c we have trice("hi); (default)
• Or after trice c -w we have trice(<space>"hi");.

I did not pay attention to this until code auto-formatting came into the game. Because some users may configure the code-formatter to have a space after an opening brace and some may prefer no space there, Trice got the -w switch to control that. The code would be altered all the time by Trice and the auto-formatter by inserting and removing spaces, if both tools do not agree on the rules. I am not sure, if the iD(n), should be optional also be iD(<space>n<space>),. We should keep it simple.

EDIT: When the Trice cache is used, an auto-formatter should get active before Trice sees the code. See the cache doc.

[KammutierSpule]

Thanks I will evaluate later. My main concern is more with version control system, as if on different systems it has different behavior it will cause a big diff on files.

[rokath]

If the Trice version is the same on different systems there should be no differences even if compiled with different Go versions. Otherwise this would be very interesting.

EDIT: The -w CLI switch is now part of release 0.72.3.

[rokath]

I wrote

I am not sure, if the iD(n), should be optional also be iD(n),. We should keep it simple.

After thinking and reviewing the code I decided, that iD(n) should be influenced be the -w CLI switch as well. It was a very small change and is in my opinion now more consistent. The parser tolerates white spaces anyway. The long name of -w is now -spaceInsideParenthesis, no better idea.

EDIT: Right now only in the devel branch.