jeremy,
Thanks for your response.
The following is an outline of how I see this for a "view from a different
mind", for you to keep in mind going forward.
In all your examples of using wikify you tend to use it in the body of the
wikitext, just in time, wrapping its own output. I tend to run into
difficulty using it any other way, such as a local or global macro, and
when in your example there are "variables" in the source eg if your set
included {{!!fieldname}} or $tooltip$ etc... in what is to be wikified.
It is clear we need to fill out the documentation Pragma
<https://tiddlywiki.com/#Pragma> and Wikify Widget
<https://tiddlywiki.com/#WikifyWidget>, sometimes so people know this does
not promise things it may "on the surface"
for examples Question that arise from the naive
Pragma
- When using a rule inside a define is it valid only within that macro?
- When using it at the top of the tiddler does it apply to the whole
tiddler? including macros subsequently defined or referenced?
- Is using \import filter more efficient than global macros or the new
view only macros tag
- Where are the rules documented? Are they a one for one match with
these names $:/core/ui/ControlPanel/Parsing
I found the "undocumented "[wikiparserrules[]]" filter operator
Wikify
- With the Wikify widget is there a way for us to apply the pragma rules
to the result?
- The Wikify Widget <https://tiddlywiki.com/#WikifyWidget> would benefit
from examples and ideally through the various templates available already
in the core, so people can generate and store tiddlers in alternate formats
that already operate under export, save and other options.
- Storing the result of a wikify operation in the current wiki is also
of substantial value (I would detail if asked)
Parsing is of substantial interest to many, so I hope eventually we can
open this to users, especially to add our own markup. I and mario have
being looking at this with the leading dotparagraph and trailing
spacespace. Of course such markup will not be universal when tiddlers are
transferred but they can be made to "fail gracefully" when not defined.
The markup process provides the opportunity for authors and designers to
enhance how they input information into a wiki, in effect allowing the
development of other shorthand, custom shorthand can still be evaluated
into html or text, copy and paste etc.. and exported as standard content.
Regards
Tony
On Thursday, March 12, 2020 at 4:53:02 AM UTC+11, Jeremy Ruston wrote:
>
> Here’s a simple example of using the wikify widget:
>
> <$set name="text" value="This is ''bold'' and this is //italic//">
> <$wikify name="html" text=<<text>> output="html">
> <$text text=<<html>>/>
> </$wikify>
> </$set>
>
> And here’s the same example with the addition of adding the prefix:
>
> \define rules()
> \rules except italic
>
> \end
>
> <$set name="text" value="This is ''bold'' and this is //italic//">
> <$set name="text" value={{{ [<text>addprefix<rules>] }}}>
> <$wikify name="html" text=<<text>> output="html">
> <$text text=<<html>>/>
> </$wikify>
> </$set>
> </$set>
>
> Best wishes
>
> Jeremy
>
>
> On 10 Mar 2020, at 00:26, TonyM <anthon...@gmail.com <javascript:>> wrote:
>
> Jeremy, Stobot,
>
> Any method that can make wikify behave better would be appreciated.
>
> Jeremy, can you give an example of this please
>
>> One tip is to prepend the \rules pragma to the start of the text to be
>> wikified and thus restrict the wikitext rules that will be recognised.
>
>
> Stobot,
>
> - I think your pattern could be of great use, pending a better method
> if you could publish your code pattern with some examples It would be a
> good contribution and others may also show alternative ways to achieve the
> same thing.
> - There are a few cases where construction of filters before use would
> get around other limitations or the need for nested filters.
> - I am also starting to configure some longer filters as global macros
> such as standard-fields so they can be excluded from the result of the
> fields[] operator.
>
> Share Share Share
>
> Regards
> Tony
>
> On Tuesday, March 10, 2020 at 7:51:47 AM UTC+11, Jeremy Ruston wrote:
>>
>> Hi Stobot
>>
>> I don't know if anyone else builds things like I do - with a ton of
>> dynamic tables and branched lookups, but I use this pattern all the time:
>>
>> \define macrotobuildfilter() ...
>>
>> <$wikify name="macrotobuildfilterwiki" text=<<macrotobuildfilter>>>
>> <table>
>> <$list filter=<<macrotobuildfilterwiki>>>
>> ...
>> </$list>
>> </table>
>> </$wikfiy>
>>
>> That's just with one, but usually I have a few nested ones. In fact I'll
>> go so far as to say that more than half of the time I use a macro, I have
>> to wikify it before use as it's being used as a parameter for something
>> else.
>>
>>
>> The pattern you’re using here is a subtle one: to use the wikification
>> process to create filter strings. As you’ve probably gathered, it can be
>> quite brittle. For example, there can be problems if titles included in
>> your filter strings include wikitext markup (e.g. HTTP links contain an
>> embedded //). One tip is to prepend the \rules pragma to the start of the
>> text to be wikified and thus restrict the wikitext rules that will be
>> recognised.
>>
>> I've often thought of how great it would be to have that wikification
>> done in the same step - maybe with triple brackets like <<<wikified
>> macro>>> ? Similarities to the {{{...}}} notation in a way.
>>
>>
>> Yes, it’s somewhat anomalous that there isn’t a quoted attribute syntax
>> that returns the wikified value of the argument. Part of the reason is that
>> as Mat points out, wikification is a relatively slow process (unlike
>> wikifying the page we can’t do any selective refreshing, we have to process
>> the entire text on each refresh cycle).
>>
>> Is this possible? I see some other threads on additional parser rules, so
>> thought it might be a good time to bring up.
>>
>>
>> It might be worth experimenting with it, but I’d be concerned about
>> performance.
>>
>> An alternative approach that might be a bit easier would be to create a
>> pragma that’s a shortcut for the wikify widget. Something like:
>>
>> \define-with-wikification macrotobuildfilter() ...
>>
>> <table>
>> <$list filter=<<macrotobuildfilterwiki>>>
>> ...
>> </$list>
>> </table>
>>
>> An ordinary \define pragma generates a single <$set> widget; this new
>> pragma would generate a <$set> widget with a nested <$wikify> widget.
>>
>>
>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/parsers/wikiparser/rules/macrodef.js
>>
>> Best wishes
>>
>> Jeremy
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TiddlyWiki" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to tiddl...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/tiddlywiki/a0aff5bb-2aa3-4bc0-8094-72cf07c550a8%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/tiddlywiki/a0aff5bb-2aa3-4bc0-8094-72cf07c550a8%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tiddl...@googlegroups.com <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/d16dfbae-0bb9-403b-abf7-129918ba3ea1%40googlegroups.com
>
> <https://groups.google.com/d/msgid/tiddlywiki/d16dfbae-0bb9-403b-abf7-129918ba3ea1%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/78d04c90-9ea0-4ea2-8f55-9da55d1ff776%40googlegroups.com.
