> > *BJ: *if the transclusion is for a 'text' then parseTextReference calls > parseTiddler which uses the caches. >
*BJ: *There is no 'context for transclusions' in tiddlywiki, (actually > there is the inline/block distiction) the parsing is determined by the > content of the tiddler (includings the pragmas). > Ah! I had totally misunderstood, and didn't review the code well enough. Thanks for setting me straight. Good work all on going back in time and solving this problem for me. ;) *Mat*: IMO defining multiple macros, or macros in a tiddler containing > other stuff, is not true to tiddler philosophy. There mere fact that a > macro is *defined *indicates that it should be an individual tiddler. > *Jeremy*: I actually find “local macros” (ie macros defined and used within > the same tiddler) to be an essential tool for organising the content within > a tiddler, and so I would want to see them as part of TWX. The current > thinking about shifting the tiddler store to be a stack of tiddler store > widgets gives us a natural way to implement them. So, I agree with *both* of these sentiments. I think it makes sense for macros to exist as separate objects (IE, outside tiddler markup) but I also think it's useful for them to be encapsulated within the tiddler where they're used. Allowing a Tiddler to encapsulate its own tiddler-store, separate from the global namespace, would be a natural way to have macros as separate bodies of text that are nevertheless contained in the tiddler where they're used. I'm finding myself suddenly keen on the idea that a *field* or similar entity could be a tiddler-store in TWX... This would also be a great way to keep bulk data from bogging down the wiki store. On Thursday, 4 January 2018 14:45:53 UTC-6, BJ wrote: > > > > On Thursday, January 4, 2018 at 9:40:09 PM UTC+1, BJ wrote: >> >> >> >> On Thursday, January 4, 2018 at 8:56:29 PM UTC+1, Evan Balster wrote: >>> >>> there is caching in the core - see 'getCacheForTiddler' >>>> >>> >>> Haha, I almost bit my tongue when I sent that E-mail — I was aware of >>> the cache mechanism but hadn't seen that it was implemented for parse trees >>> as well. >>> >>> Trouble is, transclusions *don't* use the parse tree cache. They call >>> parseTextReference, which parses the transcluded tiddler with the current >>> ruleset. Part of the trouble with implementing a parse-caching >>> optimization is that the context where the tiddler is transcluded might >>> define different parse rules, resulting in a different parse tree for that >>> context. As noted by other users >>> <https://groups.google.com/forum/#!topic/tiddlywiki/eQRf8Wun3Zo>, >>> however, this "feature" can be unexpected or undesirable. >>> >> There is no 'context for transclusions' in tiddlywiki, (actually there is > the inline/block distiction) the parsing is determined by the content of > the tiddler (includings the pragmas). > > >> >> if the transclusion is for a 'text' then parseTextReference calls >> parseTiddler which uses the caches. >> >>> >>> On Thursday, 4 January 2018 13:09:18 UTC-6, BJ wrote: >>>> >>>> >>>> >>>> On Thursday, January 4, 2018 at 7:48:00 PM UTC+1, Evan Balster wrote: >>>>> >>>>> Hey, all — >>>>> >>>>> I have a plugin that defines parametrized tiddlers as components, >>>>>> there is a demo here: >>>>>> >>>>> >>>>> Neat! So under the hood this is functionally equivalent to >>>>> <$vars><$transclude/></$vars> right? >>>>> >>>> >>>> that correct -its to avoid the parsing of macros, but also to make >>>> wikitext components to be more like equivalents to widgets. >>>> >>>>> >>>>> What I'd really like to see in the future is a "parse-tree cache" for >>>>> more efficient transclusions. >>>>> >>>> >>>> there is caching in the core - see 'getCacheForTiddler' >>>> >>>>> >>>>> >>>>> ...Turning to another aspect of TWX, my idea is that it should be >>>>>> written in C, and compiled to WebAssembly... >>>>>> >>>>> >>>>> ...I'd love to go with rust here... >>>>> >>>>> >>>>> Hmmm... I've got thoughts on this but I'd rather start a new thread >>>>> so this one doesn't veer off-topic. >>>>> >>>>> >>>>> On Thursday, 4 January 2018 06:20:18 UTC-6, Jeremy Ruston wrote: >>>>>> >>>>>> >>>>>> IMO creating a new kernel should use a language that was designed to >>>>>> create kernels :) ... I'd love to go with rust here. >>>>>> >>>>>> >>>>>> Indeed, Rust would probably be a better choice these days. >>>>>> >>>>>> Best wishes >>>>>> >>>>>> Jeremy. >>>>>> >>>>>> >>>>>> Just a thought >>>>>> >>>>>> -m >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "TiddlyWikiDev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at https://groups.google.com/group/tiddlywikidev. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/tiddlywikidev/2e218423-1c94-4f75-ad6d-784824a9b972%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/tiddlywikidev/2e218423-1c94-4f75-ad6d-784824a9b972%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/549773b1-8159-43f6-bb8c-267e2c06108b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
