On Sunday, September 20, 2020 at 1:12:12 AM UTC+2, TonyM wrote: This idea is very powerful from a user perspective, but I have no idea how > achievable technically, please give it some thought. > > - If feasible it only needs the development of one new customise > feature reference the content > - My thought is a variable such as currentContent, idealy > $(currentContent)$ because then it is easy to concatinate > - eg to="$:/prefix/$(currentContent)$" > - This also raised the desire to access other variables in the pragma > such as current tiddler / storyTiddler or any if possible. > > The \pragma command is evaluated at "parsing time". There are no variables. They are created at that time.
> I am experimenting with customise to try and toggle something. > > - I realise that I would be useful if the content of the line could be > referenced in the "pragma" > > Here is a simple example I have "fudged" > \customize degree="button" _element="$button" to="Content" > °button Content > °button A Todo item > That's not the goal. ... Use \define and use macros for stuff like this. Don't try to use it that way it will and should never work. It will only create frustration. The button widget is a "frankenstein" widget. If you want to customize it, it has to fail! ... There is a reason, why Jeremy created all the action widgets. ... Because the button widget can't cope with all the different usecases. There is only 1 way, the <$button widget should be used also in standard TW. The existing parameters are there for compatibility, because we can't remove them. <$button actions=<<actions>> >button text</buttons> That's the __only__ way, that is available to customize it. ... That is one reason, why I wanted to create a new "copy-to-clipboard" widget. (Which I haven't atm) Widgets that can be customized in full HAVE to be structured in the way as <$list ... The schema has to be like this: <$widget-name param=value param=value param=value ... template=XXX > content to be worked with. </$widget-name> OR <$widget-name param=value param=value param=value > < content used as template> </$widget-name> > I have set the to="Content" as if I could have the content of the line > passed into the pragma. This navigates to a tiddler named "Content" however > I would like the second "button" to navigate to " A Todo item" > As I wrote. This will never work. If I would make the the \customize xxx to be able to work with a buttion I would create a "frankenstein \customize". So the only way it can work is the button structure that I did describe. I think (but not sure yet), the only way to solve this problem is a new XButton widget, that has a schema as described above. It may look like this: <$xbutton btn-text="click me" actions= template=XXX > content </$xButton> or This should be fully customizable, in the way it should be. I expect its obvious, > Yes it is, but at the moment _not_ all of the the existing widgets will allow us to customize them. They haven't been designed that way. Especially the really old ones, like the button-widget. > The ability to create toggles and new buttons and a lot more such as state > tiddlers/data indexes and much more would be possible by allowing the > content of the line be a parameter to the customised mark-up. > I'm not sure, it this should be the goal. We do have macros and "toggle buttons" and the like should be implemented that way ... and at the moment they have to! > For me this started with a desire to construct custom mark-up such as > °do An item I may have to do, quickly typed into a tiddler > > - Which could be used to generate a clickable item in the view > template to indicate complete > > I think this should be doable already. ... But I'm not sure. I'll need to test it. I would go with: https://grosinger.net/tw5-checklist/ instead. > Other possibilities > > - Click line > - to flag that line/paragraph for subsequent processing > - to create a tiddler by that title > - to places that text in a data tiddler with next nth key > > There is a lot of logic in the line above. ... eg: nth key need some logic to be incremented / changed. We are at "parser time"!!!! Logic needs to be done at rendering time, which is way later. > > - > - Turn text into a tag > - to copy line to keyboard > - Allowing footnotes to be created > - many more > > I can see, the desire. I did have it too. The plugin already has some code to "extract" the content between start: and _endString, for debugging purposes. BUT at the moment it seems, the different existing widgets, do know more about their context as they should. .. EG. Your checkbox example. °do - Some text Should be doable already. _but_ it fails with a RSOD. ... The <$checkbox widget creates a parsetree that is different, to mine. --> may be a bug in \customize \customize degree=do _element="$checkbox" tiddler=<<qualify "state/">> tag=done °do - Das ist ein Test Should work .. but doesn't -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/0a3d3be8-05ea-4f20-a88d-00c3fddb4da6o%40googlegroups.com.
