[twdev] Re: Adding client-specific appearance tweaks panel under Control Panel -> Appearance

[TonyM]

donmor,

Thanks for continuing development on tiddloid. It is a valuable 
contribution. 

I was wondering if you are joining us on discourse?. I would like to 
initiate a private conversation on something that may be of interest and it 
would be easier over there because we can avoid emails.

Regards
TW_Tones



On Monday, 10 May 2021 at 10:20:37 UTC+10 donmor3000 wrote:

> I'm testing new Tiddloid/Lite versions, which requires special system 
> tiddlers for per-wiki configurations. A PR to TiddlyWiki5 
>  was created days 
> before to add a tab into Control Panel, but has been not active fora month.
> Here's the effect of the new version of Tiddloid/Lite with configuration 
> pages inserted:
> [image: 113657945-a4ac0400-96d1-11eb-9e6e-39ffee4f9f2d.png][image: 
> 113658858-6d3e5700-96d3-11eb-8bdb-2f5be4dce806.png]
> The first option hides the toolbar on page finished to load by setting 
> `$:/config/Tiddloid/HideToolbar` to `yes`. The second option makes 
> Tiddloid/Lite get background color from current palette and apply it to the 
> toolbar and system bars by setting `$:/config/Tiddloid/ApplyTheme` to `yes`.
> Some of the European translates uses Google Translate, which requires 
> correction.
> By now I'm not sure it's necessary to put this panel in every new copy of 
> empty wiki, which makes these features available out of box, but is useless 
> for those never use Tiddloid/Lite. Another way is to make these contents as 
> a plugin in the official plugin store, users have to install it manually, 
> but increases portability, especially for old TW5 versions. Which way is 
> better? Urging for replies.
>

-- 
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/fbdd0df8-8f67-4c73-b665-ae7b39229e0dn%40googlegroups.com.

[twdev] Re: Tiddloid - A new android editor is to be released

[TonyM]

Donmor,

Please see if you can get this into a store and charge a few bucks so we 
can return something for your effort. Even if you leave the apks for the 
poorer amongst us :)

Love your work
Tones

On Monday, 10 May 2021 at 09:36:36 UTC+10 donmor3000 wrote:

> A new version (1.4.0) is coming. Go to the GitHub Release 
>  page to get the 
> testing packages.
>
> *Update details:*
>
>- Main activity and splash now supports landscape mode
>- Now showing size of each files
>- Fixed the problem that "open in new window" operation crashes the 
>page. Now opening a dialog for this operation.
>- Now supports changing theme color to adapt to the page, or hiding 
>toolbar on page loaded (configure inside each wiki).
>- Now supports "print page" operation
>- Now supports forking TiddlyWiki Classic sites.
>- Refactored application data structure
>- Application data backup/restore(hidden operations)
>- Other bug fixes and performance improvements
>
> Please note: These packages is for early access only. Feel free to post 
> issues and PRs on GitHub .
> 在2019年11月21日星期四 UTC+8 上午11:57:42 写道：
>
>> Thanks so much for updating and Developing Tiddloid.
>>
>> Tony
>>
>>
>> On Wednesday, November 20, 2019 at 11:42:15 PM UTC+11, donmor3000 wrote:
>>>
>>> A new release (1.3.6) came out. It  is recommended to go to the GitHub 
>>> page to get it.
>>> Update detail:
>>>
>>>- Direct export now supports getting filename from TiddlyWiki
>>>- Fixed the bug that the backup files not removed after Wiki rolled 
>>>back
>>>
>>> BTW the patch to the TiddlyWiki has been merged to master and should be 
>>> with the next version (5.1.22)
>>>
>>

-- 
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/9e9a5070-057e-4838-9e34-8b03092100a7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

Here is a summary of the existing glyphs
I established this with this site https://unicode-table.com/en/

Latin-1 Supplement › Acute Accent
´ tick
´ Acute Accent
U+00B4

 Latin-1 Supplement › Degree Sign
°
° Degree Sign
U+00B0
 


 Small Form Variants › Small Left Parenthesis
﹙
﹙ Small Left Parenthesis
U+FE59

 Latin-1 Supplement › Pilcrow Sign
¶
¶ Pilcrow Sign
paragraph sign
U+00B6

Braille Patterns › Braille Pattern Dots-25
⠒
⠒ Braille Pattern Dots-25
U+2812
 
 
Braille Patterns › Braille Pattern Dots-2356
⠶
⠶ Braille Pattern Dots-2356
U+2836
 
 
 Mathematical Operators › Almost Equal To
≈
≈ Almost Equal To
asymptotic to
U+2248

Latin-1 Supplement › Right-Pointing Double Angle Quotation Mark
»
» Right-Pointing Double Angle Quotation Mark
right guillemet, >>
U+00BB


Unicode Block Description Coverage
U+0370–U+03FF Greek and Coptic 135 glyphs
U+2070–U+209F Superscripts and Subscripts 48 glyphs
U+2200–U+22FF Mathematical Operators 256 glyphs
U+2300–U+23FF Miscellaneous Technical 256 glyphs
U+27C0–U+27EF Miscellaneous Mathematical Symbols-A 48 glyphs
U+2980–U+29FF Miscellaneous Mathematical Symbols-B 128 glyphs
U+2A00–U+2AFF Supplemental Mathematical Operators 256 glyphs
Glyph Variants (not all math) 1353 glyphs


Regards
Tony
On Friday, 11 December 2020 at 06:02:52 UTC+11 @TiddlyTweeter wrote:

> *Problems Of Working In The Dark*
>
> One of the biggest issues I have had is getting a CONSISTENT approach to 
> both determining "Candidate Markup Glyphs" AND sharing them.
>
> I mean, before we go too far,  would it not be a good idea to identify by 
> U+0023 numbers what we are talking about? Both for favourite pairings, or 
> simple glyphs that strike you for markup?
>
> IF you give me the numbers I can begin to think easier how to extract them 
> from a font!
>
> Best wishes
> TT
>

-- 
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/d4078bbb-3f1d-481b-b51a-e4cb81f93c73n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Perhaps I should have emphasised obtain or  build our own WOFF file for a 
last resort font.  

In the Katex plugin the 
$:/plugins/tiddlywiki/katex/fonts/KaTeX_Math-Italic.woff 
<https://anthonymuscio.github.io/empty-pre-release.html#%24%3A%2Fplugins%2Ftiddlywiki%2Fkatex%2Ffonts%2FKaTeX_Math-Italic.woff>
 tiddler 
is only 30kb in size.

Regards
Tones 

On Wednesday, 9 December 2020 at 23:02:28 UTC+11 PMario wrote:

> On Wednesday, December 9, 2020 at 4:58:35 AM UTC+1 TonyM wrote:
>
> Many of the additional characters for maths is available inside the Katex 
>> plugin with the use of Woff files,  this plugin is less than 1mb in size.
>>
>
> If a font is about 1 MByte I'd add it to my PC, but in now way I would 
> want to add it to my wiki. I'm thinking about something in the 10th of 
> kiloBytes up to 100+kByte, that is acceptable. 
>
> -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/8b8ab6b9-b2a5-4b79-b12f-ae7a96c2439fn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Observation,

Many of the additional characters for maths is available inside the Katex 
plugin with the use of Woff files,  this plugin is less than 1mb in size.

*The Web Open Font Format (WOFF) is a font 
<https://en.wikipedia.org/wiki/Font> format for use in web 
<https://en.wikipedia.org/wiki/World_Wide_Web> pages. WOFF files 
are OpenType <https://en.wikipedia.org/wiki/OpenType> or TrueType 
<https://en.wikipedia.org/wiki/TrueType> fonts, with format-specific 
compression applied and additional XML 
<https://en.wikipedia.org/wiki/XML> metadata added. The two primary goals 
are to first distinguish font files intended for use as web fonts from 
fonts files intended for use in desktop applications via local 
installation, and second to reduce web font latency when fonts are 
transferred from a server to a client over a network connection. * 

If we could interrogate these fonts, identify the glyphs we use for 
customise in there and the we could make the katex plugin a co-requisit, or 
build our own WOFF file for a last resort font.

However my own experience is most devices can now show most "international" 
codepoints.

Tony
On Wednesday, 2 December 2020 at 16:28:41 UTC+11 TonyM wrote:

> Sorry Wrong link in my reply, part of my development.
>
> See https://www.unicode.org/Public/UCD/latest/ucd/BidiBrackets.txt for 
> open and close pairs.
>
> Tony
>
>
> On Wednesday, 2 December 2020 at 16:26:45 UTC+11 TonyM wrote:
>
>> *TT, et al*
>>
>> Yes lets start "* Unicode and Font Support in TW* " thread, however I 
>> was keen to make it easier for us to finalise on our glyphs to support 
>> closing that issue., thus relevant to this thread.
>>
>> This may be a possibility to build our own targeted font, but its looking 
>> to me like most platforms have access to glyphs for a wide range of Unicode 
>> already. 
>>
>> I also think making the fonts visible can also be an option. If we 
>> publish a wiki, and we rely on Unicode characters for customise,  and 
>> present output without those same characters visible, just used in code, 
>> all should work as expected. Only when editing a tiddler containing such 
>> characters they would not be able to read them, or tell them apart,  if 
>> they do not have the correct font. Ie functionality remains, visibility 
>> does not. The customise plugin can display these critical characters and 
>> note if they appear all the same, they need to update fonts available to 
>> view the glyphs. Or activate a sub-font with the select glyphs defined.
>>
>> From what I can see so far, a lot of platforms will have little trouble 
>> with the vast majority of Unicode Characters because of the sets commonly 
>> distributed to devices.
>>
>> *Jeremy,*
>> Interesting and Curious what you saw, I never did because I do not use 
>> rounded buttons. Many Unicode characters have different widths which must 
>> give rise to this.
>>
>> *PMario et al, Inline;*
>>
>> I just found this document which contains the matched braces available 
>> throughout Unicode 
>> https://www.unicode.org/Public/UCD/latest/ucd/Blocks.txt which may prove 
>> useful in the subsequent inline features.
>>
>> I continue to work on compiling information in a searchable tiddlywiki 
>> for managing "any" Unicode character or range.
>>
>> Tony
>> On Wednesday, 2 December 2020 at 04:42:53 UTC+11 @TiddlyTweeter wrote:
>>
>>> Ciao TonyM & PMario
>>>
>>> TonyM wrote:
>>>
>>>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>>>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>>>> <https://anthonymuscio.github.io/PreReleaseGlyphs.html> 
>>>>
>>>
>>> *TonyM*: That demo shows the issues arising over font support are 
>>> generic---Not Just for PMario Markup. I think we should pursue the broader 
>>> scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
>>> to start it? I have some solutions in mind. But they are refactory to this 
>>> thread.
>>>
>>> *PMario*: I think TonyM is *definitely heading in the right direction* 
>>> on trying to pin down font support issues for your Custom Markup by 
>>> illustration.
>>> I can see the beginning of a *solution*. One where reliable markup 
>>> glyphs could be always relied upon whatever platform you are on. It would 
>>> be *a very minimal font embedded in TW for JUST markup glyphs. It would 
>>> be kilobytes, not megabytes*. To get to the point of pro

[twdev] Re: Peer Review please Cheat sheet

[TonyM]

Saq,

As you are aware the wikification process is linked to the render process. 
I am trying to keep this issue focused and fix the gap I have highlighted. 
The term I try and use is "evaluate", basically to resolve a value from the 
wikitext elements and use it in logic and other tests, ideally without 
wikification, but evaluation. Can these be separated?, if not then 
wikification would be a good target for preperformance improvements, it's a 
nexus between the parsing and rendering, logic and practical use.

*Just as {{||template}} is not supported as a widget attribute, 
{{{filter||template}}} is not supported for filtered attributes. *

I am not so sure about this statement. I understood the template 
pre-processes the result then delivers the value(s) to the attribute. I 
will look more closely.

Tones
On Friday, 4 December 2020 at 09:29:56 UTC+11 saq.i...@gmail.com wrote:

> @Tones wiki syntax for transclusions, and syntax for indirect and filtered 
> attributes for widgets, are two entirely different things and changing them 
> would not be backwards compatible.
>
> Refer to this thread that explains the same difference but with regards to 
> double brace transclusions and indirect attributes: 
> https://groups.google.com/g/tiddlywiki/c/YCdcBV88h_g
>
> Just as {{||template}} is not supported as a widget attribute, 
> {{{filter||template}}} is not supported for filtered attributes.
> The filter is evaluated and the literal result of the filter is assigned 
> to the attribute. Filters do not have any concept of templates.
>
> Regarding wikify, due to the performance implications, it is my personal 
> opinion that we should NOT be facilitating its' usage and associated code 
> patterns, and instead should be leading users towards more optimal ways of 
> doing things. Wikify should be a tool of last resort when there are no 
> alternative ways of doing the same thing. If you look through the TW core 
> you will see that wikify is used exceedingly sparingly even though the 
> entire UI is built from wikitext. Ultimately, however, it is not my call as 
> what is supported in the core or not so its not me that you need to 
> convince. :)
>
> That said, I do completely agree that we do need some better form of 
> variable substitution or string templating support.
> Cheers,
>
> Saq
> On Thursday, December 3, 2020 at 11:17:24 PM UTC+1 TonyM wrote:
>
>> Saq,
>>
>> In effect are you a saying in the latter the reference to the value is 
>> the result rather than the value?, I understand the complexities here (I 
>> think) however I expect 99% of users 
>>
>>- Do not understand this distinction
>>- Think the value is returned, and expects it in filter logic
>>
>> This is why I believe strongly we should provide a short method to do 
>> this and my issue <https://github.com/Jermolene/TiddlyWiki5/issues/5110>
>>
>> Regards
>> Tones
>> On Thursday, 3 December 2020 at 20:32:33 UTC+11 saq.i...@gmail.com wrote:
>>
>>> An important distinction to make is that between filtered transclusions 
>>> in wikitext, and filtered attributes for widgets.
>>>
>>> In the former, the {{{ filter || template }}} format is supported 
>>> because the output gets wikified.
>>> In the latter, this is not supported as the literal value of the filter 
>>> is assigned to the attribute, similar to attribute={{!!field}}
>>>
>>

-- 
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/3a4d9328-65b2-4a47-a991-4af0e480a445n%40googlegroups.com.

[twdev] Re: Peer Review please Cheat sheet

[TonyM]

Saq,

In effect are you a saying in the latter the reference to the value is the 
result rather than the value?, I understand the complexities here (I think) 
however I expect 99% of users 

   - Do not understand this distinction
   - Think the value is returned, and expects it in filter logic

This is why I believe strongly we should provide a short method to do this 
and my issue 

Regards
Tones
On Thursday, 3 December 2020 at 20:32:33 UTC+11 saq.i...@gmail.com wrote:

> An important distinction to make is that between filtered transclusions in 
> wikitext, and filtered attributes for widgets.
>
> In the former, the {{{ filter || template }}} format is supported because 
> the output gets wikified.
> In the latter, this is not supported as the literal value of the filter is 
> assigned to the attribute, similar to attribute={{!!field}}
>

-- 
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/9ca0c9dc-9d9c-48ea-b81f-7eefe9078136n%40googlegroups.com.

[twdev] Re: Peer Review please Cheat sheet

[TonyM]

codaCoda,

I have updated the content of "&" to return text only
<$text text={{{ [all[current]split[ ]] +[join[]] }}}/>

*Important guidance* is 

   - the "filter" given to the transclusion needs each value to be treated 
   as a title hence 
  - $:/string/ [] / [{!!fieldname}] [[/suffix/]] [all[current]]
  - except for literals without white space, we need to wrap it in at 
  least one [ ]
   

I think typically we are forced to use wikify still rather than set or vars 
to get such variables to operate in a filter.
<$set name=ghost-tiddler value={{{ $:/ghost/ [all[current]] || & }}}>
<$link to=<>/>
<$list filter="[has[title]]" emptyMessage="No ghost">
Ghost tiddler <> exists



This does just not result in <> "$:/ghost/*currentTiddler*"

I have raised this issue 
<https://github.com/Jermolene/TiddlyWiki5/issues/5110>, but Saq has an 
argument that wikify is a poor performer.

Regards
Tony
On Thursday, 3 December 2020 at 12:41:51 UTC+11 codacoder...@outlook.com 
wrote:

> Tony - Looks good on  a first pass... I'll need to look at it properly 
> tomorrow (it's late here).
>
> On Wednesday, December 2, 2020 at 6:59:28 PM UTC-6 TonyM wrote:
>
>> And using codaCodas examples prior;
>>
>> <$wikify name=style-value text="""color: {{!!color}}""">
>>  style=<> 
>>   
>>
>> Check this in 
>> devtools  
>>
>> Check this in devtools  
>>
>> Again great for attribute values and parameters, but still need another 
>> step to get the result into a filter.
>>
>> Tony
>>
>> Tones
>> On Thursday, 3 December 2020 at 11:46:41 UTC+11 TonyM wrote:
>>
>>> Saq et al,
>>>
>>> Thinking a little further on this issue of "inline concatenation of 
>>> various tiddlywiki values", I believe I have just found a quite elegant 
>>> solution.
>>> Given your complaint about Wikification performance this returns the 
>>> "evaluated text"
>>>
>>> Create a tiddler called "&" for concatenate containing
>>> {{{ [split[ ]] +[join[]] }}}
>>>
>>> This spits the input by spaces/run and then joins them.
>>>
>>> Now to concatenate use;
>>> {{{ filter || & }} 
>>> {{{ filter-run filter-run ||&}}
>>>
>>> Where filter can access any value available to a filter, use space 
>>> separation of runs
>>> {{{ $:/string/ [] / [{!!fieldname}] [[/suffix]] ||&}}} 
>>> {{{ $:/string/ [] / [{!!fieldname}] [[/suffix/]] [all[current]] 
>>> ||&}}}
>>> {{{ $:/system/ [] ||&}}
>>>
>>> Now I am already taking this code pattern further, 
>>>
>>>- This allows the concatenation of values passed as a parameter/set 
>>>of filters
>>>- but for efficient use I know need to determine the best way to get 
>>>a result into a filter. I expect we must use set or vars.
>>>
>>> Regards
>>> Tony
>>> On Thursday, 3 December 2020 at 04:28:23 UTC+11 saq.i...@gmail.com 
>>> wrote:
>>>
>>>> @codacoder There are issues on github discussing both approaches, using 
>>>> backticks to wikify OR using them to do substitution. I strongly prefer 
>>>> the 
>>>> latter due to the performance penalty associated with wikify.
>>>>
>>>> See
>>>>
>>>>- https://github.com/Jermolene/TiddlyWiki5/issues/5121
>>>>- https://github.com/Jermolene/TiddlyWiki5/issues/5110
>>>>
>>>> But let's not derail Tony's thread by going too far off topic. If we 
>>>> want to discuss this further we should start a new thread.
>>>>
>>>> Cheers,
>>>> Saq
>>>>
>>>

-- 
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/d7daf9fe-f668-488b-8f65-bcd8dc9806d0n%40googlegroups.com.

[twdev] Re: Peer Review please Cheat sheet

[TonyM]

And using codaCodas examples prior;

<$wikify name=style-value text="""color: {{!!color}}""">
 style=<> 
  

Check this in 
devtools  

Check this in devtools  

Again great for attribute values and parameters, but still need another 
step to get the result into a filter.

Tony

Tones
On Thursday, 3 December 2020 at 11:46:41 UTC+11 TonyM wrote:

> Saq et al,
>
> Thinking a little further on this issue of "inline concatenation of 
> various tiddlywiki values", I believe I have just found a quite elegant 
> solution.
> Given your complaint about Wikification performance this returns the 
> "evaluated text"
>
> Create a tiddler called "&" for concatenate containing
> {{{ [split[ ]] +[join[]] }}}
>
> This spits the input by spaces/run and then joins them.
>
> Now to concatenate use;
> {{{ filter || & }} 
> {{{ filter-run filter-run ||&}}
>
> Where filter can access any value available to a filter, use space 
> separation of runs
> {{{ $:/string/ [] / [{!!fieldname}] [[/suffix]] ||&}}} 
> {{{ $:/string/ [] / [{!!fieldname}] [[/suffix/]] [all[current]] ||&}}}
> {{{ $:/system/ [] ||&}}
>
> Now I am already taking this code pattern further, 
>
>- This allows the concatenation of values passed as a parameter/set of 
>filters
>- but for efficient use I know need to determine the best way to get a 
>result into a filter. I expect we must use set or vars.
>
> Regards
> Tony
> On Thursday, 3 December 2020 at 04:28:23 UTC+11 saq.i...@gmail.com wrote:
>
>> @codacoder There are issues on github discussing both approaches, using 
>> backticks to wikify OR using them to do substitution. I strongly prefer the 
>> latter due to the performance penalty associated with wikify.
>>
>> See
>>
>>- https://github.com/Jermolene/TiddlyWiki5/issues/5121
>>- https://github.com/Jermolene/TiddlyWiki5/issues/5110
>>
>> But let's not derail Tony's thread by going too far off topic. If we want 
>> to discuss this further we should start a new thread.
>>
>> Cheers,
>> Saq
>>
>

-- 
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/a01afb1b-dc15-4cea-9863-6b75c92a2706n%40googlegroups.com.

[twdev] Re: Peer Review please Cheat sheet

[TonyM]

Saq et al,

Thinking a little further on this issue of "inline concatenation of various 
tiddlywiki values", I believe I have just found a quite elegant solution.
Given your complaint about Wikification performance this returns the 
"evaluated text"

Create a tiddler called "&" for concatenate containing
{{{ [split[ ]] +[join[]] }}}

This spits the input by spaces/run and then joins them.

Now to concatenate use;
{{{ filter || & }} 
{{{ filter-run filter-run ||&}}

Where filter can access any value available to a filter, use space 
separation of runs
{{{ $:/string/ [] / [{!!fieldname}] [[/suffix]] ||&}}} 
{{{ $:/string/ [] / [{!!fieldname}] [[/suffix/]] [all[current]] ||&}}}
{{{ $:/system/ [] ||&}}

Now I am already taking this code pattern further, 

   - This allows the concatenation of values passed as a parameter/set of 
   filters
   - but for efficient use I know need to determine the best way to get a 
   result into a filter. I expect we must use set or vars.
   
Regards
Tony
On Thursday, 3 December 2020 at 04:28:23 UTC+11 saq.i...@gmail.com wrote:

> @codacoder There are issues on github discussing both approaches, using 
> backticks to wikify OR using them to do substitution. I strongly prefer the 
> latter due to the performance penalty associated with wikify.
>
> See
>
>- https://github.com/Jermolene/TiddlyWiki5/issues/5121
>- https://github.com/Jermolene/TiddlyWiki5/issues/5110
>
> But let's not derail Tony's thread by going too far off topic. If we want 
> to discuss this further we should start a new thread.
>
> Cheers,
> Saq
>

-- 
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/e5da025d-4718-4a60-af6c-6f54bad0ed9dn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Sorry Wrong link in my reply, part of my development.

See https://www.unicode.org/Public/UCD/latest/ucd/BidiBrackets.txt for open 
and close pairs.

Tony


On Wednesday, 2 December 2020 at 16:26:45 UTC+11 TonyM wrote:

> *TT, et al*
>
> Yes lets start "* Unicode and Font Support in TW* " thread, however I was 
> keen to make it easier for us to finalise on our glyphs to support closing 
> that issue., thus relevant to this thread.
>
> This may be a possibility to build our own targeted font, but its looking 
> to me like most platforms have access to glyphs for a wide range of Unicode 
> already. 
>
> I also think making the fonts visible can also be an option. If we publish 
> a wiki, and we rely on Unicode characters for customise,  and present 
> output without those same characters visible, just used in code, all should 
> work as expected. Only when editing a tiddler containing such characters 
> they would not be able to read them, or tell them apart,  if they do not 
> have the correct font. Ie functionality remains, visibility does not. The 
> customise plugin can display these critical characters and note if they 
> appear all the same, they need to update fonts available to view the 
> glyphs. Or activate a sub-font with the select glyphs defined.
>
> From what I can see so far, a lot of platforms will have little trouble 
> with the vast majority of Unicode Characters because of the sets commonly 
> distributed to devices.
>
> *Jeremy,*
> Interesting and Curious what you saw, I never did because I do not use 
> rounded buttons. Many Unicode characters have different widths which must 
> give rise to this.
>
> *PMario et al, Inline;*
>
> I just found this document which contains the matched braces available 
> throughout Unicode 
> https://www.unicode.org/Public/UCD/latest/ucd/Blocks.txt which may prove 
> useful in the subsequent inline features.
>
> I continue to work on compiling information in a searchable tiddlywiki for 
> managing "any" Unicode character or range.
>
> Tony
> On Wednesday, 2 December 2020 at 04:42:53 UTC+11 @TiddlyTweeter wrote:
>
>> Ciao TonyM & PMario
>>
>> TonyM wrote:
>>
>>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>>> <https://anthonymuscio.github.io/PreReleaseGlyphs.html> 
>>>
>>
>> *TonyM*: That demo shows the issues arising over font support are 
>> generic---Not Just for PMario Markup. I think we should pursue the broader 
>> scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
>> to start it? I have some solutions in mind. But they are refactory to this 
>> thread.
>>
>> *PMario*: I think TonyM is *definitely heading in the right direction* 
>> on trying to pin down font support issues for your Custom Markup by 
>> illustration.
>> I can see the beginning of a *solution*. One where reliable markup 
>> glyphs could be always relied upon whatever platform you are on. It would 
>> be *a very minimal font embedded in TW for JUST markup glyphs. It would 
>> be kilobytes, not megabytes*. To get to the point of proof-of-concept I 
>> need some days yet, but I'm getting close. Its just trudge over the Unicode 
>> BMP to establish which fonts would provide the glyphs needed, cost free, to 
>> make a good "TW-MarkupGlyphsFont".
>>
>> Best wishes
>> TT
>>
>

-- 
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/254bd64c-2d67-4699-92f0-bfad14928793n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

*TT, et al*

Yes lets start "* Unicode and Font Support in TW* " thread, however I was 
keen to make it easier for us to finalise on our glyphs to support closing 
that issue., thus relevant to this thread.

This may be a possibility to build our own targeted font, but its looking 
to me like most platforms have access to glyphs for a wide range of Unicode 
already. 

I also think making the fonts visible can also be an option. If we publish 
a wiki, and we rely on Unicode characters for customise,  and present 
output without those same characters visible, just used in code, all should 
work as expected. Only when editing a tiddler containing such characters 
they would not be able to read them, or tell them apart,  if they do not 
have the correct font. Ie functionality remains, visibility does not. The 
customise plugin can display these critical characters and note if they 
appear all the same, they need to update fonts available to view the 
glyphs. Or activate a sub-font with the select glyphs defined.

>From what I can see so far, a lot of platforms will have little trouble 
with the vast majority of Unicode Characters because of the sets commonly 
distributed to devices.

*Jeremy,*
Interesting and Curious what you saw, I never did because I do not use 
rounded buttons. Many Unicode characters have different widths which must 
give rise to this.

*PMario et al, Inline;*

I just found this document which contains the matched braces available 
throughout Unicode https://www.unicode.org/Public/UCD/latest/ucd/Blocks.txt 
which may prove useful in the subsequent inline features.

I continue to work on compiling information in a searchable tiddlywiki for 
managing "any" Unicode character or range.

Tony
On Wednesday, 2 December 2020 at 04:42:53 UTC+11 @TiddlyTweeter wrote:

> Ciao TonyM & PMario
>
> TonyM wrote:
>
>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>> <https://anthonymuscio.github.io/PreReleaseGlyphs.html> 
>>
>
> *TonyM*: That demo shows the issues arising over font support are 
> generic---Not Just for PMario Markup. I think we should pursue the broader 
> scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
> to start it? I have some solutions in mind. But they are refactory to this 
> thread.
>
> *PMario*: I think TonyM is *definitely heading in the right direction* on 
> trying to pin down font support issues for your Custom Markup by 
> illustration.
> I can see the beginning of a *solution*. One where reliable markup glyphs 
> could be always relied upon whatever platform you are on. It would be *a 
> very minimal font embedded in TW for JUST markup glyphs. It would be 
> kilobytes, not megabytes*. To get to the point of proof-of-concept I need 
> some days yet, but I'm getting close. Its just trudge over the Unicode BMP 
> to establish which fonts would provide the glyphs needed, cost free, to 
> make a good "TW-MarkupGlyphsFont".
>
> Best wishes
> TT
>

-- 
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/bf0c0e64-bd67-455a-a6fe-2cf9d25fcb0bn%40googlegroups.com.

[twdev] Re: Peer Review please Cheat sheet

[TonyM]

CodaCoda,

Yes I understand that, but I will review the cheat sheet to see if I give 
it sufficient weight.

Did you look at the online 
version https://anthonymuscio.github.io/#Standard%20Nomenclature the 
filtered transclusions section could promote its use more.

Tony

On Wednesday, 2 December 2020 at 06:40:53 UTC+11 codacoder...@outlook.com 
wrote:

> Hi Tony
>
> Bold effort!
>
> I spotted something in there that I do quite often, but I do it a little 
> differently:
>
> You: 
>
> <$wikify name=style-value text="""color: {{!!color}}""">
>  style=<> 
>   
>
> Me:
>
> Check this in 
> devtools
>
> Not sure which you might prefer...
>
>
> On Thursday, October 1, 2020 at 8:13:01 PM UTC-5 TonyM wrote:
>
>> Folks,
>>
>> This working tiddler is published here;
>>
>> https://anthonymuscio.github.io/#Standard%20Nomenclature
>>
>> Regards
>> Tony
>>
>>
>> On Thursday, 1 October 2020 12:17:43 UTC+10, TonyM wrote:
>>
>>> Folks,
>>>
>>> I have being building a "CheatSheet" that I would appreciate expert 
>>> review if possible. Please respond with references to the number of each 
>>> item.
>>>
>>> You can see it is built on Tobias and Eric's work to name a few. It 
>>> tries and make simple, some particularly tricky issues that new and 
>>> experienced users face.
>>>
>>> Regards
>>> Tony
>>>
>>> Important note:
>>>
>>>- The following is a Cheatsheet or quick reference to the following
>>>wikitext, variables, widgets, filters, operators and the use of 
>>>references variables, macros, html tags and their attributes/parameters
>>>- *Key widgets* that are used sometimes, for a complete solution are 
>>>$text <https://tiddlywiki.com/#TextWidget>, $macrocall 
>>><https://tiddlywiki.com/#MacroCallWidget>, $wikify 
>>><https://tiddlywiki.com/#WikifyWidget> and $transclude 
>>><https://tiddlywiki.com/#TranscludeWidget>, otherwise this 
>>>documentation relates to all widgets.
>>>- Many *non-coders* may find this intimidating however should keep 
>>>the following in mind;
>>>   - much of this is actually essential not just for programming, 
>>>   but logical necessary, similar to the use of punctuation in hand 
>>> writting.
>>>   - Whilst it may seem complex at first, the application of these 
>>>   rules is not only consistent throughout TiddlyWiki, but has a lot in 
>>> common 
>>>   with most other implementations of html, programming languages, 
>>> mark-up and 
>>>   a lot more.
>>>   - This document is a summary of things learned over a number of 
>>>   years by the author, don't expect to understand it overnight.
>>>   - Somewhere on this learning curve you will have to stop calling 
>>>   yourself a *non-coder*.
>>>- Prior knowledge of these will help, and regardless what you learn 
>>>to use TiddlyWiki it will include transferable skills.
>>>   - You are not required to learn much that is single purpose, and 
>>>   all will unleash the power of TiddlyWiki
>>>- In this cheat sheet the use of single square brackets indicates 
>>>something optional, eg; <> [params] means that 
>>>is optional.
>>>
>>> ❶ General wiki text (including inside macros)For additional 
>>> possibilities with inside macros see *❸ Within macro definitions* below.
>>>
>>>1. literal values when literal values are used as parameters or 
>>>attributes the quoting rules apply see *➃ Using literals and 
>>>parameters*
>>>2.   html tags immediate closure
>>>3.   later closure
>>>4. <> immediate closure, see ➀ for 
>>>later closure
>>>5. <$widgetname [params] /> immediate closure
>>>6. <$widgetname [params]> inside the widget  later 
>>>closure (for more see *➁ Content of widgets*)
>>>7. {{tiddlername}} transclude the content of the tiddlername's text 
>>>field and render
>>>8. {{!!fieldname}} transclude the content of the currentTiddlers 
>>>fieldname and render
>>>9. {{tiddlername!!fieldname}} transclude the content of the 
>>>tiddlername's fieldname and render
>>>10. {{{ [addprefix[$:/myprefix/]] }}} filtered 
>>>

[twdev] Re: Custom markup (continued 4)

[TonyM]

CodaCode

Nice to see someone else buying into the vision.

*Scoping rules*
> What is the scope of \somepragma? Is it possible to globally define them 
> easily? I feel like I'm missing something obvious here. Wondering if 
> $:/tags/Macro might do the job - it shouldn't but I'd understand if it did.
>
> Both local and global definition now exists, with local via either in 
wikitext or by import pragma


> *Pragma definitions*
> (@PMario) Like me, you were probably thankful when JavaScript started to 
> support arrow functions - the brevity alone lent itself to a boost in 
> productivity. Therefore I'm wondering why \customize can't be reduced:
>
>
It could be perhaps, Mario will consider your suggestions; however the 
definitions or customise pragma support such a broad and powerful range of 
uses that brevity in the definition may be unwise. The whole function of 
the new glyps and symbols it to create brevity by definitions. So perhaps 
brevity in the definition, is a abstraction too far. 

 I think the key place to play 
is https://wikilabs.github.io/editions/custom-markup/, look for any tiddler 
to see examples, this is not a curated site, just a practical one. Search 
and play.

You have swallowed the "red pill 
<https://en.wikipedia.org/wiki/Red_pill_and_blue_pill>". More the discovery 
of infinite scope than unpleasant truths.

TonyM

-- 
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/86ea8dad-3d3d-4cea-bc69-d4ee3c00e07cn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

This article lists glyphs supported by an intersection of a set of fonts 
<https://www.johndcook.com/blog/2013/04/11/which-unicode-characters-can-you-depend-on/>.
 
Perhaps we could take this list and present it in a tiddler, in a large 
font size and put it out to the user forum for people to test and report if 
all the glyphs are visible. Perhaps also in an empty.html at a URL people 
can just open an review on their various devices?

Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable 
Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
<https://anthonymuscio.github.io/PreReleaseGlyphs.html> 
 
So far up looking at  to 65000 on Windows 10 (Chrome, FireFox and Edge) 
most are honoured however I have various local fonts that may be doing this.
Android also works mostly.

Regards
Tony
On Friday, 27 November 2020 at 20:21:22 UTC+11 @TiddlyTweeter wrote:

> Ciao TonyM
>
> TonyM wrote:
>
>> The thing I find frustrating is fonts seem not to document the "code 
>> pages" they include.  There must be Unicode rich ones available for linux 
>> and apple and other devices as there is for Windows. 
>>
>
> I agree. *Frustrating* is the word. It is one of those areas of OS 
> process that is simultaneously BRILLIANT and CONFUSING.
>
> It is *brilliant *in that modern glyph end-usage got so much easier. 
> Thanks to Unicode + improved Font File Architecture + Substitution 
> metadata. 
> It is *confusing* in that the OS+software mediated process of 
> substitution actually now makes it difficult to answer simple questions 
> about which fonts to use where---because the substitution process 
> transparently does it automatically. Unraveling that is really for an 
> expert in that specific field now.
>
> I did some tests in TW to see if I could get it to use a special Test Font 
> that Adobe provide which indexes ALL Unicode code points to a "blank." 
> Doing that you can, in theory, set a CSS cascade such that you effectively 
> switch-off substitution (i.e. cascade: Font, BlankFont). that make it quick 
> and easy to know which fonts truly hold a glyph.
> Unfortunately Windows 10 doesn't directly support the indexing method the 
> AdobeBlankVF font file uses. 
>
> I'm still playing around with the idea though.
>
> Best wishes
> TT
>

-- 
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/55ffaa8d-652b-450a-8a62-d0369aea11e8n%40googlegroups.com.

Re: [twdev] date of build-time on prerelease-website?

[TonyM]

Jeremy,

When I look at the pre-release I always check recent, or the release notes 
but it is not consistent in indicating recent changes. 

Displaying the build would at least guide us a little.

Eg make the subtitle 
<> <$text text={{{ [{$:/build}split[ at ]last[]] }}}/>

Tones


On Friday, 27 November 2020 at 21:14:32 UTC+11 Jeremy Ruston wrote:

> Hi Mirko
>
> There is a $:/build tiddler with that information, but I agree it would be 
> handy to make it more accessible.
>
> https://tiddlywiki.com/prerelease/#%24%3A%2Fbuild
>
> Best wishes
>
> Jeremy
>
> --
> Jeremy Ruston
> jer...@jermolene.com
> https://jermolene.com
>
> On 27 Nov 2020, at 09:43, Mirko Richter  wrote:
>
> 
>
> Hi,
>
> just an idea/thought: wouldn't it be easy and helpful (at least for me ;) 
> ) to have the modified-field for the "TiddlyWiki Pre-release"-Tiddler on 
> https://tiddlywiki.com/prerelease/ set to the build-date? I'm always 
> asking myself: is some feature from master already in or not?
>
> BW,
> Mirko
>
> -- 
> 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 tiddlywikide...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/tiddlywikidev/cac3a51d-9229-43ba-a284-dc5bba44eb95n%40googlegroups.com
>  
> 
> .
>
>

-- 
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/613d4204-a175-4726-bc68-46d2721493ccn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

It would be interesting to look at a selective font, as a last resort, that 
we could embed in tiddlywiki with only the symbols we need. I have seen 
font builders around but it remains a bit of a dark art to me. Most users 
such as myself have most of the Unicode covered (as I use Windows 10) so a 
local font is likely to satisfy the requirements. I would be surprised if 
any would have to revert to the last resort font if we choose the fonts 
correctly (or check the existing ones)

However I am not sure this is needed.

Font Family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, 
Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"
Code Font Family: "SFMono-Regular",Consolas,"Liberation 
Mono",Menlo,Courier,monospace


   - Then inside $:/themes/tiddlywiki/vanilla/base we see different font 
   family provided to different html elements. So in the development process 
   some recommendations have being followed or some serious analysis of fonts 
   generally available have being selected.
  - Perhaps we can find some updated recommendations that include the 
  additional character sets we need for all platforms.
  - In the above we may need to extend the Code Font Family.
   - If necessary we can just add via an additional stylesheet.
   - As I understand this we are listing fonts to use "if they exist 
   locally" and if they do not it reverts to the next best (using some details 
   of the fonts available)
   - When using customise we need to see our glyphs, and they do not appear 
   in the output, So a Tiddlywiki delivered to an audience that is not reading 
   the code it would not matter if no font exists for those Unicodes, the 
   customise should still work even without font glyphs available.

The thing I find frustrating is fonts seem not to document the "code pages" 
they include.  There must be Unicode rich ones available for linux and 
apple and other devices as there is for Windows. 

Tones

On Thursday, 26 November 2020 at 21:52:56 UTC+11 @TiddlyTweeter wrote:

> *Font-ish Thoughts ... *
>
> Ciao TonyM & PMario
>
> TonyM wrote:
>
>> What I did discover is the following 
>> <https://keyboard.cool/db/enclosed-alphanumeric-supplement/regional-indicator-symbol-letter-a>
>>  includes 
>> the letter symbols  -  and other sets. Some of which will show a color 
>> icon with the right fonts
>> [image: Snag_2a82c66a.png]
>> My thought is what if the glyphs available are from a set that an 
>> (optional) web font presents in an enhanced color form. Something one could 
>> toggle on/off? between plain and coloured.
>> In edit these would be bright and easy to see, but after wikification and 
>> when acting as customise symbols they are invisible. 
>>
>
> Right. Interesting ideas. If you look back you will see brief discussion 
> between me and PMario concerning *ways round the 'local machine' font 
> problem*.
>
> I think its worth commenting on some of the options ---
>
> 1 - *Use Web Fonts From Web. *I think PMario would not be too keen on 
> this as you'd need to online connect your wiki to a distant server and all 
> that involves. 
>
> 2 - *Use Web Fonts Once Downloaded. *Many free web fonts can be 
> downloaded. DOWNSIDE: adds *a lot *of complexity to set-up.
>
> 3 - *Embed Glyphs in a Custom Font that comes with the plugin*. This 
> might be good. ISSUES: What size would it be? Who would have knowledge how 
> to make it? And have the time? 
>
> Best wishes
> TT
>

-- 
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/e6ad8f93-bfcf-4a90-b80a-d7fb0280aca7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Gentlemen,

Sometimes one can fall into a Unicode rabbit hole.

Here however I present a few desirable forms, for which we should consider 
if their font support is robust.

Using this link one can see a set of 
brackets. https://keyboard.cool/db/search?q=bracket
To me some share a likeness to existing markup symbols such as 

   - ⦃ tiddler title and transclusion ⦄
   - Space〖tiddler title and parenthesis〗with space
   - Perhaps even a block form 
   ︗
   Inside block
   ︘

What I did discover is the following 
<https://keyboard.cool/db/enclosed-alphanumeric-supplement/regional-indicator-symbol-letter-a>
 includes 
the letter symbols  -  and other sets. Some of which will show a color 
icon with the right fonts
[image: Snag_2a82c66a.png]
My thought is what if the glyphs available are from a set that an 
(optional) web font presents in an enhanced color form. Something one could 
toggle on/off? between plain and coloured.
In edit these would be bright and easy to see, but after wikification and 
when acting as customise symbols they are invisible. Of course unless you 
have misused them, like not used inline and not as the first non blank 
character, then they will be displayed and clear in the output. Thewy will 
also be visible as clear mark-up in the editor, again with the use of 
correct fonts.

Perhaps using such a range the customise feature can detect the range of 
characters, rather than only specified ones, at least for the leading line 
base glyphs. Ie a programmatic way for a larger number of glyphs to be made 
available.

Regards
Tones



On Wednesday, 25 November 2020 at 20:48:15 UTC+11 @TiddlyTweeter wrote:

> *"Braille" Has Advantage It is SINGLE Characters With Wide Font Support *
>
> PMario
> ⠒ braille⠶ ... 
> I did play around with "braille" a little bit and for me it is _not_ 
> visible enough in plain text. ... So I'm inclined to remove it for the 
> initial (beta) release. ...
>
> The INLINE "⠒ braille⠶ " pair retains merit (let us find a similar 
> alternative that is more "visible").
>
> WHY?
> Because for inline it is far better to have single characters than 
> doubled. "X text Y" is much better than "XY text YX" for readability and 
> typing.
>
> For these reasons I hope you will keep it for now!
>
> Best wishes
> TT
> On Monday, 23 November 2020 at 14:27:12 UTC+1 PMario wrote:
>
>> Sorry for the late reply. ... I Wasn't aware, that I can only see, if 
>> something is going on, if I change the group :/
>>
>> On Wednesday, November 18, 2020 at 11:48:23 PM UTC+1 TonyM wrote:
>> ...
>>
>>> So perhaps we now need to ask
>>>
>>>- How do we go about a degree of rationalisation
>>>- code pages English + Extended Symbols and utilities eg 
>>>mathematical alphanumeric's
>>>- font recommendations
>>>- Multi-Platform support
>>>
>>> TT What do you perceive should be included?. 
>>>
>>
>> Hi folks, 
>> Interesting discussion. I did implement the different glyphs, for 
>> experimentation, so we can see how it works out. My conclusion atm is: That 
>> it creates way more problems, as it solves. .. Really! I don't want to 
>> explain, that users need a special font. .. It has to work out of the box. 
>>
>> At the moment we have:
>>
>>- There are 4 "inline" elements
>>   - __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
>>- There are 6 "block" elements
>>   - pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
>>
>> I did play around with "braille" a little bit and for me it is _not_ 
>> visible enough in plain text. ... So I'm inclined to remove it for the 
>> initial (beta) release. ... 
>>
>> I do like "underscore" because it's easy to see in plain text, but it 
>> needs more internal code :/.
>>
>> "little" causes unicode problems. ... I'd like to remove it.
>>
>> So I may end up with "underscore" and "slash". They don't cause unicode 
>> problems and are present on every keyboard. 
>>
>> ---
>>
>> I'm inclined to stick with the block elements for the initial release. 
>>
>> 
>>
>> My main point is, that I don't what to deal with the unicode support 
>> problems. The advanced usecase of the plugin is difficult enough to 
>> explain. 
>>
>> just some thoughts. 
>> -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/807519d1-3197-4a20-9aae-48f32aa73125n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I understand your concern in relationship to Unicode. But given TiddlyWiki 
has the content type;


And most systems have fonts for symbols, beyond the old ASCII sets I am 
sure we can find safe Unicode characters. TT may be the best to provide 
guidance here.

   - The dream would be keyboard enterable "glyphs" or mark-up. Way back 
   when this started I actually expected custom mark-up to be only triggered 
   by a leading period "." (first non blank character is "."), in effect an 
   escape character approach.
  - Of course now we have gone a long way past that and uncovered many 
  more possibilities.
   - A Unicode character is less likely to be found in imported text in the 
   exact way we use it as an "escape" character. 
   - As long as we can turn off and alter the escape character used, we can 
   adapt if the text contains our escape character
  - And since we need to rule in customised wiki text we are somewhat 
  safe here.
   
I am happy with the block approach first, it is already very powerful. Thus 
you could use the same principal, only if the escape character or glyph is 
the first non-space character (perhaps permit tabs etc..)

A quick look for "safe Unicode characters" gave me 
this https://qntm.org/safe 
I don't pretend to understand it fully but perhaps TT does.

Regards
Tony

On Tuesday, 24 November 2020 at 00:27:12 UTC+11 PMario wrote:

> Sorry for the late reply. ... I Wasn't aware, that I can only see, if 
> something is going on, if I change the group :/
>
> On Wednesday, November 18, 2020 at 11:48:23 PM UTC+1 TonyM wrote:
> ...
>
>> So perhaps we now need to ask
>>
>>- How do we go about a degree of rationalisation
>>- code pages English + Extended Symbols and utilities eg mathematical 
>>alphanumeric's
>>- font recommendations
>>- Multi-Platform support
>>
>> TT What do you perceive should be included?. 
>>
>
> Hi folks, 
> Interesting discussion. I did implement the different glyphs, for 
> experimentation, so we can see how it works out. My conclusion atm is: That 
> it creates way more problems, as it solves. .. Really! I don't want to 
> explain, that users need a special font. .. It has to work out of the box. 
>
> At the moment we have:
>
>- There are 4 "inline" elements
>   - __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
>- There are 6 "block" elements
>   - pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
>
> I did play around with "braille" a little bit and for me it is _not_ 
> visible enough in plain text. ... So I'm inclined to remove it for the 
> initial (beta) release. ... 
>
> I do like "underscore" because it's easy to see in plain text, but it 
> needs more internal code :/.
>
> "little" causes unicode problems. ... I'd like to remove it.
>
> So I may end up with "underscore" and "slash". They don't cause unicode 
> problems and are present on every keyboard. 
>
> ---
>
> I'm inclined to stick with the block elements for the initial release. 
>
> 
>
> My main point is, that I don't what to deal with the unicode support 
> problems. The advanced usecase of the plugin is difficult enough to 
> explain. 
>
> just some thoughts. 
> -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/732c3bf5-0d9d-4309-882f-a28dcc81bcb7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

I was thinking on this matter of unicode support, which could have 
consequences both for and in the use of custom wikitext. In many ways 
tiddlywiki "supports" Unicode, however for example no Unicode is usable in 
fieldnames, yet it is in titles, text and field values etc... However there 
is no reason we should not have a plugin and or a configuration option that 
supports Unicode. Not withstanding the need for local fonts, for example, 
windows covers most Unicode. 

Now Unicode is a broad set and the large range of languages supported do 
not necessarily need to be part of a standard distribution, somehow we need 
to be both selective and try to be exhaustive or at least provide guidance. 
If I were a speaker of another language I may already be using fonts in my 
language and keyboards that support it. 

To Support Unicode it would be good if we had the tools to;

   - Detect if extended Unicode is in use in content during import
   - Determine if Unicode is present in a given wiki (higher Unicode 
   character search?)
   - Provide information on what people will see when there is a missing 
   font and how to remedy it
   - Perhaps a plugin that once active provides a subset of Unicode 
   support, and if not so does not. basically designers or users will need to 
   opt in to the more extensive Unicode, and on visiting a tiddlywiki we can 
   see if the author has chosen to support extended Unicode.

In may ways these activities are future issues being given strategic 
consideration today, along with the conscious decision to use "special 
characters" in the customise text solution.

Why do I care?

   - As a designer or author access to extended character sets offers 
   substantial potential.
   - TiddlyWiki is a master in knowledge and information storage and will 
   benefit from robust support.
   - As Unicode use grows TiddlyWiki can be a leader in its use.
   - There are some nice innovations and self documentation features that 
   can come from extended characters, in effect namespaces and more.

So perhaps we now need to ask

   - How do we go about a degree of rationalisation
   - code pages English + Extended Symbols and utilities eg mathematical 
   alphanumeric's
   - font recommendations
   - Multi-Platform support
   
TT What do you perceive should be included?. 

Regards
TonyM
On Wednesday, 18 November 2020 at 22:18:33 UTC+11 @TiddlyTweeter wrote:

> Ciao Tony & PMario
>
> TonyM wrote:
>>
>>
>> I had not tested Android, although a big user. 
>>
>
> I think Android matters. Though personally I never use it for heavy edit, 
> its clear that lots of people do.
>
> It DOES raise an interesting issue of relevance to PMario too.
>
> I think it got clear through the 4 threads in this discussion that 
> UNIVERSAL support for ...
>
> -- Default Keyboards is likely IMPOSSIBLE
>
> -- Direct insertion via Keyboard ShortsCuts, and The Stamp Tool, is NOT 
> TOO DIFFICULT
>
> -- Unicode FONT SUPPORT requires research into CROSS-PLATFORM conditions.
>
>
> For the DEFAULT plugin markup IDs it is BEST to have UNIVERSAL FONT 
> SUPPORT.  
> Otherwise we will create a huge "support problem".
>
> Therefore: in examining Candidate Glyphs the single most important issue 
> is good FONT support.
>
> I'm stating the obvious. But answering it is not trivial.
>
> Best wishes
> TT 
>

-- 
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/37c3b1b4-f15b-46d3-bc82-e5a642964aben%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

I do understand your warnings on this, but I also know with the selection 
of an appropriate font, even pointing to one in a raw tiddler this should 
not be an issue, it is determining one freely available that can ensure the 
lions share of Unicode is available, this is what we must do. Ideally we 
find a font available and eventually ensure the empty version has it named.

I had not tested Android, although a big user.  Thanks for the feedback, 
not lets find the solution? I read how Microsoft has a few Unicode aware 
"default fonts".

Tony

On Saturday, 14 November 2020 at 20:55:18 UTC+11 @TiddlyTweeter wrote:

> Tony & PMario
>
> This illustrates issues in Font Support I mentoned earlier & in the main 
> group.
>
> In choosing Unicode solutions we do need to ensure they have font support 
> across OS.
>
> On Windows 10 I see (correct) ...
>
> [image: Screenshot 2020-11-14 103852.jpg]
> ... On my Android 8 the lead Unicode characters don't have font support  
> ...
>
> [image: Screenshot 2020-11-14 105020.jpg]
>
> This is why I refer to the "black art of Unicode". For reliable working 
> there needs to be quite a lot of checking.
>
> Best wishes
> TT
>
>
> On Wednesday, 11 November 2020 23:38:34 UTC+1, TonyM wrote:
>>
>> Further to this generic element solution;
>>
>> Eg;
>> ⮰td terminates end of line
>> ⭭tr terminates with /tr
>>
>> Only valid at the beginning of line it should be rare that a clash would 
>> occur.
>>
>> Tony
>>
>> On Thursday, 12 November 2020 09:18:24 UTC+11, TonyM wrote:
>>>
>>> Mario,
>>>
>>> I think I raised this previously, that perhaps one glyph should resort 
>>> to the element being equal to the symbol.
>>>
>>> Why?
>>>
>>> Because a large set of possibilities are opened up even without using 
>>> the customise pragma just some defaults.
>>>
>>> Eg;
>>> 'tr 
>>> would expect /tr and wrap the content in 
>>> 
>>> Without any further customisation.
>>>
>>> ie; the symbol is automatically adopted as the _element 
>>> Sure this can be customised however there are many cases where this, and 
>>> perhaps a .classname is more than enough
>>>
>>> Of course another glyph that does the same automatically terminates on 
>>> /n would also help eg;
>>> 'tr
>>> °td contents of table detail
>>> /tr
>>>
>>> °li contents of list item
>>> °li.bold bold contents of list item
>>>
>>> This is another way to help html/css savy users to make use of this 
>>> solution right out of the box with no customising.
>>>
>>> I could look from some appropriate glyphs rather than the above ' and °
>>>
>>> Regards
>>> Tones
>>>
>>>
>>> On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:
>>>>
>>>> Mario,
>>>>
>>>> That's why I favour customised 'tr and /tr  but then you have to be 
>>>> familiar with html tables. 
>>>>
>>>> Regards
>>>> Tony
>>>>
>>>> On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I did a bit more docs for table formatting. So there are the same 
>>>>> formatting options as available with standard wikitext. 
>>>>> The only problem is, to find good "start" and "end" symbols, to make 
>>>>> the wikitext readable. 
>>>>>
>>>>> -m
>>>>>
>>>>

-- 
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/e6fb5b16-4d8b-4f64-a469-b95131d591a4n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Further to this generic element solution;

Eg;
⮰td terminates end of line
⭭tr terminates with /tr

Only valid at the beginning of line it should be rare that a clash would 
occur.

Tony

On Thursday, 12 November 2020 09:18:24 UTC+11, TonyM wrote:
>
> Mario,
>
> I think I raised this previously, that perhaps one glyph should resort to 
> the element being equal to the symbol.
>
> Why?
>
> Because a large set of possibilities are opened up even without using the 
> customise pragma just some defaults.
>
> Eg;
> 'tr 
> would expect /tr and wrap the content in 
> 
> Without any further customisation.
>
> ie; the symbol is automatically adopted as the _element 
> Sure this can be customised however there are many cases where this, and 
> perhaps a .classname is more than enough
>
> Of course another glyph that does the same automatically terminates on /n 
> would also help eg;
> 'tr
> °td contents of table detail
> /tr
>
> °li contents of list item
> °li.bold bold contents of list item
>
> This is another way to help html/css savy users to make use of this 
> solution right out of the box with no customising.
>
> I could look from some appropriate glyphs rather than the above ' and °
>
> Regards
> Tones
>
>
> On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:
>>
>> Mario,
>>
>> That's why I favour customised 'tr and /tr  but then you have to be 
>> familiar with html tables. 
>>
>> Regards
>> Tony
>>
>> On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>>>
>>> Hi,
>>>
>>> I did a bit more docs for table formatting. So there are the same 
>>> formatting options as available with standard wikitext. 
>>> The only problem is, to find good "start" and "end" symbols, to make the 
>>> wikitext readable. 
>>>
>>> -m
>>>
>>

-- 
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/e3bb4243-c232-4be8-8fea-cf69624fc816o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I think I raised this previously, that perhaps one glyph should resort to 
the element being equal to the symbol.

Why?

Because a large set of possibilities are opened up even without using the 
customise pragma just some defaults.

Eg;
'tr 
would expect /tr and wrap the content in 

Without any further customisation.

ie; the symbol is automatically adopted as the _element 
Sure this can be customised however there are many cases where this, and 
perhaps a .classname is more than enough

Of course another glyph that does the same automatically terminates on /n 
would also help eg;
'tr
°td contents of table detail
/tr

°li contents of list item
°li.bold bold contents of list item

This is another way to help html/css savy users to make use of this 
solution right out of the box with no customising.

I could look from some appropriate glyphs rather than the above ' and °

Regards
Tones


On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:
>
> Mario,
>
> That's why I favour customised 'tr and /tr  but then you have to be 
> familiar with html tables. 
>
> Regards
> Tony
>
> On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>>
>> Hi,
>>
>> I did a bit more docs for table formatting. So there are the same 
>> formatting options as available with standard wikitext. 
>> The only problem is, to find good "start" and "end" symbols, to make the 
>> wikitext readable. 
>>
>> -m
>>
>

-- 
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/4e820d69-5200-4e8b-9a93-0503c2a0390co%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

That's why I favour customised 'tr and /tr  but then you have to be 
familiar with html tables. 

Regards
Tony

On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>
> Hi,
>
> I did a bit more docs for table formatting. So there are the same 
> formatting options as available with standard wikitext. 
> The only problem is, to find good "start" and "end" symbols, to make the 
> wikitext readable. 
>
> -m
>

-- 
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/defb6d49-906e-4531-8ab1-526cad90655do%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Replacing the old nested sliders plugin from TWC

In this Discussion 
<https://groups.google.com/forum/?oldui=1#!topic/tiddlywiki/VJKh0H8N7eo> a 
request mat be satisfied with custom wikitext.

Remember 
+++
content
+++
content2
===

===

Tony

On Tuesday, 3 November 2020 16:26:18 UTC+11, TonyM wrote:
>
> Gentlemen,
>
> I just discovered on Windows 10, Win+; opens a character dialogue in which 
> I can find »° and others.
>
> This means there is a simple though not too quick way to access many of 
> the glyphs we use.
>
> However I have being building tools in tiddlywiki for access to other 
> Unicode character sets. 
>
> Regards
> Tony
>
>

-- 
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/30414209-637b-431f-8714-2fd3b34bff70o%40googlegroups.com.

[twdev] Re: Writing Forms (not HTML forms, ways of writing)

[TonyM]

Corey

Perhaps such a library of tools could be helpful, but a lot can already be 
done by building a tiddler in which what you see is what you get, open it 
in a new window and print to pdf. Especially if you include page breaks in 
the display. I like foxit reader as even the free version provides 
extensive mark-up on pdfs. Sometimes it is better to make use of a 
specialist solution in conjunction with tiddlywiki?.

Regards
Tony

On Tuesday, 3 November 2020 18:19:54 UTC+11, Corey Woodworth wrote:
>
> I wonder if there'd be a demand for a pdf.js 
>  powered plugin to turn completed 
> tiddlywikis into PDFs
>
> On Saturday, September 26, 2020 at 3:24:15 PM UTC-4 PMario wrote:
>
>> Hi,
>>
>> That's a very interesting topic. Printing books has been developed and 
>> improved since about 500 years. .. HTML and the internet was able to 
>> "destroy" it in 20 years. .. In the last may be 10 years the standardizing 
>> groups try to implement elements from "printed media" into "web media"
>>
>> We got new HTML/CSS elements like flexbox, grid, masking and others, that 
>> allow us to improve and control the layout of a web page. ... BUT we are 
>> still miles away from printing a good looking page, directly from the 
>> browser. 
>>
>> We need to convert HTML to TeX with 3rd party tools, to be able to get a 
>> good looking printed page, that we can read with joy as a PDF. .. No trees 
>> need to die ;)
>>
>> -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/7e1701ec-589f-45d0-a84f-881727b8108eo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Gentlemen,

I just discovered on Windows 10, Win+; opens a character dialogue in which 
I can find »° and others.

This means there is a simple though not too quick way to access many of the 
glyphs we use.

However I have being building tools in tiddlywiki for access to other 
Unicode character sets. 

Regards
Tony

-- 
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/b6cc751f-b061-489a-9fb9-5b6ad0e32560o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Idea,

It would be quite simple to find all uses of glyphname=symbolname 
throughout a wiki to provide a Editor toolbar drop down list of existing 
glyph/symbol definitions and on click insert them at the current location 
 so the custom definitions are easier to lookup and 
select. Self documenting if the symbols are chosen well.

Tony

On Sunday, 1 November 2020 11:44:36 UTC+11, TonyM wrote:
>
> TT,
>
> I did read your history, it's Quite interesting. And to some extent I 
> defer to you, but in my return quote I pointed out the "modern" use of 
> Pilcrow.
>
> It is interesting to know where the indented 1st line of a paragraph comes 
> from, something I have never liked the aesthetics of, to be honest. You may 
> be interested in this 
> https://unicode.org/L2/L2016/16235-two-medieval-chars.pdf
>
> What I do hope is in the end we can accommodate different mark-up needs, 
> and in fact that is the value of this project. That is one reason I 
> speculated if it were possible to have an end of line only mark-up symbol, 
> not only because that is the way I would be inclined to use pilcrows, but 
> to support other end of line annotations. I believe this may already be 
> achieved with inline mark-up placed at the end of line. One persons end of 
> line is another's beginning of line anyway, for example I can imagine ﹙¶﹚.
>
> I could see someone with the interest providing both the plugin and custom 
> for anyone of these different systems. Not unlike they way a mathematician 
> may extend tiddlywiki to their own mark-up language to represent complex 
> maths, perhaps people may do this for old English, newspapers, PageMaker 
> (One of the first professional printing applications and the use of 
> postscript 
> <https://www.hackworth.co/what-is-postscript-and-why-do-almost-all-high-end-printers-support-it/>).
>  
> The key being people can make tiddlywiki their own, in new ways, through 
> the value of mark-up. Or as an example people preparing medieval style 
> texts or writing about them.
>
> One example I am aware of is using custom mark-up to write HTML via 
> shortcuts. Combined with tiddlywiki's automation I have always seen the 
> potential for tiddlywiki to be configured to be a site designer and 
> generator as well, this is where using html elements are helpful. One thing 
> that excites me a lot is using an "arbitrary html tag" inside a custom 
> mark-up. Basically it allows the writer to contain custom css and other 
> "semantically appropriate" sections in the document. Add to this 
> transclusion and macros an one could potentially generate a website by 
> filling in some content settings and export (via zip) a whole multi-page 
> site. Could this be a SquareSpace Wix killer? I have experimented with 
> connecting to html and external javascript and there is a lot of potential 
> there for more host interaction, I just do not have the skills yet.
>
> Yet another thought of late, is in response to filters, logical operators 
> and the fact that filters handle sets. It seems to me the introduction of 
> annotation for basic set manipulations would also be helpful. See in the 
> pre-release https://tiddlywiki.com/prerelease/#Filter%20Expression Equivalent 
> named prefix
>
> Regards
> Tony
>
>
> On Sunday, 1 November 2020 03:57:52 UTC+11, @TiddlyTweeter wrote:
>>
>> TonyM wrote:
>>>
>>> ¶
>>> I would not bother with the use of pilcrow unless it was part of an end 
>>> of line form of glyph only. 
>>>
>>
>> Pilcrow has a complex history before printing, in printing & on the net. 
>> They all diverge & overlap.
>>
>> Essentially the paragraph "mark" is a signal for a "longer pause" in 
>> thought in all incarnations.
>>
>> I mention a bit of its history in some comments to PMario above.
>>
>> Best wishes
>> TT
>>
>>   
>>
>

-- 
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/90c6224a-82c8-491b-9254-34c6d83b7874o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

I did read your history, it's Quite interesting. And to some extent I defer 
to you, but in my return quote I pointed out the "modern" use of Pilcrow.

It is interesting to know where the indented 1st line of a paragraph comes 
from, something I have never liked the aesthetics of, to be honest. You may 
be interested in 
this https://unicode.org/L2/L2016/16235-two-medieval-chars.pdf

What I do hope is in the end we can accommodate different mark-up needs, 
and in fact that is the value of this project. That is one reason I 
speculated if it were possible to have an end of line only mark-up symbol, 
not only because that is the way I would be inclined to use pilcrows, but 
to support other end of line annotations. I believe this may already be 
achieved with inline mark-up placed at the end of line. One persons end of 
line is another's beginning of line anyway, for example I can imagine ﹙¶﹚.

I could see someone with the interest providing both the plugin and custom 
for anyone of these different systems. Not unlike they way a mathematician 
may extend tiddlywiki to their own mark-up language to represent complex 
maths, perhaps people may do this for old English, newspapers, PageMaker 
(One of the first professional printing applications and the use of 
postscript 
<https://www.hackworth.co/what-is-postscript-and-why-do-almost-all-high-end-printers-support-it/>).
 
The key being people can make tiddlywiki their own, in new ways, through 
the value of mark-up. Or as an example people preparing medieval style 
texts or writing about them.

One example I am aware of is using custom mark-up to write HTML via 
shortcuts. Combined with tiddlywiki's automation I have always seen the 
potential for tiddlywiki to be configured to be a site designer and 
generator as well, this is where using html elements are helpful. One thing 
that excites me a lot is using an "arbitrary html tag" inside a custom 
mark-up. Basically it allows the writer to contain custom css and other 
"semantically appropriate" sections in the document. Add to this 
transclusion and macros an one could potentially generate a website by 
filling in some content settings and export (via zip) a whole multi-page 
site. Could this be a SquareSpace Wix killer? I have experimented with 
connecting to html and external javascript and there is a lot of potential 
there for more host interaction, I just do not have the skills yet.

Yet another thought of late, is in response to filters, logical operators 
and the fact that filters handle sets. It seems to me the introduction of 
annotation for basic set manipulations would also be helpful. See in the 
pre-release https://tiddlywiki.com/prerelease/#Filter%20Expression Equivalent 
named prefix

Regards
Tony


On Sunday, 1 November 2020 03:57:52 UTC+11, @TiddlyTweeter wrote:
>
> TonyM wrote:
>>
>> ¶
>> I would not bother with the use of pilcrow unless it was part of an end 
>> of line form of glyph only. 
>>
>
> Pilcrow has a complex history before printing, in printing & on the net. 
> They all diverge & overlap.
>
> Essentially the paragraph "mark" is a signal for a "longer pause" in 
> thought in all incarnations.
>
> I mention a bit of its history in some comments to PMario above.
>
> Best wishes
> TT
>
>   
>

-- 
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/2ae2294e-32f3-4543-940e-1da8c3579d3ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Do note I found these alternate small braces that may be better.
﹙₍ ₎﹚

Regards
Tony

On Saturday, 31 October 2020 12:01:43 UTC+11, TonyM wrote:
>
> Mario,
>
> I would be keen to see these additional inline glyphs made available. They 
> look like a fusion of [ ] and ( )
>
> It would be ideal for mark-up that involves links or buttons and where the 
> content is considered a title.
>
> *A line with〖 This inline 〗and more
>
>
>- They also look good when no customisation plugin is in use but does 
>communicate, if it were, this would be treated differently. 
>- I would for example use it like [[ ]] but to trigger a button to 
>create the tiddler from a template
>- Or 〖task This inline 〗to create from the task template
>- Its the more visible version TT is asking for.
>
> However I do want you to retain ﹙ little﹚ for the same reason TT does not 
> want them, they are similar but different to ( ) and less visible. 
>
>- TT can just "*not use them"* if he does not like them (I say with 
>all due respect).
>
>
> Tony
>

-- 
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/fd88d292-d4a4-43ef-a974-34a8a1dc24e6o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I would be keen to see these additional inline glyphs made available. They 
look like a fusion of [ ] and ( )

It would be ideal for mark-up that involves links or buttons and where the 
content is considered a title.

*A line with〖 This inline 〗and more


   - They also look good when no customisation plugin is in use but does 
   communicate, if it were, this would be treated differently. 
   - I would for example use it like [[ ]] but to trigger a button to 
   create the tiddler from a template
   - Or 〖task This inline 〗to create from the task template
   - Its the more visible version TT is asking for.

However I do want you to retain ﹙ little﹚ for the same reason TT does not 
want them, they are similar but different to ( ) and less visible. 

   - TT can just "*not use them"* if he does not like them (I say with all 
   due respect).


Tony

-- 
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/7ae0fa0e-b0c5-43ab-a2db-3504c994155fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Question,

If other glyphs and characters could be selected could we actually redefine 
existing mark-up with customise?
\customise glyph="*" parameters

*This would then take on the new definition here?

I raise this because this us what the current double underscore is 
effectively doing.

An example I may use if this was possible is to add underline or bold to 
H1/H2

This would allow redefinition of mark-up already in a text perhaps even 
making it behave like another mark-up language.
and additions like
\customise glyph="-" _element="li"

- to accept bullets pasted from GitHub


Tones

-- 
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/0a8dce1e-9e25-40b2-b8bf-e7170b501f56o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Just for clarification the double underscore (not underscore) is used, does 
this not clash with its existing use?, or is this intentional?

It is available on most keyboards.

Regards
Tony


On Saturday, 31 October 2020 00:55:25 UTC+11, PMario wrote:
>
> Hi folks,
>
> I'd like to discuss with you the table syntax as shown in
>
> \customize tick=table _element=table _endString="/endTable" _mode=block
> \customize tick=caption _element=caption
>
> \customize tick=! _element=th 
>
> \customize tick=cell _element=td _classes=".hl"
> \customize tick _use=cell
>
> \customize angle="===row" _element=tr _mode=block _endString="---"
> \customize angle=cmulti _element=td _classes=".hl" _mode=block 
> \customize angle=| _use=cmulti
>
> ´table ´caption Some caption text
> »===row
> ´! header 1
> ´! header 2
> ´! header 3
> ---
> »===row
> »| 1 text 
>
> »| 12 text «  and  » 
>
> »|
> * cell 13 text
> * line 2 
> * line 3 
> ---
> »===row
> »| 2 text 
>
> »| 22 text 
>
> »| 23 text 
>
> ---
> /endTable
>
> and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table
>
> Do you think it could be used as a default, shipped with the plugin. .. 
> The CSS for multiline and eg: bullet lists will need some adjustment .. 
>
> tick-cells are use for single line cells terminated by \n
> angle-cells are used for multi, block like cells terminated by \n\n
>
> »===row
>ends with 
> ---
>
> -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/ad5cc2f9-5494-4ba9-af57-3ced3be597dco%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I think it would be useful to include such "compound customisations" with 
the plugin or at lest on the plugins website. Although perhaps it could be 
an optional item that requires tagging.

Having used html tables within wikitext for so long, I find it easier to 
follow a html table format, and simple closures, as follows;

\customize tick=table _element=table _endString="/table" _mode=block
\customize tick=caption _element=caption

\customize tick=th _element=th

\customize tick=td _element=td _classes=".hl"  _mode=block

\customize tick="tr" _element=tr _mode=block _endString="/tr"

´table ´caption Some caption text
´tr
´th header 1
´th header 2
´th header 3
/tr


´tr
´td 1 text
´td 12 text «  and  »
´td
* cell 13 text
* line 2
* line 3
/tr


´tr
´td 2 text
´td 22 text
´td 23 text
/tr
/table

However if we are considering distributing or documenting "compound 
customisations" I would be tempted to extend my table to to include a lot 
more such and head/foot/body, a list widget for both rows and columns, as I 
would do this for myself anyway.

Perhaps your table responding to classic tiddlywiki tables AND one 
responding to html tables included would make sense?

Tony



On Saturday, 31 October 2020 00:55:25 UTC+11, PMario wrote:
>
> Hi folks,
>
> I'd like to discuss with you the table syntax as shown in
>
> \customize tick=table _element=table _endString="/endTable" _mode=block
> \customize tick=caption _element=caption
>
> \customize tick=! _element=th 
>
> \customize tick=cell _element=td _classes=".hl"
> \customize tick _use=cell
>
> \customize angle="===row" _element=tr _mode=block _endString="---"
> \customize angle=cmulti _element=td _classes=".hl" _mode=block 
> \customize angle=| _use=cmulti
>
> ´table ´caption Some caption text
> »===row
> ´! header 1
> ´! header 2
> ´! header 3
> ---
> »===row
> »| 1 text 
>
> »| 12 text «  and  » 
>
> »|
> * cell 13 text
> * line 2 
> * line 3 
> ---
> »===row
> »| 2 text 
>
> »| 22 text 
>
> »| 23 text 
>
> ---
> /endTable
>
> and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table
>
> Do you think it could be used as a default, shipped with the plugin. .. 
> The CSS for multiline and eg: bullet lists will need some adjustment .. 
>
> tick-cells are use for single line cells terminated by \n
> angle-cells are used for multi, block like cells terminated by \n\n
>
> »===row
>ends with 
> ---
>
> -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/53fb6198-c3bd-41f0-b02e-e1ddbe403d95o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Go how you want, but my understanding comes from the more "modern use" 
noted later in the Wikipedia entry, truthfully a leading one may confuse me 
ans many others given this;

*The pilcrow is used in desktop publishing software 
> <https://en.wikipedia.org/wiki/Desktop_publishing_software> such as 
> desktop word processors 
> <https://en.wikipedia.org/wiki/Word_processor> and page layout 
> <https://en.wikipedia.org/wiki/Page_layout> programs to mark the presence 
> of a carriage return 
> <https://en.wikipedia.org/wiki/Carriage_return> control character 
> <https://en.wikipedia.org/wiki/Control_character> at the end of a 
> paragraph. It is also used as the icon 
> <https://en.wikipedia.org/wiki/Icon_(computing)> on a toolbar 
> <https://en.wikipedia.org/wiki/Toolbar> button that shows or hides the 
> pilcrow and similar hidden characters, including tabs 
> <https://en.wikipedia.org/wiki/Tab_key>, whitespace 
> <https://en.wikipedia.org/wiki/Whitespace_(computer_science)>, and page 
> breaks <https://en.wikipedia.org/wiki/Page_break>. In typing 
> <https://en.wikipedia.org/wiki/Typing> programs, it marks a return that one 
> must type.*


I have being keen to make a preview that acts as the aforementioned toolbar 
button would.

You are right to *"produce html output that is well formed", *I will return 
to reviewing the html my tests generate. I not you have many of my prior 
examples in test tiddlers, thanks its a helpful reference. 

Tony

On Friday, 30 October 2020 15:44:29 UTC+11, PMario wrote:
>
> On Friday, October 30, 2020 at 1:09:16 AM UTC+1, TonyM wrote:
>
> Only one issue you may have overlooked, or I missed your answer. Rather 
>> than use pilcrow at the beginning of a line I would only use it at the end, 
>> if you don't see an "end of line only pragma" being possible as 
>> discussed in this reply 
>> <https://groups.google.com/d/msg/tiddlywikidev/vS5ZI0FCiIY/-3iPdVlJAAAJ> 
>> then 
>> I would suggest the reverse pilcrow, as it indicates beginning of paragraph.
>>
>
> Have a look at this: https://en.wikipedia.org/wiki/Pilcrow
>
> Pilcwrow is used at the beginning of a new paragraph and by default stops 
> with \n\n in the customize implementation. ... Similar to TTs suggestion. 
> ... 
>
> I did try to implement pilcrow / reverse pilcrow as inline markers too. .. 
> BUT it produces really strange and invalid HTML code. Ps inside SPANs 
> inside Ps if stuff was nested. .. So I did move it to "block" like syntax, 
> where it produces some predictable html output. 
>
> One of my goals still is, to produce html output that is well formed. ... 
> There is a pending PR and some discussion at GitHub, that try to fix the 
> problems with too many Ps in TW wikitext output. Especially in the UI 
> sections, where it causes theming problems. 
>
> -m
>

-- 
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/47d77f8a-6a93-4fdb-8fb1-cd560fcaa1f8o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

What you have done is fantastic. I will focus on V 0.8.0 - 2020-10-29 From 
a testing and features arising point of view. 

I am Happy to stabilise with the current solution as a first release if you 
want.

My only urgency to raise the custom Glyphs is that your are aware of it as 
a possibility and desirable. However you have done more than enough to 
accommodate I, your own and TT's questions and imagination. Its a pleasure 
working with you.

Only one issue you may have overlooked, or I missed your answer. Rather 
than use pilcrow at the beginning of a line I would only use it at the end, 
if you don't see an "end of line only pragma" being possible as discussed 
in this reply 
 then 
I would suggest the reverse pilcrow, as it indicates beginning of paragraph.

Love your work as usual, and yes the combinatorial complexity is massive. 

We do need to draw *the line* somewhere. All we need to do is ensure *the 
line *does *not compromise the future* and I think you have that in control.

Regards
Tony

 


On Friday, 30 October 2020 05:49:26 UTC+11, PMario wrote:
>
> Hi Folks,
>
> There has been so much feedback lately, that I'm still a bit overwhelmed. 
> .. I need to read and re-read the infos several times. 
>
> At the moment we have maximum flexibility, except 
> user-glyph-configuration. ... But let us test, what we have atm. ... 
>
> I'll need to create a lot more automatic tests, to avoid regressions in 
> the future. Since "inline"-like configuration can do the same things as 
> "block"-like customs I think we have a lot to test ;)
>
> It may be even possible to reduce the number of used glyphs. ... BUT I 
> think there is enough variety to satisfy the users preferences. Especially 
> as every glyph can have unlimited "symbols"
>
> -m
>

-- 
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/cf49e815-2b82-4eab-a933-30c14274066bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Sorry about the overwhelming. I will try and simplify


>> *The attached local view template demonstrates the use of additional code 
>> in a specific tiddler. *
>>
>>- *In this case of you add the field local-viewtemplate to any 
>>tiddler in the edit view and a new editable field appears. This will be 
>>applied through the view template.*
>>- *Please try it, it is immensely useful for research and 
>>experimentation on view Template code.*
>>
>>
> *Hi Tony, *
>
> *I got it working, but I think I'm the wrong person here. The problem I 
> have with that approach is: I don't understand it. *
>
> *I can't see the usecase, because my philosophy is completely different in 
> this regard.*
>

*The use case is an instant view template*, that impacts on the current 
tiddler for ViewTemplate development and testing. Once tested you would 
move the code to a global viewTemplate and delete the local one, unless 
perhaps you had a bespoke view template for one tiddler.

The reason I suggest it, is we *could have a bespoke \customise wikitext 
pragma field*, for the same development purpose, for later globalisation if 
desired.

I can build it already I believe, If I can do it with a reference somehow 
to !!custom-pragma

\importcustom [[pragma-details]]


Regards
Tony 


> 
>
> For me only 1 multiline field exists: The text field. The tiddler is the 
> smallest element in TW. 
>
> If I need "combined multiline content" I think there should be different 
> stories. IMO the Streams concept 
>  is the way to go. In TW 
> 5.1.23 there will be some (invisible) elements, that will make working with 
> "combined tiddlers" and multiple stories easier. 
>
> As soon as I need a multiline field I think it is much easier to go the 
> multi-tiddler / multi-story way as shown in the video from 9:30 to 10:30 
>   
> TW 5.1.23 will contain some elements, that will make this approach easier. 
> ... BUT there is still more work to do. There are some open PRs and 
> discussions at GitHub.
>
> -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/7e24943c-249e-4736-a691-a6a8bc3f1304o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

An Idea, to avoid us returning to a solution which has no additional glyphs 
config, could be solved by providing a packaging solution, not unlike the 
bundler plugin. We can just select tiddlers with customise and bundle the 
definitions and custom definitions to ensure transferability.

Of importance here though, I am suggesting giving the vast majority of 
users, an appropriate set of pre-defined glyphs, they may never know you 
can define more. Being able to customise them, apply parameters and 
classes, use symbols etc... "is more than enough rope". But we know and we 
can innovate via this new Glyph mechaisium. If we can define a way to 
distribute a new glyph definition, perhaps in a separate file or plugin 
then a level of modularisation occurs, even allowing us to build the 
default glyphs in the same way. There is no harm if it demands a reload, we 
can force it in a glyph definition plugin, with customise wiki text as a 
dependency.

This customised wikitext solution is so powerful I think providing such an 
extencibility feature is wise, otherwise there will be too much pressure to 
update the core solution, and I do not want this to become a maintenance 
issue for you. 

As long as we can see what glyphs have being defined, it is possible to 
search for all tiddlers making use of that glyph, and advantage of using 
Unicode characters rarely found in content. If I go to export a tiddler 
with customised pragma, if I identify which defined pragma are in use in 
the current tiddler, and include their definitions, perhaps not the default 
(definitions), but also optionally the plugin as well. Then transfer 
becomes easy.

Now, I must declare knowing what customise can achieve so far, and the 
wealth of shiny Unicode characters, I am taken by the possibilities for 
writing my own content with any custom wikitext I desire. I really don't 
care if its transferable, people can read the rendered results, I can 
capture static HTML or deliver customisations in any Wiki I want. I am 
already thinking about a glyph for footnotes or extreme semantics like 

∴ This is the conclusion or therefore statement in my text
;This is another conclusion
:This will be helpful ∴ review and extend these ideas.
That my knowledge base can extract and I can globally reformat in one 
place. All by customising a meaningful glyph.

Single line mark-ups for questions, answers, therefore, to do, details, 
references, errors,  all triggered by glyph With customise 
wikitext these can be used to trigger tasks, tiddlers, workflows and more 
all from insertion of a single glyph.

By being able to choose the glyph we can customise meaningful single 
character mark ups in a highly semantic way, rather that having to remember 
a glyph/symbol pair.

This is after all offering a personal productivity solution, sufficient to 
be wiki specific, as much as, a feature for tiddlywiki for lots of wikis.

Regards
Tone=y


On Friday, 30 October 2020 03:15:20 UTC+11, PMario wrote:
>
> On Thursday, October 29, 2020 at 1:05:53 AM UTC+1, TonyM wrote:
>
> Just a thought, if the customise definition was to accept both glyph and 
>> symbol as parameters this may be an easier approach.
>> \customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight 
>> _classes=".highlight" _mode=inline
>> even an new \customise-def that accepts _glyphs and _glyphNames and 
>> \customise does not.
>>
>
> Those definitions will need to be done at startup time. 
>  
>
>> Then all the existing definitions would be transferred into this form, 
>> but could be altered.
>>
>
> That's right.
>
> Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent 
>> use such as 
>> \customise openenc _classes=".highlight-green"
>> In effect a redefinition, like the current customise.
>>
>> In the worst case there will need to be a start-up process that puts 
>> glyph definitions in a specific tiddler into a table, ie reload to add new 
>> glyphs.
>>
>
> That would need to happen. ... When \customize definitions are parsed, the 
> whole initialisation process is in the past. So there would need to be a 
> configuration tiddler, that contains the necessary definitions. 
>
> The problem is, that the user, which wants to define the config tiddler 
> would have to know exactly, how the parser works, to do the right things. 
> ... I think it will be an education / documentation problem. 
>  
>
>> Forgive me for interfering in this aspect of coding, which I am as yet 
>> unable to contribute to myself. I wish you had another "coder" (or more) 
>> sharing your effort.
>>
>
> I do have a little problem with too many different "glyphs". .. It may 
> also be a &qu

[twdev] Re: Custom markup (continued 4)

[TonyM]

Gentlemen,

The attached local view template demonstrates the use of additional code in 
a specific tiddler. 

   - In this case of you add the field local-viewtemplate to any tiddler in 
   the edit view and a new editable field appears. This will be applied 
   through the view template.
   - Please try it, it is immensely useful for research and experimentation 
   on view Template code.

I can see using this or something similar for the application of various 
customise 
definitions only on the local tiddler.

   - Keep in mind a local-customise field could contain also a transclusion 
   such as {{extended-markup}} to include a custom mark-up template, or 
\importcustom 
   [[pragma-details]]
   - I am still to make this work for customize, but Mario would know how 
   to of the top of his head.
   - Note the customised wiki would not apply if the text field were 
   transcluded elsewhere but we could have a template that does include the 
   local-template or local-customise in a Transclude (if it exists) eg 
   {{tiddlername||$:/template/render-with-custom-wikitext}} 

Regards
Tony
Regards
Tony

-- 
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/cbf1e047-0fe9-484f-b49c-a44c106066a4o%40googlegroups.com.


local-viewtemplate.json
Description: application/json

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Just a thought, if the customise definition was to accept both glyph and 
symbol as parameters this may be an easier approach.
\customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight 
_classes=".highlight" _mode=inline
even an new \customise-def that accepts _glyphs and _glyphNames and 
\customise does not.

Then all the existing definitions would be transferred into this form, but 
could be altered.
Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent 
use such as 
\customise openenc _classes=".highlight-green"
In effect a redefinition, like the current customise.

In the worst case there will need to be a start-up process that puts glyph 
definitions in a specific tiddler into a table, ie reload to add new glyphs.

Forgive me for interfering in this aspect of coding, which I am as yet 
unable to contribute to myself. I wish you had another "coder" (or more) 
sharing your effort.

I would just add to the general discussion, whilst global customise is a 
valuable tool, I can see customise being added to the specific tiddlers 
that wish to use extended mark-up, so in many cases the scope will only be 
the current tiddler. If a text contains a glyph the editor can just choose 
another for their special mark-up, a small popup panel could list the 
glyphs found in a tiddler.

Another approach is using a custom type field, and the type which is 
equivalent to a mime type also permits providing the character set.

Regards
Tony

On Thursday, 29 October 2020 01:53:12 UTC+11, PMario wrote:
>
> On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
>>
>> *Regarding User Possibility To Set Markup Glyphs?*
>>
>> TonyM wrote:
>>>
>>>
>>> *Question - customised Glyphs, a glyph too far?*
>>>
>>>- As you can see the wide range of glyphs available that have 
>>>meaning or structure makes me wish to ask if we could allow the user to 
>>>nominate glyphs either single (line/para/blocks) or pairs for inline or 
>>>block. ie customise the customise glyphs.
>>>
>>>
>>  Ciao TonyM & PMario
>>
>> IF this were possible I WOULD use it.
>>
>
> ... need to think about it. But it would make configuration a hell lot 
> more complex.
>  
>
>> Why? Because the kinds of Markup I do would benefit from me being able to 
>> choose glyphs VISUALLY SUITED to the purpose.
>> For instance, for simple paragraphs ...
>>
>> ¶ Start of a paragraph,
>> more of the same pargraph endedon the next line.
>> ⁋ <--- End String
>>
>> I understand if its not possible. 
>>
>
> It would be possible to use pilcrows as "start" and "end" of a paragraph, 
> but I don't understand why. 
>
> TW Pargraphs end with \n\n by default
>
> So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
> personally it is confusing, since Libre Office and Word use: ¶  as a 
> paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
> paragraph. ... So the reverse pilcrow feels completely wrong at that 
> position.
>
> *I could implement:*
>
> ¶ some text \n\n
>
> Since it would be the right thing to do. see: Wikipedia Pilcrow 
> <https://en.wikipedia.org/wiki/Pilcrow>. It would be easy to explain, 
> with the link to Wikipedia. It will create a HTML P tag by default.
>
> If you want you can define an _endString. ... Default would be \n\n
>
> -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/e1e3292d-d7ef-4bee-87e1-aad00b5c43e4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,Josiah

¶
I would not bother with the use of pilcrow unless it was part of an end of 
line form of glyph only. Its key use would be to place a pilcrow in a large 
slab of text to force a pagarapgh break. if other glyphs depended on \n\n, 
it would be best to resolve these first if possible. There is a implied *new 
paragraph* that follows the ¶ that is sufficient in my view (as for this 
paragraph). If one was to have a start and end the appropriate method is a 
revers-pilcrow and pilcrow pair.

End of line only mark up, with selectable glyphs, Would allow someone like 
> me to define a glyph  "¶" as "br>" so insertion of ¶ would 
> render as a new paragraph "break". This provide the complement to beginning 
> of line and inline mark-up.

 
Arguably the ¶ could be given a definition that highlights the first word 
of the next (generated paragraph).
 
Josiah, I don't mind decent, however I disagree with the lack of visibility 
with "the" parenthesis, and value how the look. First with Custom wiki text 
present they disappear in the output. Secondly we can use the slightly 
different examples given. My point here is if something is not good enough 
⸨rather 
than exclude it⸩ find if there is a way to 〖 address 〗 it, such as ⁽ Here ⁾ 
or ₍ there ₎ remember as a rule already text contains ' " ` and other 
characters even less readable. The fact that a reader may not be able to 
tell the difference may actually be an advantage when no customisation is 
occurring.

If we have two (or more) open and close braces there is an opportunity to 
define one as non-operative in text that contains one of the other pairs. 
The point being the only reason they will be in use is because the writer 
chooses to.

I am actually keen to use such Unicode braces simply to delimit a piece of 
text, I would write separate macros to extract those ﹤keywords and phrases﹥ so 
delimited, independent of the current text even without the use of 
customise. However if such pairs are available to "custom wikitext" further 
automation or formatting can be done to automate this feature.

Tony


On Thursday, 29 October 2020 01:53:12 UTC+11, PMario wrote:
>
> On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
>>
>> *Regarding User Possibility To Set Markup Glyphs?*
>>
>> TonyM wrote:
>>>
>>>
>>> *Question - customised Glyphs, a glyph too far?*
>>>
>>>- As you can see the wide range of glyphs available that have 
>>>meaning or structure makes me wish to ask if we could allow the user to 
>>>nominate glyphs either single (line/para/blocks) or pairs for inline or 
>>>block. ie customise the customise glyphs.
>>>
>>>
>>  Ciao TonyM & PMario
>>
>> IF this were possible I WOULD use it.
>>
>
> ... need to think about it. But it would make configuration a hell lot 
> more complex.
>  
>
>> Why? Because the kinds of Markup I do would benefit from me being able to 
>> choose glyphs VISUALLY SUITED to the purpose.
>> For instance, for simple paragraphs ...
>>
>> ¶ Start of a paragraph,
>> more of the same pargraph endedon the next line.
>> ⁋ <--- End String
>>
>> I understand if its not possible. 
>>
>
> It would be possible to use pilcrows as "start" and "end" of a paragraph, 
> but I don't understand why. 
>
> TW Pargraphs end with \n\n by default
>
> So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
> personally it is confusing, since Libre Office and Word use: ¶  as a 
> paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
> paragraph. ... So the reverse pilcrow feels completely wrong at that 
> position.
>
> *I could implement:*
>
> ¶ some text \n\n
>
> Since it would be the right thing to do. see: Wikipedia Pilcrow 
> <https://en.wikipedia.org/wiki/Pilcrow>. It would be easy to explain, 
> with the link to Wikipedia. It will create a HTML P tag by default.
>
> If you want you can define an _endString. ... Default would be \n\n
>
> -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/efb10bf8-eba1-4cea-8fc5-36b85f83266fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

It must be late for you - good night

Tony

On Wednesday, 28 October 2020 12:21:02 UTC+11, PMario wrote:
>
> Hi Tony,
>
> Very good questions. ... all of them. 
>
> As I do read the requests, I think we shouldn't make a difference between 
> \customize and \customize inline  But this could cause a lot more 
> consistency problems, like:
>
> ´d ´s some text<-- only works that way because I liked it. 
>
> With strict rules it would need to look like this:
>
> ´d
> ´s some text
> some text
>    <--* _endString*
>
> I'll think about the ideas .. while I'm sleeping ;)
>
> -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/297d94fe-571b-46e5-85da-c7449abc1e5co%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Minor additional note

>
> *A random Idea*
>
>- I used to use a character combination to annotate lines on personal 
>hand written notes, I have found unicode versions, they always live at the 
>end of a line
>   - ? a question (A question) Special forms of these also exist.
>   - ! an answer (asserted / definitive answer)
>   - ⁇ Question this, it is unlikely to be true 
>   - ⁈ You must question this, question - asserted 
>   - ⁉ Believe it to be true - asserted but could question
>- So I wonder like your prior work on \n if we could 
>introduce a end of line type of custom pragma. ie it has no beginning of 
>line, or inline or block characteristics (by default)
>   - In a sense inline but only end of line (\n). Used inside ⁉ means 
>   nothing.
>   - This also means it would typically not have any input (other than 
>   symbol, class or :p) unless it detected \n vs \n\n
>
> End of line only mark up, with selectable glyphs, Would allow someone like 
me to define a glyph  "¶" as "br>" so insertion of ¶ would 
render as a new paragraph "break". This provide the complement to beginning 
of line and inline mark-up.

Regards
Tony

-- 
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/79acd201-b94f-4941-bfd0-67604a721525o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

> _endString will be _not_ configurable. 
>

I agree with this but ask if if it makes sense to be auto-terminated with 
\n or \n\n  
am I wrong to think *Typically inline does end at a line or paragraph 
break?*

So if we use the glyphs I suggested ⁽ this is inline⁾ this inline ⁽.coda at 
the end will be honoured

   - "coda" is a term used as in the finishing notes in music that end the 
   piece gracefully.
   - In this case it would be an end of line sequence
   - Arguable we may use 

´something ⁽ rest of line using inline
or
⁽ just reusing the inline to the end of line (from the beginning)

   - I suggest this only because there may be a lot of cases where inline 
   is used to highlight text
   - Not demanding closure may reduce incidental errors when closure 
   omitted.
   - This same highlight may be reused in lines as well
   - No need to define another all but identical line of paragraph 
   terminated custom wikitext just to use the same formatting as an inline 
   definition.

This is a sentence ⁽.mark.yellow this text singled out⁾ but this text just 
sentence. Note no space proceeding close.

´something ⁽.mark.yellow rest of line using inline
or
⁽.mark.yellow just reusing the inline custom for a whole line.


*⁽.mark.yellow Item 1 highlighted
*⁽.mark.green Item 2 differently highlighted.

I think inline puts us on the "home run".

Tony

-- 
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/bf3525e7-98de-4732-a495-38758bf413a4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

To clarify,

The following is about the use of underscore or another glyph to handle 
"inline custom wiki text."

> I am not sure why you say new inline functions then you say no inline 
>> customise functions.
>> Do you mean inline works with underscore, you just can not customise it?
>>
>
> It is able to detect start / end and nested inline definitions. But at the 
> moment it only sets class-names. ... No possibility to call widgets. ... 
> Will follow soon.
>

That is fine, thanks for clarifying
 

>
> At the moment the plans are: 
>
> _element should be configurable. ... I think it will be limited to widgets 
> and html inline elements 
> , or 
> may be even a subset of them. 
>

Great, do we need to suggest only to use inline html elements within this? 
This is a good reference for html block vs 
inline https://www.w3schools.com/html/html_blocks.asp

   - I plan to make extensive use of the difference in future with 
   customised wikitext.

 

>
> _endString will be _not_ configurable. 
>

Makes sense if we pre-configure the closure, and define a glyph or set of 
glyphs of the "inline type"

As in my previous email perhaps some glyphs should also have a default 
block type pre-set, and a few with neither set.
 

>
> _mode has to be fixed to inline
>

Again makes sense. that is what it is. See my last post for an attempt to 
rationalise this and my objections to underscore, which I may add has 
already cause problems be cause it is hard to see the difference between _, 
__ and ___ if they are separated by any distance or in different fonts.
 

>
> I tend to remove __ and ___ ... since it will overwrite the existing 
> __underline__ wikitext definition, which isn't usable atm. 
>

Not sure what you mean here, but is it like my objection to undersore?
 

>
> .. The rest will be the same as the existing params
>

Exciting.

Tony

-- 
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/111d3131-c480-4f05-88df-fb377a2fbbf8o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

*A few observations.*
Again please don't be overwhelmed just consider these ideas please. Nor do 
these ideas imply it demands your work, although in some cases that is most 
likely.

The key issue I am grappling with is the systemisation of glyphs, symbols 
and the scope of customises wiki text. To make this easy to use and 
remember. Presently I always need to lookup the reference material and 
slowly construct wikitext, if its slow and hard for me (involved in this 
project from the start) it may appear impossible to future new users. There 
are differences in the way Mario, TT and myself envision this, until this 
is cleared up even testing will be clumsy apart from helping future users.

Observed - In a tiddlywiki without custom mark-up
This is some Text __.test Inline text ___ with more
fails gracefully

;This is some Text __.test Inline text _/ with more
Fails *un*gracefully. Disrupts future wiki text.

*Question* Example the details 
in 
https://wikilabs.github.io/editions/custom-markup/#Customize%20the%20Details%20Element

In this example I use a custom endString basically /symbol 
\customize tick="d" _element="details" _classes=
".notop.cbox.cbox-primary.hard-linebreaks" _endString="/d" _mode=block
\customize tick="s" _element="summary" _classes=".margin-init"  _endString=
"/s"

´d ´s Details - Summary
/s
line 1
line 2
/d
´d
´s Details - Summary
/s
line 1
line 2
/d
Is there any reason why we could not make this a default end string, ie the 
"/symbol" automatically. unless specified for such blocks.
Then allow the end string to be set to a logical "\n" or "\n\n" for the 
automatic closure at end of line or end of double line break/paragraph.

Also can you explain or document a little "the use of this nesting" ?
´d ´s
as I understand it ´s follows ´d and a  so it looks inline, but I 
assume it is not, 
can we say "*customise blocks can be nested by following one with another 
on the same line, but only at the beginning of the line **or at the 
beginning of subsequent lines"* 
Just to get a more general statement?

I love the demo
wow ﹙symbol.class:param some text﹚ nice
There is also a superscript and subscript form of these (Not the same as 
each other ﹙﹚₍₎⁽⁾
⁽this is some text⁾
₍this is more text₎
To me these are two use full pairs to use glyphs for inline content. 

   - Obvious but subtle
   - Open and close are single characters
   - Would just look like a textural mark up without custom wiki text 
   plugin.
   - Provides two/tree pairs for different applications

The use of the Greek delta to represent change may be useful at some point 
as a glyph.

*Question - See diacritical markers 
*

   - Could we have any clashes with these?

*Question - customised Glyphs, a glyph too far?*

   - As you can see the wide range of glyphs available that have meaning or 
   structure makes me wish to ask if we could allow the user to nominate 
   glyphs either single (line/para/blocks) or pairs for inline or block. ie 
   customise the customise glyphs.
   - This would mean we only choose a few and let the user define extended 
   glyphs (only if they want to take the red pill), this could reduce some 
   missuses if people must add more to get more complex
   - The EditorToolbar buttons would then apply a currently selected glyph 
   or can be cloned to create a new set of buttons for another glyph/or pair.
  - Using either the actual glyphs for the button or an svg version 
  (below)
   - I realise this level of customisation may be problematic but it will 
   solve other problems like forcing us to choose glyphs. I only ask because 
   of its desirability, but have know Idea if coding wizardry permits, even if 
   a reload is necessary.


  ⁽ ⁾



  ₍ ₎

Note 'y="22"' here, lest it be "trimmed" at the bottom.

*So to my thinking about glyphs *
This is done without a detailed response to existing uses and I stand to be 
corrected, they are suggestions only, more to share the organising 
principal than the specific glyphs.
In this case the glyphs differ by their default scope ie where they 
terminate

*Pre-prevision two inline braces glyphs*

   - ⁽ ⁾ superscript additional braces open and close defined
   - ₍ ₎ subscript additional braces
   
*Pre-provision beginning of line glyphs*

   - › suggests, one end of line (eol) which is terminated with "\n" by 
   default - A single line glyph like * and #
   - » suggests, two eol, which is terminated with "\n\n" by default - A 
   paragraph responsive Glyph
   - An alternative or additional paragraph responsive glyph "¶  pilcrow 
  sign" is still in my view  a valuable one and could be used with ⁋ 
REVERSED 
  PILCROW SIGN to wrap a block and force a paragraph element.
   - ´ tick like "›" but ´ suggests special mark-up follows, which is 
   terminated with "\n" by default, or /symbol if symbol is used (an no 
   alternative given) ie if symbol is used can be used as a block, only 
   

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

This is a nice resource.


I note the special page Mirrored characters 
https://www.compart.com/en/unicode/mirrored

But in this set I cant see the Maths 
alphanumerics https://www.unicode.org/charts/PDF/U1D400.pdf

Tones

On Tuesday, 27 October 2020 00:37:08 UTC+11, PMario wrote:
>
> On Monday, October 26, 2020 at 2:21:44 AM UTC+1, TonyM wrote:
>
> The best resource I have found now is https://www.unicode.org/charts/
>>
>
> I use this one, it names them nicely: 
> https://www.compart.com/en/unicode/category
>
> -m
>
>
>

-- 
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/f3bb4db7-6215-4b9d-8a27-8461a6a0da94o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario

Thanks for the update today. I will review in the next few hours.

In responce to your last reply, to me the small brackets,
do not look like they are surrounded by spaces in  tiddlywiki.

I will look at the 4 possibilities above, my current personal preference is 
d, b, a, c;
but I want to look at the outcome with customise inactive. 

I am not sure why you say new inline functions then you say no inline 
customise functions.
Do you mean inline works with underscore, you just can not customise it?

regards
Tony

On Wednesday, 28 October 2020 at 04:04:13 UTC+11 PMario wrote:

> Hi, 
>
> V 0.7.0 - 2020-10-23
>
>- New Inline functions
>   - _symbol.class.clsss:param:param some text__
>   - .class and :param work the same way as "block" definitions
>- Removed underscore from "block" definitions, because it's used by 
>"inline"
>- Added: \\ pragma comments
>   - It's faster than HTML comments , since it can be 
>   used outside macro \define x() blocks
>
>
>
> *NO \customize inline functions yet. *
>
> Have a closer look at the tiddler code: 
> https://wikilabs.github.io/editions/custom-markup/#tick-inline-simple  
>
>
> As you can see in the code below there are 4 possibilities atm.  I intend 
> to reduce them to 2 if possible!
>
> a)
>  - start: 2 underscores: __ 
>  - end: 3 underscores or 1 underscore slash : ___ or _/
>
> b)
>  - start: /°
>  - end: °/
>
> c) 
>  - start: ⠒
>  - end: ⠶
>
> d) 
>  - start: ﹙
>  - end: ﹚
>
> a,b,c are nestable if using them again. 
>
> d) is only nestable if one of the others is used. I'm not sure, if I like 
> this behaviour. ... 
>
> -mario
>
> switch (this.match[1]) {
> case "__":
> reEnd = /___|_\//g
> break;
> case "/°":
> reEnd = /°\//g
> break;
> case "⠒":
> reEnd = /⠶/g
> break;
> case "﹙":
> reEnd = /﹚/g
> break;
> }
>

-- 
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/7cf2a129-284d-49a9-a103-a5abac290ef1n%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,


On Tuesday, 27 October 2020 00:26:49 UTC+11, PMario wrote:
>
> On Monday, October 26, 2020 at 2:21:44 AM UTC+1, TonyM wrote:
>
> so we could use ﹙ to mark inline ﹚ then continue
>>
>> compare with  (﹙  ﹚) so we could use (﹙ to mark inline ﹚) then continue
>>
>
> Looks interesting. But you have to test like so: 
>
> (﹙symbol.class:param some text﹚)  or  (﹙symbol.class:param some text﹚) 
> ... there is no visual connection between the glyph and the symbol name. 
> eg: /°symbol.class:param. It looks as if there is a space already, which 
> will lead to problems.
>
>
I am not sure what you mean here. I was thinking more of

﹙symbol.class:param some text﹚

Where if you use ﹙ as the glyph, the end string is "﹚" for inline. The 
symbol remains free for other configurations

A specially formatted quote ﹙q.large some text﹚ in line ﹙ the default 
result ﹚ inline. (Assumes trailing space before ﹚ not needed, although 
training space for ﹙ is needed. )

If I may remind you and TT (and remind myself) not to be too brief in this 
correspondence, there is plenty of room for confusion here. 

Lets not ASSUME and make an ASS out of U and ME. :)

Regards
Tony
 

> -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/9e5ce87b-e202-4da4-9751-fd3c9e1f0aafo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

See also Unicode discovery additional alphabets and tiddlywiki, and a 
keyboard Question 
<https://groups.google.com/forum/?oldui=1#!topic/tiddlywiki/OElkElXfG7Y>

Tony

On Monday, 26 October 2020 12:21:44 UTC+11, TonyM wrote:
>
> Folks,
>
> Just sharing some Unicode exploration
>
> The best resource I have found now is https://www.unicode.org/charts/
>
> Fullwidth brackets FF5F ｟ FULLWIDTH LEFT WHITE PARENTHESIS • the most 
> commonly occurring glyph variant looks like doubled parentheses → 2E28 ⸨  
> left double parenthesis ≈ 2985 ⦅ FF60 ｠ FULLWIDTH RIGHT 
> 3010 【 LEFT BLACK LENTICULAR BRACKET 3011 】 RIGHT BLACK LENTICULAR BRACKET
>
>
> You can also turn them into SVG icons
> 
>   흣
>  
>
> Of note all the standard characters have a mathematical equivalent.
>
> We can also find Mayan numerals to 19 
> https://www.unicode.org/charts/PDF/U1D2E0.pdf
>
> Also I found a set of small punctuation symbols, that look the same only 
> small, but they are separate characters
> https://www.unicode.org/charts/PDF/UFE50.pdf
>
> so we could use ﹙ to mark inline ﹚ then continue
>
> compare with  (﹙  ﹚) so we could use (﹙ to mark inline ﹚) then continue
>
> Tony
>
> On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>>
>> Hi folks,
>>
>> This is the continuation of Custom markup 
>> <https://groups.google.com/forum/#!topic/tiddlywikidev/bj_2E9ifYkw[1-200]> 
>> [1] and Custom markup (continued) 
>> <https://groups.google.com/forum/#!topic/tiddlywikidev/Os_LCSCP_l8>and 
>> Custom 
>> markup (continued 2) 
>> <https://groups.google.com/forum/#!topic/tiddlywikidev/sCMOjYxMk2Q> [2]
>>
>> Let's start a new one before [2] starts to use pagination. 
>> Have a closer look at link [1] it's possible to show all the topics in 1 
>> page
>>
>> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>> <https://wikilabs.github.io/editions/custom-markup/> the above link 
>> won't work anymore!
>> have fun!
>> 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/6a7fac6a-b847-4c64-8363-4c0830156fcbo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Folks,

Just sharing some Unicode exploration

The best resource I have found now is https://www.unicode.org/charts/

Fullwidth brackets FF5F ｟ FULLWIDTH LEFT WHITE PARENTHESIS • the most 
commonly occurring glyph variant looks like doubled parentheses → 2E28 ⸨  
left double parenthesis ≈ 2985 ⦅ FF60 ｠ FULLWIDTH RIGHT 
3010 【 LEFT BLACK LENTICULAR BRACKET 3011 】 RIGHT BLACK LENTICULAR BRACKET


You can also turn them into SVG icons

  흣
 

Of note all the standard characters have a mathematical equivalent.

We can also find Mayan numerals to 
19 https://www.unicode.org/charts/PDF/U1D2E0.pdf

Also I found a set of small punctuation symbols, that look the same only 
small, but they are separate characters
https://www.unicode.org/charts/PDF/UFE50.pdf

so we could use ﹙ to mark inline ﹚ then continue

compare with  (﹙  ﹚) so we could use (﹙ to mark inline ﹚) then continue

Tony

On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>
> Hi folks,
>
> This is the continuation of Custom markup 
>  
> [1] and Custom markup (continued) 
> and Custom 
> markup (continued 2) 
>  [2]
>
> Let's start a new one before [2] starts to use pagination. 
> Have a closer look at link [1] it's possible to show all the topics in 1 
> page
>
> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>  the above link won't 
> work anymore!
> have fun!
> 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/81c85e5c-afa8-4e83-a7a7-c1d87c028b21o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

This is but an example, and yes in this simple case a macro may be the 
answer.

But it is the idea in general and as I said us we may just want to use it 
for shortcuts. Remembering it is easy for me to apply classes "inline" to 
my signature with a custom pragma than with a macro.

Sure let us explain the use case and when a more common existing method is 
best, in fact that will help people understand customise better.

Regards
Tony


On Monday, 26 October 2020 05:28:11 UTC+11, PMario wrote:
>
> On Sunday, October 25, 2020 at 12:59:38 AM UTC+2, TonyM wrote:
>
> \customise tick=sig _element="$text" text="Anthony Muscio"
>>
>> ´sig 
>>
>> But inline This is some text written by ´sig the author
>>
>>
> IMO it should be done "the old way" with: 
>
> \define sig() Mario Pietsch
>
> <>
>
> But inline This is some text written by <> the author
>
> Which imo is much simpler code and clear for everyone, which is familiar 
> with TW
>
> -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/f865671c-9e4b-4602-abe1-21f6573062f4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

On saving https://wikilabs.github.io/editions/custom-markup/ locally and 
dropping a plugin on it I get
Internal JavaScript Error
Well, this is embarrassing. It is recommended that you restart TiddlyWiki 
by refreshing your browser
Uncaught TypeError: Cannot read property 'configTickText' of undefined

I can research this more if you want but it seems to have a serious issue.

Regards
Tony

On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>
> Hi folks,
>
> This is the continuation of Custom markup 
>  
> [1] and Custom markup (continued) 
> and Custom 
> markup (continued 2) 
>  [2]
>
> Let's start a new one before [2] starts to use pagination. 
> Have a closer look at link [1] it's possible to show all the topics in 1 
> page
>
> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>  the above link won't 
> work anymore!
> have fun!
> 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/44e8d512-7156-4f9e-b06f-2bf778225ffao%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Folks,

In relation to inline use with custom pragmas we have being focusing on 
applying styles etc to some text delineated with open and close.

Keep in mind that with the wealth of things customise can do for us we may 
just want to use it for shortcuts

\customise tick=sig _element="$text" text="Anthony Muscio"

´sig 

But inline This is some text written by ´sig the author

Tony
 

On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>
> Hi folks,
>
> This is the continuation of Custom markup 
>  
> [1] and Custom markup (continued) 
> and Custom 
> markup (continued 2) 
>  [2]
>
> Let's start a new one before [2] starts to use pagination. 
> Have a closer look at link [1] it's possible to show all the topics in 1 
> page
>
> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>  the above link won't 
> work anymore!
> have fun!
> 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/10e7ad0b-9aca-4e3f-8eda-5af47b73f056o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

TT,

Perhaps this quick answer demonstrates what you are after?

\customize tick=q _element="$macrocall" $name=display-macro _srcName=
"wikitext" display="block"
\customize tick=a _element="$macrocall" $name=display-macro _srcName=
"wikitext" display={{!!display-answers}}
\define display-macro(wikitext display:"inline") $wikitext$

´q this is a question
´a This is an answer
´q this is another question
´a This is another answer
answers will only be displayed if the field display-answers on the current 
tiddler = block or inline (not none)?


   - The above (may) be achieved only with a customise, but demonstrates 
   calling macros with the customise as well.
   - This is achieved using the macrocall widget in part because it allows 
   us to use the substitution $display$ to alter the style.

Regards
Tony

On Saturday, 24 October 2020 23:26:14 UTC+11, @TiddlyTweeter wrote:
>
> Ciao Tony
>
> When I get back to reviewing the customise solution I will demonstrate a 
>> method for your need.
>
>
> *How to dynamically change Custom Markup styling USING a Custom Markup 
> launched macro  ... ?* 
>
> The issue is NOT Custom Markup per se. Assume that is DONE already. And 
> well.
>
> Rather, the issue is DYNAMIC modification of CSS style values for styles 
> already applied.
>
> The Palette macro instantiates an economical stable approach that 
> illustrates a solution.
>
> IF you have time to explore this it could be useful. For ...
>
> 1 - MY needs;
>
> 2 - WIDER demonstration of the utility of macros UNDER Custom Markup.
>
> I think it is point (2) that has most gravitas.
>
> Best wishes
> TT
>  
> On Friday, 23 October 2020 04:50:56 UTC+2, TonyM wrote:
>>
>> TT,
>>
>> This requirement is a fundamental aspect of the customise solution, which 
>> started with an idea called dot paragraphs. 
>> This idea had a leading . on any line causes subsequent lines to be 
>> treated as a single paragraph unit a \n is reached.
>>
>> In your case arguably you want to use a div or span rather than a p
>>
>> \customise tick=div _element=div
>>
>>
>> When I get back to reviewing the customise solution I will demonstrate a 
>> method for your need.
>>
>> In short it is I believe already possible.
>>
>> Tones
>>
>>
>>
>>
>> On Friday, 23 October 2020 01:28:37 UTC+11, @TiddlyTweeter wrote:
>>>
>>> Ciao Tony
>>>
>>> Me ... 
>>>
>>>> A SERIOUS use case would be HOW to invoke dynamic style change via 
>>>>> inline buttons.
>>>>>
>>>>  
>>> TonyM ...
>>>
>>>>  Can you give an example?
>>>
>>>
>>> A simple one would be to able to dynamically change "block style" for 
>>> paragraphs. I'm interested in archaic forms of writing where there is NO 
>>> gap between paragraphs. They form one flow.
>>>
>>> Being able to do this simply by changing  ...
>>>
>>> p.archaic {
>>>   display: 
>>> }
>>>
>>> ... from "block" to "inline" in a stylesheet that is otherwise unchanged 
>>> would be ace.
>>>
>>> Hope that is clearer on my aim!
>>> TT
>>>
>>

-- 
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/54183e11-f418-4b1e-afb4-a39cd1316d2eo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Edited in Forum

On Saturday, 24 October 2020 17:22:26 UTC+11, TonyM wrote:
>
> My Response [edited]
>
> On Saturday, 24 October 2020 13:46:22 UTC+11, PMario wrote:
>>
>> On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote:
>>>
>>> Mario,
>>> Inline syntax defaults to a SPAN. The inline  wikitext syntax doesn't 
>>> care about linebreaks. 
>>>
>>
>> So it can /° start in the middle of the line, 
>> and *end* at the start of the line 
>> °/ it  will create a span and show all the text in 1 line by default.
>>
>>
> Agreed, In fact sometimes that what we want to do. Take an inline slab and 
> treat it differently even if it contains line breaks eg a Quote however 
> more often and not we choose either;
>
>1. Mark-up with a line scope
>2. Mark-up with a paragraph scope
>3. Mark-up with a block scope
>4. And /°mark-up/° inline.
>
> Perhaps we can call these 4 "customised pragma forms". 
>
>
> This is where I think we should choose 4 glyphs set up for these default 
> "treatments" although their whole meaning can be redefined, this will be 
> their default behaviours. So If I scan your customised wiki text, I can 
> possibly guess the usage of custom mark-up, I have not yet looked at the 
> definition of.
>
> I don't know yet, but one glyph should be unencumbered with any defaults. 
> And perhaps others may be used for html/buttons/macros by default. I just 
> do not know enough about all the possibilities, and a way to categorise 
> them yet, perhaps only with usage will we determine which glyph is best at 
> representing which kind of customise (intuitively). When we know this we 
> would find it easy to determine how many glyphs we need to provision, what 
> general usage categories they fit in, and appropriate glyphs to represent 
> each category. This is a bit of a "putting the cart before the horse 
> problem".
>
> This is all about a de facto standard that can easily be broken in fact is 
> some cases that may be exactly what you want to do. While writing consider 
> it a code block, when finished use half line spaced paragraphs with justify 
> and the first word highlighted. Just by redefining the pragma once. ; Reuse 
> the same glyph, away from its de facto standard.
>
> I must say it is hard for me to remember which glyph, has which default 
> behaviour in the current setup.
>
> One that comes to mind is a simple way to mark text as a comment and 
> toggle its visibility, through either customising or some other state. 
> Comments may be of the  4 "customised pragma forms". above.
>
> Regards
> Tony
>

-- 
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/30eb7adc-49a0-4ec4-80fd-1e76ff585af0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

On Saturday, 24 October 2020 13:46:22 UTC+11, PMario wrote:
>
> On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote:
>>
>> Mario,
>> Inline syntax defaults to a SPAN. The inline  wikitext syntax doesn't 
>> care about linebreaks. 
>>
>
> So it can /° start in the middle of the line, 
> and *end* at the start of the line 
> °/ it  will create a span and show all the text in 1 line by default.
>
>
Agreed, In fact sometimes that what we want to do. Take an inline slab and 
treat it differently even if it contains line breaks eg a Quote however 
more often and not we choose either

   1. Mark-up with a line scope
   2. Mark-up with a paragraph scope
   3. Mark-up with a block scope
   4. And /°mark-up/° inline.

This is where I think we should choose 4 glyphs set up for these default 
"treatments" although their whole meaning can be redefined this will be 
their default behaviours. So If I scan you customised wiki text I can guess 
the usage of custom mark-up you have not looked at the definition of.

I don't know yet, but one glyph should be unencumbered with any defaults. 
And perhaps others may be used for html/buttons/macros by default.

This is all about a de facto standard that can easily be broken in fact is 
some cases that may be exactly what you want to do. Wile writing consider 
it a code block, when finished use half line spaced paragraphs with 
justify. Just by redefining the pragma once. Reuse the same glyph, away 
from its de facto standard.

I must say it is hard for me to remember which glyph, has which default 
behaviour in the current setup.

Regards
Tony

-- 
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/31adaf7d-361e-4d9b-b0f6-85b58b8e48a1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

So ⠪.class:param Braille 246 and Braille 2345⠞ may be an option. 
>
>
I understand open and close needs to be asymmetric to see which is which. 
But the solution such as 
/glyph content glyph/  - inline
or
glyph content /glyphline  - para or block

Still retains a degree of symmetry and is thus preferable if possible.

If both could be used the first can be inline and the second defaults to 
line/block

The first /glyph indicates its inline from the start because it is 
proceeded by / otherwise it will be readable elsewhere, and must have a 
matching /glyph (ie: \n and \n\n do not cancel it)

The second can be terminated with \n, and optionally be \n\n or demand a 
/glyph as defined in the pragma.

   - This is auto line based, auto paragraph (\n\n) based or block based 
   all in one pragma
   - This is the preferred default in my view because a line beginning 
   glyph can be assumed to treat the line as the scope eg; ; : * # ! etc...
   - Eg Then the author can use say glyphaside (the html aside tag) and 
   specify \n\n or /glyph as the terminator, because apart from anything 
   calling it  glyphaside suggests its a block capable of multiple lines or 
   paragraphs. That is using the customise definition glyph with an name, 
   transmits the information whether it is used as a line/paragraph or block.

Perhaps even this could work
glyph /glypg A quote with it wrapped in oversize quotes and italics /glyph 
and more (terminates at end of line eg \n)

glyph.aside This is text in a html aside /glypg A quote in the aside /glyph 
and more

However asides can have multiple lines and paragraphs So we expect it to be 
closed with a /glyph

Or should than be closed with `/glyph.aside`





This of course should still work!

glyph.classname
Something /glyph.classname content /glyph more

*A word of warning;*

One reason I spell out how the custom mark-up is terminated, is there seems 
there is still an area of uncertainty between us on the original issue of 
paragraphs and lines. I have found a case I have trouble demonstrating 
where its easy to do two formatting tricks but impossible to do another. I 
will try and find a case below.

*Another restatement of desire or intent on my part.*

I believe the two can be accommodated, we just need to flesh out the 
objective

The first thing I really need is
*° *one
*° *two
*° *three

   - The above would apply the customised mark-up to each line, ending at 
   the end of the line (\n) 
   - one two or three can be one word through to a whole paragraph of 
   sentences ending with \n
   - The customise can insist on an empty line after or not in the rendered 
   result.
   - This fixes that fact we cant apply custom mark-up at the moment on 
   lines that do not begin with an existing mark-up line character ! !! !! ; : 
   # * basically it says any line can have a custom mark-up.

Now consider 
one
two


three

four
Say this is found text, on the internet, from a copy and paste
This currently renders as 

one two

three

four

   - Rather than go through every line and deleting or adding \n to get one 
   only \n, consistently  or making each "paragraph end with  \n\n etc...
   - Again one two or three can be one word through to a whole paragraph of 
   sentences ending with \n and some have more than one \n
   - I just want to select a whole text or block and prefix it as follows;
   
*° *one
*° *two
*° *
*° *
*° *three
*° *
*° *four
Then depending on my custom wiki text definition;

   - If it defines a paragraph every line ending with \n will be come a 
   paragraph and only one blank line will appear between each paragraph at 
   render.
   - If every line is made into a `` paragraph then this is the 
   resulting behaviour, because empty p tags collapse to one empty line after 
   each paragraph with text.

However I also know in the above example *you* are keen (I think) to have 
the custom mark-up terminate only on \n\n to make use of a common use in 
text of an empty line following \n, thus \n\n to terminate the paragraph 
and custom mark-up. In this case you may do this;
*° *one
two

 
*° *three

four
In this example one and two will become a single paragraph, three will be 
another paragraph and four will follow after a blank line at the end of 
paragraph three.

   - Question: How does this differ from the default render except that you 
   can apply custom mark-up to each resulting paragraph delimited by \n\n, ? 
   eg *°*.classname or another element

There seems to me to be a gap between these two cases above, I have not 
learned to do, and it appears impossible;
I am not even sure I can illustrate the problem (Which is bugging me)

Lets see if I can in a future post

Tony

-- 
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 

[twdev] Re: Custom markup (continued 3)

[TonyM]

TT,

This requirement is a fundamental aspect of the customise solution, which 
started with an idea called dot paragraphs. 
This idea had a leading . on any line causes subsequent lines to be treated 
as a single paragraph unit a \n is reached.

In your case arguably you want to use a div or span rather than a p

\customise tick=div _element=div


When I get back to reviewing the customise solution I will demonstrate a 
method for your need.

In short it is I believe already possible.

Tones




On Friday, 23 October 2020 01:28:37 UTC+11, @TiddlyTweeter wrote:
>
> Ciao Tony
>
> Me ... 
>
>> A SERIOUS use case would be HOW to invoke dynamic style change via inline 
>>> buttons.
>>>
>>  
> TonyM ...
>
>>  Can you give an example?
>
>
> A simple one would be to able to dynamically change "block style" for 
> paragraphs. I'm interested in archaic forms of writing where there is NO 
> gap between paragraphs. They form one flow.
>
> Being able to do this simply by changing  ...
>
> p.archaic {
>   display: 
> }
>
> ... from "block" to "inline" in a stylesheet that is otherwise unchanged 
> would be ace.
>
> Hope that is clearer on my aim!
> TT
>

-- 
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/0f5ebc0e-fb89-4dc0-beee-b0b058983a57o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

TT,

If you create an _element using style you may be able to go someway to 
doing this. However you can also use any html tag and add the parameter 
class or style as it stands.

I agree the glyphs (good name) should suggest a default function like 
inline block, style, etc... but then we can define the result as we wish, 
this includes on for automatic termination on \n and another on \n\n

Examples included should be examples of good practice for each of the 
general glyph meanings.

You were very vocal about the integration of macro invocation via Custom 
> Markup.
>

One reason I want this for is also consistency. If we can use elements such 
as html $widget the 
> I'm slightly warming to the idea.  A SERIOUS use case would be HOW to 
> invoke dynamic style change via inline buttons.
>

Can you give an example?
 

>
> I *don't *mean simply tagging/untagging  a stylesheet tiddler.
>
> I mean a macro that changes the values of CSS declarations dynamically and 
> pass new values simply (like how the Palette system works). 
> THAT would, I think, be a superb way to show the power of Custom Markup.
>

On inline there is already the comment standard /* */ it seems to me /glyph 
inline content glyph/ is quite intuitive, its easy to see if it is opening 
or close in once you are familiar with it, It seems to say 
Open an inline with this glyph and close with this glyph it has the 
advantage as reading like a form of "markup" in the old fashioned form 
"with a pen", if the text is not in a wiki with the customise feature.
This may permit nesting as well.

Perhaps we could even have /* comment */ become a new wikitext option?

If there is an explicit open and an explicit close its easier to use such 
contracts to extract them from text programaticaly.

Regards
Tony
 

>
> Best, TT
>
>
>
> On Thursday, 22 October 2020 11:51:11 UTC+2, TonyM wrote:
>>
>> Bump,
>>
>> I too needed a break from this all expansive and innovative rush. But we 
>> should try and move it to at least a beta releases before our memories fade.
>>
>> Please advise if there is something I can do.
>>
>> Tony
>>
>>
>>

-- 
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/fc9a2eb3-d476-436f-911f-430a8de24c5ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Bump,

I too needed a break from this all expansive and innovative rush. But we 
should try and move it to at least a beta releases before our memories fade.

Please advise if there is something I can do.

Tony


-- 
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/125a053f-8574-4336-9d99-eb48689eed03o%40googlegroups.com.

[twdev] Re: Basic Question Regarding TW5 Framework

[TonyM]

Christopher,

Great idea, and always welcome such initiatives, yet a lot of value can be 
obtained by researching previous work (Prior Art) before starting or after 
you capture you current ideas, the community can always help, if you break 
it into bite size pieces.

Tones


On Wednesday, 21 October 2020 09:15:09 UTC+11, Christopher Walters wrote:
>
> Well as I mentioned, I've used TW5 for my DnD notes before, there's just a 
> lot of little things that slowed the process down, which is why I was 
> looking to create a software that streamlined the process.
>
> On Tuesday, October 20, 2020 at 4:04:16 PM UTC-6 TonyM wrote:
>
>> Christopher,
>>
>> Dungeon Master notes is possibly one of the most common specific uses of 
>> TiddlyWiki
>>
>> Look for T5 TiddlyWiki 5 in discord this is where a lot of gamers reside.
>>
>> This may work
>>
>> https://discord.gg/cjEfap
>>
>> Tones
>>
>>
>> On Wednesday, 21 October 2020 05:29:49 UTC+11, Christopher Walters wrote:
>>>
>>> Well, I was hoping to learn Javascript/React for job opportunities 
>>> besides, haha
>>>
>>> I don't know how familiar you are with Dungeons and Dragons, but the 
>>> idea I had for this software was to have a fast, responsive, organized way 
>>> to organize Dungeon Master notes, which would include things like 
>>> information on characters, locations, themes, and rules. I tried to do this 
>>> for myself with just raw TiddlyWiki, but I found that TW was a little *too 
>>> *fluid. I guess the easiest way to describe what I'm talking about 
>>> would be to describe a potential use case. 
>>>
>>> Here's a rough mockup of what I imagine the UI would be like.
>>>
>>> [image: zNhSTl7[1].png]
>>>
>>> The adventurers come to a haunted house. At the top of the page are tabs 
>>> (a), with quick access to areas that could be relevant soon, but aren't 
>>> currently the central focus. At the top of the main window, there are 
>>> 'sub-tabs' (b), which link to pages for the various sub-pages within this 
>>> larger area (Haunted House), like floors in a multi-story building. On one 
>>> side of the main window is a map, where "rooms" are hyperlinked such that 
>>> they navigate the app to the proper entry. Across from the map is a 
>>> scrollable section (d), detailing all of the "rooms" on this "floor." This 
>>> is where I really love TiddlyWiki's text editor, with the capacity to 
>>> quickly format and link to other pages. In fact, when I was making this UI, 
>>> I straight up took a screenshot of my old TiddlyWiki notes.
>>>
>>> Within a moment, I could click the 'Floor 2' sub-tab, and everything 
>>> within the map and the main notes area (c and d) would update accordingly. 
>>> I could click 'Floor 1' and everything would return to this way it was 
>>> before. 
>>>
>>> I'd also like there to be a 'quick navigation' or 'quick search' 
>>> function, something like the 'Ctrl + K' functionality that Discord has, 
>>> that allows the DM to search for key words, and navigate to an entry very 
>>> very quickly. 
>>>
>>> I'm assuming that the 'rooms' or entries might have a path, something 
>>> like `continent/country/region/village/Haunted House/floor/Spare Bedroom`, 
>>> and that's what the link would contain. I could contain multiple rooms on 
>>> the same floor with the same title, such as "Spare Bedroom", even though 
>>> they would have different paths for linking purposes.
>>>
>>> The text editor from TiddlyWiki mostly serves my purposes for a text 
>>> editor perfectly, though there's a fair amount of customization that I'd 
>>> actually like to cut down on, for the sake of user simplicity. 
>>>
>>> On Monday, October 19, 2020 at 6:59:30 PM UTC-6 TonyM wrote:
>>>
>>>> Christopher,
>>>>
>>>> 95% of what tiddlywiki can do does not need  Javascript/React. It has 
>>>> its own wikitext and macro language and widgets to achieve almost 
>>>> anything. 
>>>> No to mention the plugins and editions available.
>>>>
>>>> I have build my own rapid development environment on top of tiddlywiki 
>>>> without more than the odd hack given to me.
>>>>
>>>> If you think you need to make use of Javascript/React no matter, but 
>>>> perhaps tell us what functionality you are trying to get, and we can tell 
>>>> you if its

[twdev] Re: Basic Question Regarding TW5 Framework

[TonyM]

Christopher,

Dungeon Master notes is possibly one of the most common specific uses of 
TiddlyWiki

Look for T5 TiddlyWiki 5 in discord this is where a lot of gamers reside.

This may work

https://discord.gg/cjEfap

Tones

On Wednesday, 21 October 2020 05:29:49 UTC+11, Christopher Walters wrote:
>
> Well, I was hoping to learn Javascript/React for job opportunities 
> besides, haha
>
> I don't know how familiar you are with Dungeons and Dragons, but the idea 
> I had for this software was to have a fast, responsive, organized way to 
> organize Dungeon Master notes, which would include things like information 
> on characters, locations, themes, and rules. I tried to do this for myself 
> with just raw TiddlyWiki, but I found that TW was a little *too *fluid. I 
> guess the easiest way to describe what I'm talking about would be to 
> describe a potential use case. 
>
> Here's a rough mockup of what I imagine the UI would be like.
>
> [image: zNhSTl7[1].png]
>
> The adventurers come to a haunted house. At the top of the page are tabs 
> (a), with quick access to areas that could be relevant soon, but aren't 
> currently the central focus. At the top of the main window, there are 
> 'sub-tabs' (b), which link to pages for the various sub-pages within this 
> larger area (Haunted House), like floors in a multi-story building. On one 
> side of the main window is a map, where "rooms" are hyperlinked such that 
> they navigate the app to the proper entry. Across from the map is a 
> scrollable section (d), detailing all of the "rooms" on this "floor." This 
> is where I really love TiddlyWiki's text editor, with the capacity to 
> quickly format and link to other pages. In fact, when I was making this UI, 
> I straight up took a screenshot of my old TiddlyWiki notes.
>
> Within a moment, I could click the 'Floor 2' sub-tab, and everything 
> within the map and the main notes area (c and d) would update accordingly. 
> I could click 'Floor 1' and everything would return to this way it was 
> before. 
>
> I'd also like there to be a 'quick navigation' or 'quick search' function, 
> something like the 'Ctrl + K' functionality that Discord has, that allows 
> the DM to search for key words, and navigate to an entry very very quickly. 
>
> I'm assuming that the 'rooms' or entries might have a path, something like 
> `continent/country/region/village/Haunted House/floor/Spare Bedroom`, and 
> that's what the link would contain. I could contain multiple rooms on the 
> same floor with the same title, such as "Spare Bedroom", even though they 
> would have different paths for linking purposes.
>
> The text editor from TiddlyWiki mostly serves my purposes for a text 
> editor perfectly, though there's a fair amount of customization that I'd 
> actually like to cut down on, for the sake of user simplicity. 
>
> On Monday, October 19, 2020 at 6:59:30 PM UTC-6 TonyM wrote:
>
>> Christopher,
>>
>> 95% of what tiddlywiki can do does not need  Javascript/React. It has its 
>> own wikitext and macro language and widgets to achieve almost anything. No 
>> to mention the plugins and editions available.
>>
>> I have build my own rapid development environment on top of tiddlywiki 
>> without more than the odd hack given to me.
>>
>> If you think you need to make use of Javascript/React no matter, but 
>> perhaps tell us what functionality you are trying to get, and we can tell 
>> you if its native or already available.
>>
>> Regards
>> Tony
>>
>>
>> On Tuesday, 20 October 2020 08:54:43 UTC+11, Christopher Walters wrote:
>>>
>>> Okay, that's good to know, I guess I'll come back to this forum when I 
>>> have a stronger understanding a Javascript/React. I've got plans for an 
>>> Electron application, but I loved the text editing and Hyperlinking 
>>> capabilities from TiddlyWiki, which is why I wanted to ask here. Thanks for 
>>> your help. 
>>>
>>> On Sunday, October 18, 2020 at 5:42:07 PM UTC-6 joshua@gmail.com 
>>> wrote:
>>>
>>>> Yes, TiddlyWiki5 is definitely its own "paradigm". While similar to 
>>>> React, in that a javascript model is updated, and these updated are passed 
>>>> to the "DOM" to be rendered by the browser, it is very unique in how it is 
>>>> constructed and how updates are called.
>>>>
>>>> Resources:
>>>>
>>>> https://tiddlywiki.com/dev/
>>>> https://tiddlywiki.com/dev/#TiddlyWiki%20Core%20Application
>>>>
>>>> https://softwareas.com/tiddlywiki-internals-1-of-3-architectu

[twdev] Re: Basic Question Regarding TW5 Framework

[TonyM]

Christopher,

95% of what tiddlywiki can do does not need  Javascript/React. It has its 
own wikitext and macro language and widgets to achieve almost anything. No 
to mention the plugins and editions available.

I have build my own rapid development environment on top of tiddlywiki 
without more than the odd hack given to me.

If you think you need to make use of Javascript/React no matter, but 
perhaps tell us what functionality you are trying to get, and we can tell 
you if its native or already available.

Regards
Tony


On Tuesday, 20 October 2020 08:54:43 UTC+11, Christopher Walters wrote:
>
> Okay, that's good to know, I guess I'll come back to this forum when I 
> have a stronger understanding a Javascript/React. I've got plans for an 
> Electron application, but I loved the text editing and Hyperlinking 
> capabilities from TiddlyWiki, which is why I wanted to ask here. Thanks for 
> your help. 
>
> On Sunday, October 18, 2020 at 5:42:07 PM UTC-6 joshua@gmail.com 
> wrote:
>
>> Yes, TiddlyWiki5 is definitely its own "paradigm". While similar to 
>> React, in that a javascript model is updated, and these updated are passed 
>> to the "DOM" to be rendered by the browser, it is very unique in how it is 
>> constructed and how updates are called.
>>
>> Resources:
>>
>> https://tiddlywiki.com/dev/
>> https://tiddlywiki.com/dev/#TiddlyWiki%20Core%20Application
>> https://softwareas.com/tiddlywiki-internals-1-of-3-architectural-concepts/
>>
>> https://softwareas.com/tiddlywiki-internals-2-of-3-list-of-javascript-files/
>>
>> https://softwareas.com/tiddlywiki-internals-3-of-3-key-javascript-classes-and-files/
>> https://btheado.github.io/tw-widget-tutorial/
>>
>> Best,
>> Joshua Fontany
>>
>> On Sunday, October 18, 2020 at 3:51:45 PM UTC-7 TonyM wrote:
>>
>>> Christopher,
>>>
>>> Others can give a more technical origins story, but to me TiddlyWiki is 
>>> the framework. It is a platform in its own right and relies on broad 
>>> standards of HTML and Javascript. 
>>>
>>> When incorporating Javascript you need to be aware of the way tiddlywiki 
>>> works because its efficient update propagation to the whole wiki when a 
>>> change occurs is what gives tiddlywiki power to a developer and user.
>>>
>>> Because of this use of standard software standards plus a set of 
>>> mechanisium in many cases its possible to plug in many alternative 
>>> technologies, both in single file files and even more so on Node JS server 
>>> implementations.
>>>
>>> A key thing to remember is most of tiddlywiki is totally visible even 
>>> within a single empty.html, by learning how to navigate the internals of 
>>> tiddlywiki it becomes self documenting and you can follow a current 
>>> function to learn how its done and clone and build a new new and novel 
>>> solution.
>>>
>>> A piece of advice to New users and javascript writers is as a platform 
>>> or framework much can be achieved already tiddlywiki without resorting to 
>>> new Javascript code. I believe the key input needed by javascript coders is 
>>> filling gaps in functionality or performance when needed or creating 
>>> engines for complex computations. Fortunately open source projects in 
>>> javascript or HTML can be and have being, "ported" into the tiddlywiki 
>>> frame work successfully, and this makes use of other open source 
>>> communities efforts. 
>>>
>>> I feel tiddlywiki is about both niche and general solutions but I have 
>>> adopted it as my development environment of choice on top of which I can 
>>> build anything including tools to build TiddlyWiki's or websites and apps.
>>>
>>> Regards
>>> Tony
>>>
>>>
>>> On Monday, 19 October 2020 07:02:05 UTC+11, Christopher Walters wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have dreams for creating a piece of software for this really niche 
>>>> purpose, and I found myself returning time and again to TiddlyWiki as the 
>>>> basis for a lot of it. 
>>>>
>>>> My question is really basic, feels like it doesn't even really warrant 
>>>> a Conversation post  What framework does TiddlyWiki use? 
>>>>
>>>> I've heard of things like Angular or React, but I'm just looking for a 
>>>> name that I can research and learn on my own, for the purposes of 
>>>> replicating that aspects of TW5 that I enjoy so much. 
>>>>
>>>

-- 
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/d9967d73-01aa-42c8-9b54-b44bdb969375o%40googlegroups.com.

[twdev] Question: Illegal tiddler titles as namespace for features

[TonyM]

Folks,

There is a warning not to use curly braces or square brackets in the 
tiddler titles

eg {text}

There is also a warning for [ ] square barckets.

eg [prefix[prefix[]] such as a filter. I understand this and would notmake 
use of these as a rule.

However you can actually create tiddlers with these as such, I am wondering 
the following;

   - I understand for general use these tiddler names are problematic 
   because they will need special handling to allow parsing and transclusion 
   etc...
  - That is these rules should be followed in general
   - However I am keen to look at using such braces in special tiddlers for 
   handling various cases.
  - An example may be using {fieldname} as a tiddler that provides view 
  and edit code for each fieldname.
  - I could hide it behind a $:/fields/fieldname but I am finding value 
  using such short names because it is easy to remember, just bracket.
  - It has the added advantage of being searchable fieldname will list 
  {fieldname}
  - Perhaps I could even use {!!fieldname} as a field tiddlers title.
   - I am already making use of the permitted (transcludableTiddler) naming 
   standard.
   - I do not recall why I saw value in tiddlers named as a filter but I do 
   remember it could add a great deal of functionality.

I am currently working on a content authoring tool that allows quick 
insertion of other tiddlers titles into the authors text, having field 
tiddlers could do the same help insert a fieldname into wikitext

Thanks in advance for you thoughts

Tones/Tony

-- 
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/fddf27ab-80c1-479e-ba4b-f61a49604ea5o%40googlegroups.com.

[twdev] Re: Question: Set cursor in editmode to fieldname?

[TonyM]

Sorry, Reposted in main forum

On Monday, 19 October 2020 10:56:39 UTC+11, TonyM wrote:
>
> Folks,
>
> I have a button that creates a new field then uses the message
> <$action-sendmessage $message="tm-edit-tiddler" $param="tiddlername"/>
> To open the tiddler for edit.
>
> Is it possible somehow to get the cursor to appear in the new field?
>
> Why?
> This would simplify providing a value to the field if we could click open 
> for edit and type, with no need to mouse to the field.
>
> Thanks in advance
> Tony
>
>
>

-- 
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/722c08c8-becf-4690-a63c-74a090d11724o%40googlegroups.com.

[twdev] Question: Set cursor in editmode to fieldname?

[TonyM]

Folks,

I have a button that creates a new field then uses the message
<$action-sendmessage $message="tm-edit-tiddler" $param="tiddlername"/>
To open the tiddler for edit.

Is it possible somehow to get the cursor to appear in the new field?

Why?
This would simplify providing a value to the field if we could click open 
for edit and type, with no need to mouse to the field.

Thanks in advance
Tony


-- 
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/bbf45a1e-c097-422c-aab9-3e977ee25c16o%40googlegroups.com.

[twdev] Re: How can I install an unofficial Saver?

[TonyM]

Ryan,

Always consider an unofficial saver as a candidate for an  official saver 
if you can expand and democratise tiddlywiki,

Regards
Tones

On Tuesday, 22 September 2020 09:14:27 UTC+10, Ryan Kramer wrote:
>
> Thank you Mario, that looks like what I want to do. (Assuming that once I 
> build the TW using nodejs I can save it as a single file and use it in 
> single-file mode going forward. This is probably obviously true but I'm new 
> to TW5.)
>
> @TiddlyTweeter "What is the the added value over extant tools?" Good 
> question. I'm new to TW5 so maybe there is already a way to meet my 
> requirements:
> 1) I should be able to access my wiki from anywhere, as long as I have a 
> web browser and can remember my domain name, username, and password.
> 2) I should be able to stay signed-in via a browser cookie until I sign 
> out.
> 3) The TW should be backed up as a single HTML file into a cloud storage 
> account that I control.
> 4) Backups exceeding X days should automatically be purged
>
> I realized I can do this very easily using AWS. The S3 bill will round 
> down to zero (possibly literally), and everything else is within the AWS 
> Free Tier.
>
> The more I think about it, my custom Saver isn't very "custom" at all. It 
> just does a PUT to send the entire HTML back to window.location.pathname. 
> This probably isn't the most bandwidth-efficient way to do it, but it works 
> for me.
>
> On Monday, September 21, 2020 at 12:45:05 PM UTC-5 PMario wrote:
>
>> Hi Ryan,
>>
>> How do you build your TW? With node?
>>
>> You can set your environment variables see: 
>> https://tiddlywiki.com/#Environment%20Variables%20on%20Node.js to your 
>> plugin library. 
>>
>> If you build a new TW the plugin will be included. 
>>
>> Have a closer look at this discussion: 
>> https://groups.google.com/d/msg/tiddlywiki/EMHF71bzlP0/Qdr0GsT4AgAJ
>>
>> If that's not enough, let us know!
>>
>> -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/804e81dd-56e3-4c7a-a3ac-4084dafc0fb6o%40googlegroups.com.

[twdev] Re: Basic Question Regarding TW5 Framework

[TonyM]

Christopher,

Others can give a more technical origins story, but to me TiddlyWiki is the 
framework. It is a platform in its own right and relies on broad standards 
of HTML and Javascript. 

When incorporating Javascript you need to be aware of the way tiddlywiki 
works because its efficient update propagation to the whole wiki when a 
change occurs is what gives tiddlywiki power to a developer and user.

Because of this use of standard software standards plus a set of 
mechanisium in many cases its possible to plug in many alternative 
technologies, both in single file files and even more so on Node JS server 
implementations.

A key thing to remember is most of tiddlywiki is totally visible even 
within a single empty.html, by learning how to navigate the internals of 
tiddlywiki it becomes self documenting and you can follow a current 
function to learn how its done and clone and build a new new and novel 
solution.

A piece of advice to New users and javascript writers is as a platform or 
framework much can be achieved already tiddlywiki without resorting to new 
Javascript code. I believe the key input needed by javascript coders is 
filling gaps in functionality or performance when needed or creating 
engines for complex computations. Fortunately open source projects in 
javascript or HTML can be and have being, "ported" into the tiddlywiki 
frame work successfully, and this makes use of other open source 
communities efforts. 

I feel tiddlywiki is about both niche and general solutions but I have 
adopted it as my development environment of choice on top of which I can 
build anything including tools to build TiddlyWiki's or websites and apps.

Regards
Tony

On Monday, 19 October 2020 07:02:05 UTC+11, Christopher Walters wrote:
>
> Hi all,
>
> I have dreams for creating a piece of software for this really niche 
> purpose, and I found myself returning time and again to TiddlyWiki as the 
> basis for a lot of it. 
>
> My question is really basic, feels like it doesn't even really warrant a 
> Conversation post  What framework does TiddlyWiki use? 
>
> I've heard of things like Angular or React, but I'm just looking for a 
> name that I can research and learn on my own, for the purposes of 
> replicating that aspects of TW5 that I enjoy so much. 
>

-- 
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/827b544a-37cb-4ce2-b9a7-d6973a05c364o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Folks,

I simply can't get over the power this adds to tiddlywiki. 

   - Even just to use a symbol for a known or arbitrary html element name 
   is immensely powerful. 
   - Having a symbol and name simply replace a specific implementation of a 
   widget and pre-set attributes
  - This includes the use of the macrocall widget to prefill macro 
  parameters.
   - The ability to use a set of .classnames against any line or block in 
   wikitext is another expansive opportunity
  - The classnames so defined are readily applied to other wikitext 
  elements and are thus able to be re-used in many places.
   - Using a symbol/name to indicate the application of a larger set of 
   classes is also a way to collapse complexity into the minimum of annotations
   - It is now possible to generate an "alias" name for many things 
   including existing css 
   \customise tick=frame _classes="tc-tiddler-frame"
   - To be able to provide the content of a line as input to many different 
   customised responses
   eg filter to list-links °orderedList [tag[toc]] 
   

I am yet to fully comprehend how to go between inline, block and \n or \n\n 
without end strings but I think its all there?

I am also trying to use previous workarounds with customise for anchors and 
links within tiddlers. Then simplify with customise.

Regards
Tony


-- 
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/2a7b12b9-5002-436b-949f-ef71a92f1b4fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

Perhaps there is something I do not understand but I am suggesting a 
specific symbol lets say ¤ as a working symbol

   - Perhaps I can state it in different words?


Consider this
\customise sym=elementname _element=elementname

¤elementname that will internally parse this as if there existed a 

¤elementname.classname and allowing class names
You can see the customise is repetitive, but currently it must be explicit

What I am suggesting is there is so much value in using customise just to 
take a named element name and allow a classname(s) to be applied and close 
it.
 line or content 
So I am asking if it would be possible to to convert any line beginning 
with a fixed special character to result in a open and close element of the 
immediate text. Arguably auto close on \n\n

Why;

   - HTML elements, open and closed arbitrary or not, could be collapsed to 
   ¤elementname.classname
   - Arbitrary html sections allow the author to mark-up their content 
   according to logical names

This tiddler is about 

   - Then with a small set of css or macros and view templates we can alter 
   the display, or search all tiddlers for such content
   - This works well *already* but I was wondering if we can replace this 
   with ¤elementname.classname ?
   - Macros can either interrogate the rendered html or between ¤elementname  
   and \n\n to extract the contents.

For many users this would be a compelling use of the customise pragma but 
they would not need to define such customise parameters at all.


Regards
Tony

On Tuesday, 6 October 2020 02:58:47 UTC+11, PMario wrote:
>
> On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote:
>
> This makes me ask if one of out special characters could simply default to 
>> the element that follows the special character
>>
>> eg
>> 'aside Content is an aside
>>
>>
>>- That is nominate one of the special character to just automatically 
>>treat what follows as this does \customise tick=aside _element=aside
>>
>> This would be possible if we would check against an HTML list of "names". 
> which is already done, eg: _element="article" will have a look at: 
> https://github.com/Jermolene/TiddlyWiki5/blob/9716c326952c16f63345a135e73cf36670dca0d8/core/modules/config.js#L37
>
> But we would probably need to update this list, since "Details" isn't 
> listed there. 
>  
>
>>
>>- So in fact we do not need to define any \customise tick=elementname 
>>_element=elementname
>>
>> We do for "names" that are not html tags.
>  
>
>>
>>- This should be achievable programaticaly so any element name can be 
>>used including arbitrary html elements.
>>
>> including "arbitrary" tags is not possible, since this would limit the 
> names to html elements only. .. That's not what we want. 
>
> -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/b97c2e46-e726-4c99-b2dc-bd0a5bebe512o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

I have returned to research after a short break, and realise it is not as 
intuitive when you come back to, it but I am getting there.

As a starter I am reviewing first simple elements only 

eg;
\customise tick=kbd _element=kbd _mode='inline'
\customise tick=div _element=div
\customise tick=p _element=p
\customise tick=summary _element=summary
\customise tick=article _element=article
\customise tick=aside _element=aside

They all seem to work as advertised and allow the additional of classes

This makes me ask if one of out special characters could simply default to 
the element that follows the special character

eg
'aside Content is an aside


   - That is nominate one of the special character to just automatically 
   treat what follows as this does \customise tick=aside _element=aside
   - So in fact we do not need to define any \customise tick=elementname 
   _element=elementname
   - This should be achievable programaticaly so any element name can be 
   used including arbitrary html elements.

So if we did this it would work like below but with no need to use the 
\customise pragma for a nominated tic.
\customise tick=question _element=question
\customise tick=answer _element=answer

question { display: initial }
answer { display: none }


´question What do you think?

´answer Really cool eh?



By the way I do nor think we shopuld say 

=

Since to me the tick degree etc.. is a symbol


To me 

=
Would be better and note that name can be a single character, work or character 
(the symbol).

Regards

Tony




On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>
> Hi folks,
>
> This is the continuation of Custom markup 
>  
> [1] and Custom markup (continued) 
> and Custom 
> markup (continued 2) 
>  [2]
>
> Let's start a new one before [2] starts to use pagination. 
> Have a closer look at link [1] it's possible to show all the topics in 1 
> page
>
> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>  the above link won't 
> work anymore!
> have fun!
> 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/04b6f31f-2dc9-405a-8a83-df0f618cdacdo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Sorry, To be a little clearer on my previous question answer

You may use answers to display all answers at once;

Otherwise
'q1 Question 1
'a1 answer 1

etc...
Tony

On Monday, 5 October 2020 23:54:08 UTC+11, TonyM wrote:
>
> Mario,
>
> I have returned to research after a short break, and realise it is not as 
> intuitive when you come back to, it but I am getting there.
>
> As a starter I am reviewing first simple elements only 
>
> eg;
> \customise tick=kbd _element=kbd _mode='inline'
> \customise tick=div _element=div
> \customise tick=p _element=p
> \customise tick=summary _element=summary
> \customise tick=article _element=article
> \customise tick=aside _element=aside
>
> They all seem to work as advertised and allow the additional of classes
>
> This makes me ask if one of out special characters could simply default to 
> the element that follows the special character
>
> eg
> 'aside Content is an aside
>
>
>- That is nominate one of the special character to just automatically 
>treat what follows as this does \customise tick=aside _element=aside
>- So in fact we do not need to define any \customise tick=elementname 
>_element=elementname
>- This should be achievable programaticaly so any element name can be 
>used including arbitrary html elements.
>
> So if we did this it would work like below but with no need to use the 
> \customise pragma for a nominated tic.
> \customise tick=question _element=question
> \customise tick=answer _element=answer
> 
> question { display: initial }
> answer { display: none }
> 
>
> ´question What do you think?
>
> ´answer Really cool eh?
>
>
>
> By the way I do nor think we shopuld say 
>
> =
>
> Since to me the tick degree etc.. is a symbol
>
>
> To me 
>
> =
> Would be better and note that name can be a single character, work or 
> character (the symbol).
>
> Regards
>
> Tony
>
>
>
>
> On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>>
>> Hi folks,
>>
>> This is the continuation of Custom markup 
>> <https://groups.google.com/forum/#!topic/tiddlywikidev/bj_2E9ifYkw[1-200]> 
>> [1] and Custom markup (continued) 
>> <https://groups.google.com/forum/#!topic/tiddlywikidev/Os_LCSCP_l8>and 
>> Custom 
>> markup (continued 2) 
>> <https://groups.google.com/forum/#!topic/tiddlywikidev/sCMOjYxMk2Q> [2]
>>
>> Let's start a new one before [2] starts to use pagination. 
>> Have a closer look at link [1] it's possible to show all the topics in 1 
>> page
>>
>> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>> <https://wikilabs.github.io/editions/custom-markup/> the above link 
>> won't work anymore!
>> have fun!
>> 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/8641a4ab-1b41-49bd-ac75-60a34ffe4024o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

Thanks for the progress and listening. Today is a public holiday and I am 
spending time with my partner, so may not feedback today.

This project certainly has "energised me" both for its outcomes and what I 
perceive to be other key improvements we need in TiddlyWiki. It has also 
led to some new insights. 

One project is "canned templates", basically a set of templates in tiddlers 
with practical names.

   - Helpful with a number of customise shortcuts


For example "(new-journal-here)" is a tiddler, `{{||(new-journal-here)}}` 
will present a new journal here button for the current Tiddler. Basically a 
pseudonym for 
{{||$:/core/ui/Buttons/new-journal-here}}

Either in a viewTemplate, wikitext or *Using customised shortcuts* which 
use a list they are a quick way to add features

\customise tick=toptoc _element="$list" filter="[tag[toc]]"

´toptoc {{||(link)}} {{||(new-here)}}

Gives

[image: Snag_6a15d6.png]
Some I am building

   - (block)
   - (caption-title)
   - (copy-text)
   - (copy-title)
   - (currentTiddler)
   - (edit-fields)
   - (edit-text)
   - (edit)
   - (editor)
   - (export-tiddler)
   - (inline)
   - (link)
   - (new-here)
   - (new-journal-here)
   - (notes-tiddler)
   - (open-window) 
   toptoc {{||(open-window)}} {{||(link)}}
   - (set-tsn)
   - (tiddler-buttons) a set of buttons to use on lists of tiddlers

[image: Snag_708d0c.png] 




Regards
Tony

On Sunday, 4 October 2020 23:23:33 UTC+11, PMario wrote:
>
> Hi foks,
>
> I did just upload V0.6.0 which has some INCOMPATIBLE changes. 
>
>
>- *New Functionality*
>   - $:/config/custom-markup/pragma/PageTemplate 
>   
> 
>  
>   tagged: $:/tags/Macro
>  - content: \importcustom [tag[$:/tags/pragma]]
>   - contains global pragma definitions .. and macro definitions
>- *Incompatible changes*
>   - _params renamed to -> _classes
>   - _maps renamed to -> _params !!
>   - Adjusted the docs accordingly
>- Improved debug modes
>   - \debugcustomize new parameters: no, list, global, global list, global 
>   ID
>   - _debug new parameter: no,
>- angel renamed to: angle + docs
>
> -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/d0fd23a7-405e-4693-b410-db55a9f73f8fo%40googlegroups.com.

[twdev] Re: Peer Review please Cheat sheet

[TonyM]

Folks,

This working tiddler is published here;

https://anthonymuscio.github.io/#Standard%20Nomenclature

Regards
Tony

On Thursday, 1 October 2020 12:17:43 UTC+10, TonyM wrote:
>
> Folks,
>
> I have being building a "CheatSheet" that I would appreciate expert review 
> if possible. Please respond with references to the number of each item.
>
> You can see it is built on Tobias and Eric's work to name a few. It tries 
> and make simple, some particularly tricky issues that new and experienced 
> users face.
>
> Regards
> Tony
>
> Important note:
>
>- The following is a Cheatsheet or quick reference to the following
>wikitext, variables, widgets, filters, operators and the use of 
>references variables, macros, html tags and their attributes/parameters
>- *Key widgets* that are used sometimes, for a complete solution are 
>$text <https://tiddlywiki.com/#TextWidget>, $macrocall 
><https://tiddlywiki.com/#MacroCallWidget>, $wikify 
><https://tiddlywiki.com/#WikifyWidget> and $transclude 
><https://tiddlywiki.com/#TranscludeWidget>, otherwise this 
>documentation relates to all widgets.
>- Many *non-coders* may find this intimidating however should keep the 
>following in mind;
>   - much of this is actually essential not just for programming, but 
>   logical necessary, similar to the use of punctuation in hand writting.
>   - Whilst it may seem complex at first, the application of these 
>   rules is not only consistent throughout TiddlyWiki, but has a lot in 
> common 
>   with most other implementations of html, programming languages, mark-up 
> and 
>   a lot more.
>   - This document is a summary of things learned over a number of 
>   years by the author, don't expect to understand it overnight.
>   - Somewhere on this learning curve you will have to stop calling 
>   yourself a *non-coder*.
>- Prior knowledge of these will help, and regardless what you learn to 
>use TiddlyWiki it will include transferable skills.
>   - You are not required to learn much that is single purpose, and 
>   all will unleash the power of TiddlyWiki
>- In this cheat sheet the use of single square brackets indicates 
>something optional, eg; <> [params] means that is 
>optional.
>
> ❶ General wiki text (including inside macros)For additional possibilities 
> with inside macros see *❸ Within macro definitions* below.
>
>1. literal values when literal values are used as parameters or 
>attributes the quoting rules apply see *➃ Using literals and 
>parameters*
>2.   html tags immediate closure
>3.   later closure
>4. <> immediate closure, see ➀ for later 
>closure
>5. <$widgetname [params] /> immediate closure
>6. <$widgetname [params]> inside the widget  later 
>closure (for more see *➁ Content of widgets*)
>7. {{tiddlername}} transclude the content of the tiddlername's text 
>field and render
>8. {{!!fieldname}} transclude the content of the currentTiddlers 
>fieldname and render
>9. {{tiddlername!!fieldname}} transclude the content of the 
>tiddlername's fieldname and render
>10. {{{ [addprefix[$:/myprefix/]] }}} filtered 
>transclusion, see also *❻ More on filtered transclusions*
>11. Not valid in General wiki text
>   1. 
>   2. "",
>   3. [[]]
>
> ❷ Widget and HTML attributes or parameters html element attributes 
> <https://tiddlywiki.com/#HTML%20in%20WikiText>, e.g. $macrocall
>
>1. <$widget attribute="literal value"/> see *➃ Using literals and 
>parameters*
>2. <$widget attribute=<>/> using a variable
>3. <$widget attribute=<>/> using a macro
>4. <$widget attribute={{transclusion}}/> using a transclusion see
>5. <$widget attribute={{{ filter }}}/> filtered transclusion ;❻
>6.  see *➃ Using literals and 
>parameters*
>7. >/> using a variable as a HTML 
>attribute
>8. >/> using a variable 
>as a HTML attribute
>9.  using a variable as a HTML 
>attribute see more on transclusions ❻ and ❼
>10.  filtered transclusion ;❻
>11. {{!!transclusion}} a field who's value can also be inside [[ ]]
>12. *Not valid in widget attributes/parameters*
>   1. <$widget attribute="prefix-<>"/> can not concatenate 
>   literals and variables in a parameter
>   2. <$widget attribute=[[prefix-<>]]/> can not concatenate 
>   literals and variables in a parameter or treat it as a tiddler link a

[twdev] Peer Review please Cheat sheet

[TonyM]

Folks,

I have being building a "CheatSheet" that I would appreciate expert review 
if possible. Please respond with references to the number of each item.

You can see it is built on Tobias and Eric's work to name a few. It tries 
and make simple, some particularly tricky issues that new and expierenced 
users face.

Regards
Tony

Important note:
   
   - The following is a Cheatsheet or quick reference to the following
   wikitext, variables, widgets, filters, operators and the use of 
   references variables, macros, html tags and their attributes/parameters
   - *Key widgets* that are used sometimes, for a complete solution are 
   $text , $macrocall 
   , $wikify 
    and $transclude 
   , otherwise this docmentation 
   relates to all widgets.
   - Many *non-coders* may find this intimidating however should keep the 
   following in mind;
  - much of this is actually essential not just for programming, but 
  logical necessary, similar to the use of punctuation in hand writting.
  - Whilst it may seem complex at first, the application of these rules 
  is not only consistent throughout TiddlyWiki, but has a lot in common 
with 
  most other implementations of html, programing languages, markup and a 
lot 
  more.
  - This document is a summary of things learned over a number of years 
  by the author, don't expect to understand it overnight.
  - Somewhere on this learning curve you will have to stop calling 
  yourself a *non-coder*.
   - Prior knowledge of these will help, and regardless what you learn to 
   use TiddlyWiki it will include transferable skills.
  - You are not required to learn much that is single purpose, and all 
  will unleash the power of TiddlyWiki
   - In this cheatsheet the use of single square brackets indicates 
   something optional, eg; <> [params] means that is 
   optional.

❶ General wiki text (including inside macros)For additional possibilities 
with inside macros see *❸ Within macro definitions* below.
   
   1. literal values when literal values are used as parameters or 
   attributes the quoting rules apply see *➃ Using literals and parameters*
   2.   html tags imediate closure
   3.   later closure
   4. <> imediate closure, see ➀ for later 
   closure
   5. <$widgetname [params] /> imediate closure
   6. <$widgetname [params]> inside the widget  later closure 
   (for more see *➁ Content of widgets*)
   7. {{tiddlername}} transclude the content of the tiddlername's text 
   field and render
   8. {{!!fieldname}} transclude the content of the currentTiddlers 
   fieldname and render
   9. {{tiddlername!!fieldname}} transclude the content of the 
   tiddlername's fieldname and render
   10. {{{ [addprefix[$:/myprefix/]] }}} filtered 
   transclusion, see also *❻ More on filtered transclusions*
   11. Not valid in General wiki text
  1. 
  2. "",
  3. [[]]
   
❷ Widget and HTML attributes or parameters html element attributes 
, e.g. $macrocall
   
   1. <$widget attribute="literal value"/> see *➃ Using literals and 
   parameters*
   2. <$widget attribute=<>/> using a variable
   3. <$widget attribute=<>/> using a macro
   4. <$widget attribute={{transclusion}}/> using a transclusion see
   5. <$widget attribute={{{ filter }}}/> filtered transclusion ;❻
   6.  see *➃ Using literals and 
   parameters*
   7. >/> using a variable as a HTML attribute
   8. >/> using a variable as 
   a HTML attribute
   9.  using a variable as a HTML 
   attribute see more on transclusions ❻ and ❼
   10.  filtered transclusion ;❻
   11. {{!!transclusion}} a field whos value can also be inside [[ ]]
   12. *Not valid in widget attributes/parameters*
  1. <$widget attribute="prefix-<>"/> can not concatenate 
  literals and variables in a parameter
  2. <$widget attribute=[[prefix-<>]]/> can not concatenate 
  literals and variables in a parameter or treat it as a tiddler link at 
same 
  time
  3. <$widget attribute="prefix-{{transclusion}}"/> can not concatenate 
  literals and transclusions/textreferences in a parameter
   
❸ Within macro definitions*Within macro definitions refers to the following 
cases*

\define macrocname(parms) In here
\define macrocname(parms) here
and in here
\end

Keep in mind macros definitions also have full access to wiki text as 
documented in *❶ General wiki text*"Note: representations using the $ sign 
are 'substitutions' so you must provide the delimiters such as quotes with 
the substitution if required'"See footnote *➂ The value of Substitutions* for 
more,it is importiant you understand *➃ Using literals and parameters* if 
you want to use substitutions.
   
   1. $macroParameter$, "$macroParameter$", [[$macroParameter$]] 
   <<__macroParameter__>>
   2. 

[twdev] Re: [TW5 Plugin] JsonMangler v2.2.3 Released!

[TonyM]

Joshua,

Thanks so much for building on this comprehensive solution. I have not yet 
made use of it much yet, but it is very important to tiddlywiki, because it 
opens many integration possibilities.

I stumbled on https://en.wikipedia.org/wiki/WordNet and 
https://wordnet.princeton.edu/ 
which I hope to find a JSON file.

WordNet® is a large lexical database of English. Nouns, verbs, adjectives 
and adverbs are grouped into sets of cognitive synonyms (synsets), each 
expressing a distinct concept. Synsets are interlinked by means of 
conceptual-semantic and lexical relations. The resulting network of 
meaningfully related words and concepts can be navigated with the browser(link 
is external) . WordNet is also 
freely and publicly available for download 
. WordNet's structure makes it a 
useful tool for computational linguistics and natural language processing.


   - This would allow in TiddlyWiki some natural language processing or 
   even a simple thesaurus. 
   - It could be added temporarily to a wiki or permanently.
   - It could be used to find unknown relationships by relying on the 
   relationships within the language itself.
  - Eg Synonyms or antonyms verbs adverbs etc... become part of the 
  relationship and link identification from texts.
   

Thanks again.

Regards
Tony

On Sunday, 27 September 2020 09:32:12 UTC+10, Joshua Fontany wrote:
>
> This release ads two new filter operators: "comparefield[]" and 
> "compareindex[]" operators that function as "compare[]" on a specific field 
> or index. The first prefix is now the field or index name. See the help 
> documentation in the example wiki.
>
> Requires TiddlyWiki v5.1.23-pre
>
> I now have a new domain that hosts all my wiki experiments. The demo wiki 
> for this plugin is now located at: 
> https://chronicles.wiki/TW5-JsonMangler/
>
> Download the node-folders at: 
> https://github.com/joshuafontany/TW5-JsonMangler/releases/tag/v2.2.3
>
> Best,
> Joshua Fontany
>

-- 
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/5dded6f6-81d9-4cbf-ac64-6bff573377b3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

Mario,

Yes Very interesting.

Please keep this possibility alive, I agree the checklist plugin is great, 
and its very low complexity in wikitext one of its key advantages however I 
do like the ability to have a minimalist output or read only view of those 
we can build in custom wiki text


   - The Checkbox and map solutions are great.

I have published [RFC] Request for Comment and collaboration - Unique 
renamable Tiddlers and children with any name, a total Database? 

Just now, the features of which could be leveraged by custom wiki-text 
especially when looking for state and unique tiddlers;
Eg; Rather than qualify use [prefix[$:/checkboxes/]suffix[a]]... 
perhaps checkboxes against children. 

   - Which can be renamed and have additional content. ie a checkbox item 
   can become a tiddler.

This will help!


   - Especially if I get help building widget(s) that can be used within 
   custom wiki text
   - Of course if you can find the time, I would like to collaborate with 
   you (and others) on this as well.

*I will continue with the evaluation of your new releases. *

Question(s)?

   - Given "_params = class definitions" perhaps it could become _classes 
   and _map becomes _params?
  - It would be easy/clearer to say the syntax is 
  .class(s):param1:param2
   - I have experimented to see If I can introduce custom definitions in 
   the story list or view templates as I am keen to get at least a conditional 
   global customise pragma.
  - I am not concerned, too much, how we achieve this, only that we 
  document at least one method to do it, that does not demand \customise or 
  something similar in the text field.
  - Transcludeing a tiddler of definitions should work, but if this 
  could relate to a tag not unlike $:/tags/macro  
  - For example if a tiddler has object-type[book-page] bring in a set 
  of *custom wiki-text *and styles can be handled separately.
  - One day I hope to toggle custom-wiki text definitions such that one 
  can render for a screen, newsletter or PDF print layouts using the same 
  content and wikitext but alternate customise pragma.
   
*Review discovery;*

   - If I clone test-checkbox-widget-maps-transclusion and change the text 
   in one of the checkboxes, I seem to get the same state tiddler as in the 
   original (only on refresh), that state tiddler is listed by not honoured. 
  - I was wondering about checkboxes that are internal vs global, one 
  checklist could prefill another using different text marked elsewhere.
   

FYI

   - I have discovered a number of powerful techniques on top of custom 
   Wikitext I have not had the time to share yet.



Regards
Tony

On Tuesday, 29 September 2020 23:48:38 UTC+10, PMario wrote:
>
> Hi folks, 
> I did just upload V 0.5.3 that contains 3 more very powerful parameters. 
> It lets us do the following: 
>
> \customize degree=☐ _element="$macrocall" $name="check" _1=tid 
>
> \define check(src, tid) 
> <$checkbox tiddler=<> tag=done class="db"> 
> <<__src__>> 
> \end
>
> °☐:a This is a test
> °☐:b This is a test 
> °☐:c This is a test 
>
> With the "old" mechanism only 1 state tiddler would have been created. 
> With this mechanism it is possible to add 2 new parameters to the macro. eg:
>
> °☐:a .. a is the text, that will be written to the tid parameter of the 
> "check" macro. 
>
>
> It's possible to have 2 new parameters. If there are more, it gets way to 
> complicated. IMO it will be much more readable to use the existing 
> mechanism. 
>
> \customize degree=☐ _element="$macrocall" $name="check" _1=tid _2=test
>
> \define check(src, tid, test) 
> <$checkbox tiddler=<> tag=done class="db"> 
> <<__src__>> - $test$ 
> \end
>
> °☐:a:noSpacesAllowed This is a test
>
> Since this
>
> °☐:a:noSpacesAllowed This is a test
>
> may be too much clutter it is possible to define a new _maps parameter eg: 
>
> \customize degree=☐ _element="$macrocall" $name="check" _1=tid _2=test 
> _maps=":a:noSpacesAllowed"   
>
> °☐ This is a test
>
> More info can be found in the examples. .. The _maps parameter can do some 
> cool stuff. 
> See: Examples in GG 
> 
>
> Have fun!
> 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/16332238-3211-44d9-ad9a-31ea286a64b4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

TT et al,

Word of the day? "Nomenclature 
"

The easiest way I could describe it is "*Private Shorthand Supporting 
> Public Messaging*".
>
>
One advantage we have both by design and by circumstance is TiddlyWiki 
produces its results via final rendition in html. As a result whatever you 
use to generate content is a universally applicable, even copy and paste.

The tiddlywiki core plugin $:/plugins/tiddlywiki/internals lets us preview 
the output in html and copy and paste it. To me html is the public 
manifestation. How one generates this content is always up to the author. 
Tiddlywiki can provision a world of options to assist in generating it, 
from a database backend to easy to implement semi-automatic outputs. To me 
this returns us to tiddlywiki as a platform. Rather than messaging, 
although it is one way to think of it, it is publishing content.
 

> It is provision of an efficient method for supporting AUTHOR writing 
> methods. Full stop.
>
>
An author solution in tiddlywiki has three key audience groups, tiddlywiki 
enthusiasts/designers, the author and those that read the authors work. All 
however can have audiences made up of different individuals or groups with 
different end objectives. 

As many authors insist, know your audience. 

   1. If writing something for yourself, the features are all you need and 
   you can build your own Nomenclature, 
   2. if writing for authors, giving them the tools to write, is another 
   audience for which a flexible but structured solution is needed and must be 
   documented. This is where the shortcuts must be curated and a readable 
   Nomenclature is essential to assist in take up or adoption.
   3. We may be smart and use 2 to do 1
   4. The final readers (on the whole) do not care how we achieved the 
   result, only that it is readable. However readability and quality will be 
   related to the tools the author makes use of.

If my audience is ultimately for me 1 or 2 above I plan to analyse the 
elements of content of published material and provide high quality short 
cuts / html and wiki elements to generate content the final audience.

The way I plan to go about this is to look for formal standards for writing 
to identify the elements I need to provision. Normal text only such as 
novels etc... is trivial,  as a result I believe if I look at *text books, 
documentation, report writing and instruction manuals* I should be able to 
find an established set of elements for which to build a library of authors 
shortcuts. We may then alter the defaults to present the result according 
to different styles but using the same elements.

*I would appreciate community support to help identify good style and 
element guides (Especially yourself TT),* perhaps even an international 
standard from which to identify and codify the elements. I hope what we 
learn may eventually be packaged and one or more options for authors. That 
is style guides backed up by shortcuts.

Another important feature of this current project it the reformatting of 
material obtained elsewhere, a key example is quoting references and online 
content. But a key source that will only grow is tiddlywiki content.

   - Which reminds me some work has being done by academics and scientist 
   previously to build such tools already in tiddlywiki.
   - Also on books and quote collections including but not limited to our 
   Christian friends and the bible.

*Let the conversation begin (in another thread?)*

Regards
Tony

Other notes:

Guidelines for writing taxonomy for the web 

>
>
>- Mutually exclusive categories can be beneficial. If categories 
>appear several places, it's called cross-listing or polyhierarchical. The 
>hierarchy will lose its value if cross-listing appears too often. 
>Cross-listing often appears when working with ambiguous categories that 
>fits more than one place.[19] 
>
>
>
>- Having a balance between breadth and depth in the taxonomy is 
>beneficial. Too many options (breadth), will overload the users by giving 
>them too many choices. At the same time having a too narrow structure, 
> with 
>more than two or three levels to click-through, will make users frustrated 
>and might give up
>
>  
Knowledge representation and reasoning 

Ontology (information science) 

Lexicon 



 

-- 
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 

[twdev] Re: Custom markup (continued 3)

[TonyM]

Folks,

I continue researching the possibilities for these reasons

   - It is seriously exciting
   - To work with Mario and others (What a pleasure)
   - To discover the possibilities
   - To test the limits, and perhaps uncover minor tweaks that add great 
   value
   - Lastly to solve long held problems I experience with tiddlywiki

Some notes; See matching code samples

   1. customise definitions as a rule need to be at the top of the tiddler
  1. However they can also be at the top of a tiddler you transclude
  2. This effectively is a way of applying a pragma anywhere within 
  your tiddler without defining it at the top
  3. Scope is with in that only?
   2. Using set and its filter parameter and an end string, can be used to 
   gain access to an evaluated variable anywhere in the tiddler.
  1. But how would one do this for other customised items?
   
Questions

In the drop down to select our mark-up character eg degree, the "make your 
own choices" could be different for each character. This list would 
indicate the kind of use as a defacto standard, and put more customisation 
at the hands of the user, in part organised by character, like my propose 
de facto standards.

I am posting this now as google is playing games with me, I can not add 
bullets anymore...

Code samples

1. Transclude this tiddlername in a tiddler {{||tiddlername}}
\customize tick=wikify _element="$wikify" _srcName=text name=result
\customize tick=text _element="$text" _srcName=text

´text {{{ [all[current]] }}}


´wikify {{{ [all[current]] }}}

´wikify {{{ [all[current]] }}}

\customize tick=ghost _element="$set" name=ghost 
filter="""[all[current]addprefix[$:/ghost/]]""" _endString="/ghost"

2. Setting and using evaluated variables
\customize tick=ghost _element="$set" name=ghost 
filter="""[all[current]addprefix[$:/ghost/]]""" _endString="/ghost"

´ghost <>

And <> the value is here

<$set name=new-var value=<> >

My <>


I did not use the end string here! Is that a problem?
Are they "self closing"?


Tony

On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>
> Hi folks,
>
> This is the continuation of Custom markup 
>  
> [1] and Custom markup (continued) 
> and Custom 
> markup (continued 2) 
>  [2]
>
> Let's start a new one before [2] starts to use pagination. 
> Have a closer look at link [1] it's possible to show all the topics in 1 
> page
>
> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>  the above link won't 
> work anymore!
> have fun!
> 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/c46825d8-ee76-47d1-b153-9a637c4580a5o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[TonyM]

TT,

Readability in programming languages has often simply come from a body of 
work. You can write code in short or long ways. I imagin you choose 
depending on the audience.


   - For example your own shortcuts where at more others view the results 
   can be as brief as you want.
   - If however you construct something for people to learn from or 
   customise its a whole new game.
   - And when you do, you will need to document and teach so you are driven 
  to be as meaningful as possible
   - If you in fact build a library of mark-up and shortcuts for people to 
   also use then much more time is needed 
   - This is why at the end of the last topic my brainstorm for the use of 
   different symbols was around the major areas a TiddlyWiki User/Designer 
   becomes familiar with.
  - We already have a language of concepts and terms we share, so this 
  is as good a place to start from.
   
More ideas

   - Thinking about these custom pragmas and "languages" I think many of 
   the graphical, and chart solutions in tiddlywiki may benefit greatly from 
   this customisation. a set of symbols and words can be used to capture 
   appropriate primitives for writing, perhaps even the humble Railroad 
   Diagrams  and flowcharting graphics.
   - I look forward to trying this for recursive and nested solutions, 
   because this is where you can codify a concept in a word, then build the 
   response to that word. eg walk a tree, scan a list...

Regards
Tony who is well past his bedtime.



On Friday, 25 September 2020 23:15:03 UTC+10, @TiddlyTweeter wrote:
>
> @TiddlyTweeter wrote: 
>
> 1 - does the end user need to see what the author used? My guess is that 
>> they *don't.* 
>> I mean we are doing this to make WRITING easier. But most READERS won't 
>> be writers so will never need to see the markup glyphs.
>>
>  
>
>> PMario wrote: 
>> You are right, but 1 of my main goals for this project is to have the 
>> prose text as readable as possible.
>
>
> SINCE Gruber a lot has changed. What is readable for him, then was likely 
> NOT this ...
>
> °X.fred-opens-angel Fred opens the Guillemet with a degree.
>
> Is THAT "readable"? I would say it IS readable for the AUTHOR.
>
> I am using your tool for inserting text via CSS like this (each class uses 
> "::before" to insert the text)...
>
> °A.a-lonyb
> °P.p-3
> °A.o-ls-l
>
> I can read that. It is MY shorthand. Very compact. I fully understand it. 
> But it is NOT Gruber's concept of Markdown "readability".
>
> The POINT? "Readability" is actually CONTEXT dependent.
>
> I'll give a bigger example later. 
>
> Your tool actually allows shorthand easily. 
>
> It gets over some of the practical (& ideological, circa 2004) limitations 
> of existing wiki markup methods.
>
> Best wishes
> TT
>
>  
>

-- 
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/50fba97c-7d11-447d-96e3-48e624034804o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[TonyM]

Mario,

I don't think very specific id's are a problem if the result is of 
substantial utility.

I have a larger concern about the symbols which have a wider applicability, 
because I think they need to be given a default purpose, kind of defacto 
standard for each of them, to encourage some consistency. 

Without some suggested uses for each and a suitable default state even an 
individual may have a problem re-reading their mark-up later. We create 
some rules but you can always break them.

Defacto standards are just a suggestion, but deciding before deployment 
some common suggestions, will help the community build a language.

Perhaps the suggestion may be (brainstorm follows)

   - One for inline classes and formatting CSS
   - One for block classes and formatting CSS
   - One for html entities
   - One for widgets
   - One for transcluding content
   - one for list outputs (multiple items)
   - One for checkboxes

Questions?

   - What major areas of possible application can you think of?
   - Perhaps knowing the above could help us choose the characters to use?

For example >> for lists? or blocks

I have not yet attempted any inline uses, Do you have a working example yet?

Regards
Tony

On Friday, 25 September 2020 21:43:26 UTC+10, PMario wrote:
>
> On Friday, September 25, 2020 at 1:26:12 PM UTC+2, PMario wrote:
> ...
>
> Tony wanted the possibility to add more key=value _params. .. And I think 
>> it should be possible, in the _params section and calling it. eg: 
>>
>> °☐:a This is a Test
>>
>
> It should be also possible to use the Ballot Box 
>  as an ID instead of the 
> degree eg: 
>
> \customize ballot=check ... 
>
> ☐check:a This is a test
> ☐check:b This is a test
>
> Which would make it a "very very" specific ID for a special usecase. ... 
> I'll need to think about it, if that should be done. 
>
> 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/21f638a7-5034-4f57-9870-0805a6cefbbeo%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[TonyM]

TT,
 

> But, as I work with it myself I sometimes struggle with the PERMUTATIONS 
> possible.
>

This is so often the case in tiddlywiki, the customisations and 
possibilities are virtually infinite in many directions.
This is just another few dimensions of control.
 

> My main wondering is WHO is it FOR, mainly?
>

Just as for tiddlywiki, we will not know except through lived experience. 
Unlike commercial solutions we do not need to lead with a defined user or 
market. 

The most substantial features this introduces in my view is;

   - The application of wikitext or CSS to any line, not just lines 
   beginning with existing markup like * : ; # !
  - Shortcuts to apply css to any line
  - This is fixing a GAP in the current mark-up
   - The ability to build shortcuts for HTML and Widgets such that you do 
   not need to close the tag and you can pre-set attributes and parameters 
   -  
   
   - Defining your own wikitext markup using the special characters and 
   symbol provided.
   - The opportunity to address various gaps in tiddlywiki via a 
   customisation route
   - Improved sliders and details
  - Building more semantic elements
  - Interactive wikitext eg checkboxes
   

My view is that configurations will be made available to address different 
needs such as those below. 
I think this will be used in a way that macros do, people will craft and 
distribute solutions based on all or part of the customise solution.

   - An individual being able to build short cuts for themselves 
   (productivity)
   - A canned set of customisation for different users eg
  - Authors
  - Book authors
  - Blog or newsletter writers.
   - Automated website or page generation
   - Providing custom mark-up for users to use in content - almost another 
   mark-up language, where the designer sees the value.
  - Will need to be structured and documented in the solution, but the 
  designer. See my "address" post, that uses vars to supply predefines 
  variables
   - and many as yet unforeseen possibilities

Regards
Tony

-- 
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/8cb42266-862f-4a65-a9fb-bef18b665a77o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[TonyM]

Mario,

Is it not your bed time?

>
> There is a typo: you need to close the first widget element: `<$count 
> filter="[prefix[$:/state]]">` 
>
> Not really. The string   is like the _endString parameter for 
> the standard TW parser. So it doesn't need to be created. 
>

My mistake again. However the following tick is not working
\customize tick=count-filter _element="$count"  _srcName=filter

Count: <$count filter="[prefix[$:/state]]"/>

´count-filter [prefix[$:/tags/macros]]


>>- *Can I ask?,* I have not test yet but is their any reason this 
>>would be limited to widgets?, because html could also make use of the 
>>content being applied to an attribute?
>>
>> Do you have any examples, that would need it. .. There is no special 
> reason. 
>

I will explore this further and report, however;

   - I imagine it uses a very similar mechanism
   - People may assume it will work


>>- Perhaps too much to ask if there were a way to pass SOME content 
>>into the src and other as usual treated as content. 
>>   - In a dreamy state you could imagine any key=value pair in the 
>>   "content" being translated to attribute=value with every thing else 
>> placed 
>>   in the body.
>>
>> The problem is, that there is no way for the algorithm to know, if it is 
> content, or if it is key:value as parameter. 
>

Fair enough, but since we have some methods to to access various values in 
the pragma definitions, perhaps we just need to document the way to make 
use of these
Thus rather than use parameter in the content we use them in our 
definitions, 

   - I will identify and document as I go

Yea, but that is not best practice. It will hide a  element, which 
> shouldn't be used except for examples...