-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Provide packages with a way to handle raw content #1092
Comments
(See #675 (comment) for the original context). Instead of cramming more and more special commands into Note that since we are at parser level, we could even decide for something that doesn't look as a real SILE command, so it could as well be But for the sake of simplicity here, let's admit we may prefer using a SILE-familiar syntax... Eg.
vs.
Or even:
Another possible use:
(And let's thus have a real verbatim thing, with possibly a package that even does syntax highlighting for the said language) Packages could "register" a callback function for supported types. Say, from the Interestingly, a In brief:
Am I missing something? |
An interesting idea. Off the top of my head I don't think it would play nice with the XML or other input methods, it would only work with SILE syntax where we define the grammar. As such the ASTs for different inputs would diverge. I'll have to sleep on that though. Another idea might be just a keyword/macro trigger built into the language that adds/removes "passthrough" mode to specific commands via a callback in the LGEG grammar at runtime:
A similar command could be used to disable passthrough mode. This would obviously need to be part of the document before any such tags were encountered. |
Links to discussion in PR #675 that veered off into what this issue is about:
|
Having slept (poorly) on this, one downside I can see to my own previous suggestion about the parser finding a keyword to enable raw modes is that it would be limited to the primary document or segment being parsed. This would mean that a package could not enable a new tag to be passthrough for the main document. It could probably enable it for itself and any future strings that get parsed, but by the time the package include happens the primary document will already be parsed. |
Clarifying usage for the Another note is that if the TOC iteration issues is fixed properly (cf. issue #230 and PR #593) then we would have a way to restart processing after one pass. This would possibly enable seeing a library load that added a raw tag, then re-parse the input with the new function(s) available. This might run into some issues with syntax validation on the initial pass, but a failed pass could also be a good time to restart if we had new parser rules registered. Somewhat inefficient maybe but ergonomic. |
I expect the next release to have not one but 2 ways to handle this, one with the |
Re-opening because the PR that closed this is the less direct of the two solutions slated for v0.14.0, I'll let the more direct answer be the final closer here. |
The way the parser works, we currently have to tell the parser ahead of time what tags contain raw content that needs to be passed through to an external handler rather than recursively parsed for more SILE commands. This works great for our builtin
\script{}
command. It can also be amended quite easily as I've been assuming we would de for math (#220), Lilypond (#435), TikZ (#437), SVG (#1091), etc. if and when any of those things were bundled with SILE.This does not work out very well for things like @ctrlcctrlv's
texmode
package (see discussion in #947) that we do not plan to bundle. In fact it means 3rd party packages are at a distinct disadvantage to bundled ones in what they can and can't do.There is a workaround, but in requires invoking SILE with special arguments:
$ sile -e 'SILE.inputs.TeXlike.passthroughCommands.foo = true' -d foo test.sil
We should either think of a way for packages to inject their requested handling early (I can't think of one other than using two parsing passes) or make a more convenient interface for this and document it for use by 3rd party packages.
The text was updated successfully, but these errors were encountered: