New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IE-0003: Dividing source text into multiple files #3
Conversation
I prefer option 2:
Option 3 is interesting, but the caveats make it seem more fragile than option 2. Does changing the level of a source file require changing it in both places? What about if you move code around, would it suddenly complain if there's a section after an external chapter? And who can ever remember the order of "book" and "volume" anyway! And also, to be honest, the whole .inform/.materials split is weird and doesn't make sense outside of MacOS. If anyone is unaware, in MacOS .inform folders are treated like single files. You can't (easily) access their insides. This makes them convenient for hiding all the build artefacts. But they have the disadvantage that users can't then add other files to them. So we have the .materials folder. And in this proposal we'll then have two source folders! One in .inform which contains only the story.ni, and the other in .materials which contains additional source files. Necessary in MacOS, but kind of weird in the other OSes. Really the build artefacts should have just been in a hidden .build folder. I think it would be great if this .inform/.materials split was abolished in the future, but I know that's almost certainly not going to happen. |
I am also intrigued by the This summary of Kenneth Reitz's guidance on Python Structure is my best anchor. Software repositories of any programming language (or set of programming languages) all appear to share hierarchy and labels, aka folders and files. From here, languages diverge in conventions and requirements for their project structure. Along with all the finicky metadata involved, the core concepts of Python appear to be IE-0001 proposes Is there a clear winner for collective noun of this new style of source text/subdivision? As IE-0003 is currently written, I understand a |
I also prefer explicit Regarding headings, the simplest initial implementation might be to report a Problem if there would be a conflict -- for example, if the
I second this. It has long been a pet peeve of mine that the materials folder is not a subfolder of the project. I don't think there's any strong reason to hide the build artifacts; indeed it's quite necessary to look at some of them (such as the debug log) on occasion. And people are used to compilers making a It would be nicer if all of the source was in the single Source directory, although having them split is not unprecedented since this is how project-local extensions currently operate. |
Wholeheartedly agree. It's currently a pain that to track an Inform project in git one needs another directory above the .inform and .materials directories. This proposal comes so frustratingly close to obviating this and allowing one to track only the .materials dir. It would take just a few tweaks to get there: modifying the IDEs to offer some scheme for letting Settings.plist live under project.materials (I'm personally indifferent to this one and would be elated by the measures below alone...) modifying inbuild and inform7 to:
e.g.,
|
I just want to endorse Zed's and uecasm's request to retire the .inform / .materials distinction, merging the directories. It really doesn't play nice with source control or under Linux. If we could get everything into one directory, it would help a ton. |
There's been a substantial discussion on the forum the past few days: https://intfiction.org/t/informs-inform-materials-folders/66875 |
Summary
The ability to split a large source text across multiple text files.