Urgh, this is really bad. Sorry.

Note to self: SILE.inputs.TeXlike.process does not seem to do anything when a documentclass is already defined. I blame @alerque for 97a4e3e, but I'm not sure if that's fair or not.

Is the % include/test.sil bit in your .sil file or was that just for the sake of your Github post? If the former this might be an iteration of #502.

I'll try to have a look today and see if I can figure out what's up.

Is the % include/test.sil bit in your .sil file or was that just for the sake of your Github post

For the sake of the github post. The original included file has only got the macro definition in it.

Wow yes this is as sticky little cart/horse problem and I broke it while adding other capabilities. Our file type detection wants to have its cake and eat it too, but I'm struggling to visualize how we can have both sets of nice things. I suspect the answer is going to be to stop trying to guess file types and just expect one of the other. We can't simultaneously sniff file types, allow valid comment syntaxs, and validate our own parsing tree.

With auto-detecting whether percentage units were vertical or horizontal the "smart" behavior turned out to be both finicky and limiting. Requiring the user to specify the axis both reduced unexpected behavior quirks and enabled more complex layouts. Likewise I think sniffing every text file and input string and trying to figure out if it's Lua, TeX, or XML will turn into a fiasco. At the very least we'll have to stop pretending the first few bytes actually tell us anything and actually try to feed the whole blob to each parser until one of them doesn't croak.

This issue is a ~~~duplicate~~~ near duplicate of #465.

@kappa2222 As of just now the bulk of your issue should be fixed in the master branch. You can recompile sile from that and it should work as it did before I broke it.

The catch is that "working" in this case still isn't quite what you expect. Sile can include a TeX-flavor file and splice it into the parsed tree where your include statement was, but it expects the included file to have a top level \start{document} tag. Your example here only has a fragment. You need to wrap that in a document tag for it to work.

I am leaving this issue open to address that because it does seem like including a fragment like that should be possible, but actual regression bug was #465 and that is fixed. Now this is a feature request for a new behavior that would be more intuitive.

I confirm that the problem is solved now, many thanks.

I don't mind adding a \start{document tag at the beginning of the included file at all.

@kappa2222 Do be aware when you include something any whitespace (including newlines) after the opening document tag and before the ending tag is going to get brought into your host document. It might happen that where you put the include this isn't a problem, but it might introduce unexpected spaces if you pull in inline content. What might have been discarded when rendering the include as a stand alone document might not get discarded at the include position.

This seems like unexpected behavior to me and I've mentioned it in our outstanding whitespace issue #105. Not requiring the wrapping document tag would make including fragments more intuitive in my mind.