Vocabulary as a general concept seems like it fits the bill. At that point, "smart" attributes would just be treated as wikitext with the "plaintext" vocabulary.
I have to confess I'd forgotten about typed blocks when I wrote the OP, and by running at parse-time they solve some of the stickier problems I mention in the OP. They provide a simple way to insert "raw" plaintext into wikified plaintext, and to manipulate the parse settings before widgets are instantiated... This puts some questions on my mind: - Is it sensible to add vocabulary as another option for typed blocks? - Would typed blocks would inherit parse settings the markup does not specify? (vocabulary & render mode) - Could widgets detect the parse settings that produced them and employ these when parsing imported text? - Could the wikiparser cache support caching parse-trees for each vocabulary? On Friday, 12 January 2018 02:02:19 UTC-6, Jeremy Ruston wrote: > > Hi Evan > > I think that this ancient ticket might be roughly equivalent to what > you’re after: > > https://github.com/Jermolene/TiddlyWiki5/issues/345 > > The proposal still reflects my thinking in this area. > > Best wishes > > Jeremy. > > > On 12 Jan 2018, at 04:58, Evan Balster <[email protected] <javascript:>> > wrote: > > Hey, all — > > Currently TiddlyWiki implements plain-text wikification by applying > WikiText parsing to generate a DOM, then extracting and concatenating any > text-widgets in the DOM while discarding everything else. While this > functionality is very useful, it has some tricky drawbacks — wikification > involves (often) unnecessary work processing irrelevant parse rules, and > anything resembling an <element> or //wikitext markup will be stripped out, > when this might be very undesirable (eg, when encountering JavaScript or > C++ comments). > > I'd like to propose an alternative mode where only those parse rules which > are applicable to plaintext are considered — that is, widgets, > transclusions (including lists), variables and a few other items. That > way, we can write things like this (a method stub generator): > > <$list variable=class filter="[tag[Class]]"> > <$list filter="[tag[Method][tag<class>]]"> > // {{!!summary}} > {{!!return_type}} {{!!name}}({{!!parameters}}) { > } > > </$list> > </$list> > > I'd like to propose, further, that this functionality be available for > attributes. This will eliminate several situations where it's necessary to > use macros or $wikify, replacing these mechanisms with a more efficient, > briefer, pre-parsable expression. As noted by Jeremy, one of the most > common user mistakes involves expecting wiki syntax inside quoted strings > (or imported via macro/transclusion) to work in an attribute... Things > like title="my name is {{!!name}}". I see very few reasons (aside from > compatibility) why they shouldn't work as expected! > > A conservative approach could mandate a double-equals syntax or an > alternative quotation style for wikified attributes: > > <div style=="size: {{!!size}}px;"> > > ...Though if I'm to be honest I would prefer to see all attributes parsed > by default with an alternative syntax for "direct" values. Perhaps I'm too > radical. :) > > I don't think wikification needs to change much to implement this — > another parse mode, with a smaller ruleset. The tricker part of the > implementation is getting widgets to parse imported text according to the > proper rules. To that end, I suggest that the namespace variable could be > used to determine parsing behavior for imported text. In the future this > might also be leveraged to keep inappropriate elements out of <math> and > <svg> namespaces... > > > With these changes, I believe TiddlyWiki's logic would become more > powerful and, crucially, more consistent, helping newcomers to learn it > with fewer "gotchas" and making it simpler for experts like me to build > complicated constructs. I also think it's an essential piece of the puzzle > for evolving TiddlyWiki beyond macro dependency. > > Interested to hear others' thoughts. > > -- > 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] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > 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/7e867e78-da41-466a-b9ab-754439100af2%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywikidev/7e867e78-da41-466a-b9ab-754439100af2%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/482bb2ac-1419-4ea5-a73c-d0f0f89afeb8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
