Bugs & Feature Suggestions • [BUG] @Include recursion tree is flawed

This one is gonna be a bit hard to wrap your head around but the example should show the "bug"
We have a folder with the files

MainSkin.ini
└A.inc
└B.inc
└C.inc

In the skin, the meters are color coded to represent it easier, A is RED, C is GREEN, B is BLUE

MainSkin.iniA.incB.incC.incOn the assumption that the Docs saying You may also include files within files. Once again, the ordering is determined by placement: when any file includes another file, the new contents are added within its own sections, immediately after the section where the statement is made. is correct, with the way we have written this, let's go over how the @Includes should work, @Include by @Include.

First let's start with the code as is
First the @IncludeA is loaded, so the skin now becomesAfter that, it sees that @IncludeC exists, so it gets placed between the meters Finally, it sees @IncludeB, so it adds it at the endSo now let's put them as boxes next to each other with how it should look
ACCCAB
The Rainmeter log debugs the loads for those files in that order too, ACB

And that's how it should work by the logic imposed by the wording on the docs and what humans would assume with recursive actions of this kind... except it dosen't, that's why I made this report, when Rainmeter gets to for some reason, Rainmeter breaks human logic at this step, it sees that there's an @IncludeC, so [MeterA2] is put into limbo and from the "we have read in A.inc these following sections" list, the @IncludeC triggers "in A.inc we have these sections we have no idea about, assume they are new sections to be placed after every @Include is done" for every single other thing in A.inc, Rainmeter is no longer gonna take it's time dealing with [MeterA2] at this step

This ends up being what Rainmeter currently dose right nowwhich is ACCCBA

I wanted to give a suggestion here but I genuinely have no idea how to fix this. When I found this out my very first reaction was a loud WHYYYYYY???? and laughing at my screen.
Most likely binary tree where the sections are resolved first and the @Includes get their branches later can be a solution for this? (If my assumption that Rainmeter reads @Includes line by line is correct and dosen't read sections before @Includes) I know the solution is to just include [MeterB] in MainSkin.ini, but the logic for the implementation is still flawed and it's what I wanted to point out, the docs are too correct in saying When Rainmeter reaches an @include line, it reads the given file, placing all unique options into any existing sections, then places the remainder of the included file after the section in which it was called.

And to give credits, this was submitted by Gabe on Discord

Statistics: Posted by Jeff — 3 minutes ago — Replies 0 — Views 2

---