Hi I am working on some tiddlywiki development tools and wondering if there were a way to import pragma/macro/procedure definitions from a textarea field in the current tiddler.
To illustrate this I will show code that does not work
\import [all[current]get[local-pragma]]
This would allow me to separate out any pragma from R&D tiddlers text field so there is no need to scroll down to the tiddler body as the pragma gets longer.
the Import variables widget has the same limitation as the filter only returns tiddler titles that are subsequently imported.
Perhaps there is a work around, however I would also be interested in seeing if a slight modification of the \import pragma or another created, could be made to get it working.
The pragma is defined here $:/core/modules/parsers/wikiparser/rules/import.js
perhaps modify the importvariables widget, however it will need to be closed at the bottom of the tiddler
it is defined here $:/core/modules/widgets/importvariables.js
perhaps this could be given additional parameters tiddler (defaults to current tiddler) and field. Its in Javascript so I can’t understand it.
Clone and modify to ImportVariablesHere is another approach
Why;
Keep the scope of the design effort to one tiddler, no need to define global values in separate tiddlers
When you have a lot of pragma simplify editing the body
Allow the local override of a core widget or macro like in a “sandbox”
Allow such tiddlers to be shared including their pragma
Developing new utility procedures, widget, functions and filters in a “sandbox” like tiddler.
No tagging etc… of an external tiddler.
I already have an equivalent form for a local view template that is drawn from a textarea field. I just add the field and the local view template is applied.
I may try and do something similar for local styles as well
Edit: The importvariables widget reads information from the tiddlers cached parseTree and “links” it to the current tiddler.
Tiddler fields are not parsed and not cached atm
Importing stuff from there would be slow
We also do not have a good editing UI for field text-areas in the core atm
While some of your “Why” arguments are valid there is na equal number of “contra” arguments against that functionality.
An additional one is code complexity and consistency
If users would want to overwrite “field pragmas” they would need to change the tiddler. But if the tiddler is a shadow-tiddler this would cause a lot of problems.
Hi @TW_Tones that code doesn’t work because the import pragma expects a filter that yields the titles of tiddlers containing the definitions. There is currently no way to import definitions from a field other that the default “text” field.
That is interesting to know, but I am not sure how important it is for one tiddler (at a time).
This is only for a single software development tiddler. Or an example to share, so I don’t think there is a performance issue, I can also automate a way to turn suchg a tiddler into a multi-tiller solution or plugin but only after development.
I am however bundling some support tiddlers with this solution.
eg I already have “a good editing UI for field text-areas” inside the editor view/
Yes, I understood that seemed to be the case. But I am trying to get around it.
The worst case may be to save a temp tiddler and import that.
As I said I already have a local-viewTemplate that works nicely but it can use a transclusion.
One possible approach might be to use the <$transclude> widget to import the contents of the field, and ensure that there is a <$slot> widget at the end of the definitions. Then when you transclude, you can include a matching <$fill> widget, and then the wikitext within that widget will have access to the imported definitions.