Mario, The need for an endString, although may be valid in other use cases is a good way to recognise when a multi-line block or inline text is in use, rather than the line based approach. Many of the current wiki text is line based.
It seems to me that making use of a method like °/.classname something here /° or °/.classname something here /° and/or Start of line °/id.classname something here /° end of line. The key being you can see which opens and which closes, ie its asymmetric yet palindromic. But if course, since unfortunately the mechanism's you are using are unknown to me, I leave the feasibility to you. If you were looking for a point at which to publish an initial release, perhaps this could be the dividing line, between the first and second release. As long as nothing in the first release compromised later inline annotations, it does not all have to be solved at once. I certainly think that the matching CSS and other interesting applications of the customise pragma can come from the community. Perhaps a challenge for the most impressive applications and their subsequent documentation would be a way to get feedback, doco etc... In the mean time, best rest assured I continue to exercise your latest releases, and If I am truthful, primarily trying to test its limits. Trying to do things that until now has either being impossible or long winded. As an aside I am working on leveraging macros and transclusions to complement opportunities to authorship along side the customize pragma. Regards Tony On Monday, 21 September 2020 at 19:53:59 UTC+10 PMario wrote: > On Monday, September 21, 2020 at 10:54:48 AM UTC+2, @TiddlyTweeter wrote: > > I had an example Use Case to show but things changed so much in your tool >> I'm revising it. Hopefully I have time soon. >> > > Yea, It was alpha as we started. It is beta now. So I think we settled on > the naming conventions. > > >> I note your comment on buttons. Right. >> >> I also read the detail on discussion of using it for macros. I'm slightly >> nervous about that. >> The GAINS on HTML insertion and CSS styling are very substantial. I would >> not want handling macros to confuse the basic need to expand easy invoke of >> HTML & CSS. >> > > The existing widgets haven't been designed with our usecase in mind. > Especially the button widget is a "monster". It has way too many different > usecases and way to many parameters. Some of them are used, some of them > don't. .. Depending on the usecase. ... That's why the action-widgets have > been invented. .. They do _only 1 thing well_ > > There was a bug in the code, that made it impossible to handle widget > parameters in the right way. I fixed it, and will publish it soon. > > >> I do have issues with INLINE markup (°) in that there is no way to nest >> at the moment. It is also "verbose" having to do °°match°°. >> > > Yea, Inline needs more love. It's the basic function only. similar to > @@match@@ So we don't win anything yet. Nesting like: > > °° xxxx °° yyyy °° zzz °° will never be possible. since the TW parser > doesn't work that way with inlines. There is the _need_ to have a uniquely > identifiable endstring. So the \customizeinline will need an _endString > param to make nesting possible. > > -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 tiddlywikidev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/c34cd0a0-6cd0-48c8-a663-887d28f37369n%40googlegroups.com.
