Closed aartaka closed 1 year ago
Alternatively, maybe export *html-path*
?
The reason html-path isn't currently exported is that it's actually bound with dynamic extent. The idea is that most Spinneret users won't use the variable, so they shouldn't have to pay for it.
I'm willing to merge this change given a test and a mention in the readme.
The reason html-path isn't currently exported is that it's actually bound with dynamic extent.
But then it's still bound for the scope of Spinneret forms compilation, right? And let-binding that wrapps some tag is safe, as it simply nests the dynamic variable inside a lexical scope. Am I getting it wrong?
The idea is that most Spinneret users won't use the variable, so they shouldn't have to pay for it.
That one does make sense, but this also applies to the macro I'm suggesting here. Why pay for with-path
is no one uses it?
So I'd say that it'll be simpler to export *html-path*
, than re-inventing the wheel. I can open a new PR with tests and documentation. @ruricolist, sounds good?
Yes, go ahead.
Closing in favor of #77.
This adds a new macro,
with-html-path
, that let-binds*html-path*
so that the behavior of smart tags, like:h*
can be influenced from outside them without modifying unexported*html-path*
directly.The use-case is splitting Spinneret-generated code into several functions and setting the section depth independently in each of these functions. Given that we often split Spinneret code into functions in Nyxt, this one is quite critical to not depend on unexported APIs of Spinneret.