On Friday, September 11, 2020 at 4:46:23 AM UTC+2, TonyM wrote: > > > - I think it is worth persisting before release so we do not > compromise the future possibilities, or release something which is later > very different and confuses people. > > I think °°<symbol>.classes inline°° implementation is missing, but then it should be "feature complete" ... IMO it is already a "monster" and far way from "doing 1 thing well ;)"
> > - Not with standing this perhaps a MVP just for paragraphs and div's > plus classnames and no customisation? > - This could allow a set of companion stylesheets to be build and > tested > > That's right. The intro will start with the possibility to "style" default TW paragraphs. .. Show indentation and some "color boxes" > *On parameter names* > > - Using a naming standard like your proposed one, always makes things > harder for me to read, especially coming back to it after some time away, > that is the leading c as when I scan wikitext the c interferes with > spotting the name > > > - Have you considered using parameter names with the $ as we do > elsewhere to separate it from another fieldname like in the macro-call > $name? > > OK. $name is established by TW action-widgets, for the exact same reason. So if we would use it, the chance is, that we will get naming problems. ... But I do like the underscore idea. It's not as intrusive as $ > > - > - .name and _name and others should be possible, perhaps there is a > precedent somewhere? > > I think I'll try the _underscore ;) > > - They will not be used outside the pragma? > > No it's only needed for the \customize pragma. It will allow something like \customize tick=transclusion _element="$transclusion" _mode=block mode=block The first mode will be for the pragma and the second for the transclude widget. > *On underline* > > Can I suggest you stop referring to "_" as Underline as it is an > underscore, sure wiki text uses double underscore to wrap text and > underline it. But the character is underscore and its used to underline in > some cases. > OK > > *On Custom tag* > > If the one parameter can now be used for html tags and widgets, although > they are tags, we do not call widgets tags, perhaps a different name like > "element"? which doco will say is a "html tag or widget name" Arbitrary > html tags permitted. > IMO _element is OK > *Other* > > I wonder if arbitrary widget names can be used?, and by customising we can > toggle if that widget introduced by that tick can be disabled/enabled. eg > debug mode. > > ´.debug This when in debug mode like <<transclusion>> > > I note that > Top > > <$arbitrary> > Content of arbitrary widget > </$arbitrary> > > bottom > > Produces; > Top > > Undefined widget 'arbitrary' > > bottom > > I wonder if we could toggle this "Undefined widget " message off, when > not debugging, on by default. > This info is created at the *rendering stage*. ... We can't avoid this info, except using valid widget names. IMO this is an issue for the TW core. -mario -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/55e4db1d-9c85-49d3-b6a8-d95a454d5fb0o%40googlegroups.com.
