subject:"\[twdev\] Re\: Custom markup \(continued 3\)"


>
> I use this one, it names them nicely: 
> https://www.compart.com/en/unicode/category


That is a good Unicode resource because it honors Unicode, yet gives 
additional ways to navigate.

TT

On Monday, 26 October 2020 14:37:08 UTC+1, 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/a22d6fea-52d6-4a40-8c97-b8f395758e60o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread PMario

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/050f7a86-1a68-4410-9623-8cfa362868bdo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread PMario

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.

-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/01aabd42-5328-45ad-bcef-3b4227ee9fb1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*How Can Unicode Help?*

I, for myself, did a UNICODE exploration of PAIRED MARKUP characters. 
By "markup" I actually mean LITERAL markup characters used by workers in 
the PRINT industry. 

No Maths was added.

I also added PMario's mashup ideas. As well as stuff I know already.

Let me know IF you want me to post these!

Best wishes
TT

On Friday, 25 September 2020 13:46:32 UTC+2, 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/75b7da87-e0ee-4d25-ba46-5f46bb69f566o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao Tony

One issue with Unicode is that it identifies all "unique character" 
addressing (i.e. each character has a unique code) BUT is totally agnostic 
about how they are REPRESENTED in fonts. Font variations can give 
unexpected results.

Much of the time this is not an issue. But sometimes it is.

I DO think taking Unicode more seriously in TW is definitely a good idea. 
Frees us up from the standards of 1986 that are no longer needed. 

BUT there are several "trip-up" points along the way to be understood & 
skirted.

Best wishes
TT

On Monday, 26 October 2020 02:21:44 UTC+1, 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 
>>  
>> [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/54cfd77b-338f-424f-80fb-1406774891f7o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao TonyM

You will see on the main group I commented about ensuring FONT support for 
online TW.

In your case here you likely on safe(ish) ground.
But it would be worth checking the individual listed TW fonts to establish 
that end users can SEE them always.
BabelMap is a free Unicode/font tool to do that.

Basically we need a methodology to determine WHAT useful characters in TW 
would always be there for end users ONLINE?

We not there yet.

Best wishes
TT


On Monday, 26 October 2020 02:21:44 UTC+1, 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 
>>  
>> [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/71ab7927-04d1-43d2-b13d-d992c24be821o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread TonyM

See also Unicode discovery additional alphabets and tiddlywiki, and a 
keyboard Question 


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 
>>  
>> [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/6a7fac6a-b847-4c64-8363-4c0830156fcbo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread 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)

2020-10-25 Thread 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)

2020-10-25 Thread PMario

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/ddedbfc7-9d76-4890-83c5-087392480f03o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread PMario

On Sunday, October 25, 2020 at 1:03:50 AM UTC+2, TonyM wrote:

On saving https://wikilabs.github.io/editions/custom-markup/ locally and 
> dropping a plugin on it I get
>

Which plugin did you "drop". I can't recreate the problem. 

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/a17cd42a-2070-408d-92b7-220e611dd046o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread PMario



On Saturday, October 24, 2020 at 1:35:47 PM UTC+2, @TiddlyTweeter wrote:
>
> *Final Plea for TWO Inline markers*
>

I was thinking about that too, because underscore make much more problems 
as I thought.

-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/3bd93e13-f8fc-45c0-b96f-06cc341be245o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

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)

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)

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)


*How to dynamically change Custom Markup styling USING a Custom Markup 
launched macro  ...*

Ciao Tony

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


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/4751355e-9179-49ea-b727-a83a87da6cd6o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Plee for TWO Inline markers*

PMario wrote:
>
>
> Yes. There will be only 1 inline maker ...
>

This is my last :-) attempt to argue for TWO INLINE MARKERS.

Why?

1 - Let's take the Braille possibility. It is EXCELLENT visually as we 
already discussed. But what if you are blind?  You need Braille.
 Giving a SECOND markup syntax you can let braille writers/readers use 
Custom Markup without them having to use Braille symbols.

2 - Let's take case of complex nested markup. Having MORE THAN ONE way of 
marking up inline is MUCH MORE READABLE ... Do you want to maintain this ...

This _encloses _an enclosure

... or this? ...

This _encloses *⠒*an enclosure*⠶*__

The last version is much easier to read.

3 - It's pretty cheap to do & I think viable? So why not :-)?

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/91bea42c-b88e-4896-949b-6dbaa82cedc2o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*On Being Able To Comment Custom Markup Pragma*

This, I am sure, will help enormously on uptake.

Being able to comment pragma will help a lot! No least because Custom 
Markup is advanced use of parsing and it will often need in-context 
comments to enable end users to make best use of it.

Best wishes
TT

PMario wrote:
>
> On Friday, October 23, 2020 at 1:28:39 PM UTC+2, PMario wrote:
>
> *Pragma Comment*
>>
>> Could be
>>
>> \\ comment comes here till the end of the line
>>
>>
> We are lucky :)
>  
>
>> \\ If pragma comments are used here they are faster as used in the define 
>> block.
>> \\ This comment doesn't produce a parse-tree element!!
>>
>  
>
>> \\define test()   <- this is a comment now
>> \\ this comment is as slow as
>> \\ 
>>
> \\end  <- this is a comment now
>>
>
> Will be active in V0.7.0 ... soon !!
>

-- 
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/665b5c38-f834-4f9a-9c9a-92936a47539co%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*YES. Do use Unicode Glyphs when they have FONT support in TW!*

PMario wrote:
>
> So ⠪.class:param Braille 246 and Braille 2345⠞ may be an option. 
>
>  - So it's Braille: 246 as a start, which seems to be not used by the 
> default alphabet. 
>  - And Braille 2345, which is letter: t
>
> They will be hard to type, but can be predefined. .. 
>
> What do you think about: 25 as start: ⠒ and 2356 as stop: ⠶
>

We discussed already the very complex issue of (1) providing markup glyphs 
that WORK VISUALLY; (2) that are SUPPORTED in default TW FONT assignments. 
Matching both criterion is not easy.

Your discovery that Braiile characters  *⠒ & **⠶* would work (be supported 
by TW fonts) I think brilliant!

I think that pair is an EXCELLENT choice.

Some may complain that they are not on keyboards. But that applies to most 
every new markup character. It is simply NOT possible to support new 
characters on keyboards universally. But all we need is an Editor driven 
button / or key-combo to solve that subsidiary issue, which is easy.

So, I am very in FAVOR of *⠒ & **⠶ *solution. Mainly because it VISUALLY 
makes sense for markup (*⠒ = open & **⠶ = close*) . They are unambiguous, 
single characters, VISUALLY elegant.

Thoughts
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/af500787-baa0-41ad-939f-dfc7ff652ddbo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*On Implicit Closure (i.e. "single open with auto-closure on first \s")*

PMario wrote:
>
> It doesn't work out with a "single" start char. Way to many problems with
> TW variable names eg: _element ... if there is no `_element` definition. :/
>

That is a shame :-(.

It makes my "Shorthand Use Case" that you, PMario, understand much more
verbose than it strictly needs to be ...

So instead of "*_S.in*" I'll need to write things like "*_S.in__"*

That looks innocent till you see (for example) what it could look like in
code in bulk ...

*_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in
*

... versus ...

*_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__
**_S.in__ **_S.in__ *

In WRITING text its V. MESSY visually for my specific use case.

But I do recognize the limits you encountered in the TW extant parser you
are interfacing with.

I may have* a way round *the PROBLEM. It only occurs in writing. So a
solution is to write as I need and automate the insertion of the Custom
Markup glyphs after I have written what I want. the issue for me is ONLY in
the writing really, the code I don't really care so long as it works.

BUT I wanted you to understand and see the issue that *the more characters
you insert the harder WikiText gets to read!*

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/0e2bb343-1568-487a-acab-a17d6c4199d7o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

PMario wrote:

I was experimenting with: /° some text /° nested text °/°/
> But I personally think, that's *confusing.*


I AGREE.

If you are *manually typing *those kinds of combinations its a recipe for 
failure.

The problem is *both* visual and conceptual.

Conceptually the HTML "echo" implies that ° ... /° is most suited (i.e. 
on.-tag. off-tag).

Yet VISUALLY */° ... °/ *is much better for implying "sequester" 
(containment).

The problem will be that cognitively these two different possibles are in 
users minds and it will be VERY EASY to confuse them.

That said, IF the user is doing this through highlighting of text to span a 
button press it far less of an issue.

My thoughts
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/8034b8b2-9748-438e-b9ba-12dd1f84ad14o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*On Underscore*

__ double-underscore can be a start and - underscore slash could be stop _/  
> ??? or triple underscore ___ as stop. I personally wouldn't have a big 
> problem with those combinations. 


A few points.

1 - I AGREE that underscore is BETTER for INLINE than BLOCK. 
  Visually "_" initiates an implying that "sequestered" text (i.e. 
contained *_text bits__*)  will be styled. 
  It really is better for inline, but never blocks.

  So, IMO, (please note) I don't think it should be used for BLOCKS 
even if it is NOT used for inline (hope this is clear!)

2 - One issue is that visually in some proportional fonts (i.e. not 
mono-spaced in editor) it can get much harder to see on small screens (i.e. 
smartphones) the difference between open and closed.

3 - I'm slightly concerned it will confuse users used to the EXISTING 
method for underlining.

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/c916988e-5182-4bc6-a2ce-2c5c8d7a930do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

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)

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)

On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote:
>
> 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.
>

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.

It will be possible to change that behavior with CSS, but I don't think, 
that _mode=block makes sense for inline wikitext.

-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/d2d6ffd7-3c2c-4044-b238-891fea75ba63o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-23 Thread 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)

On Friday, October 23, 2020 at 1:06:15 PM UTC+2, PMario wrote:

Writing all the above text  I was thinking: . . . . 
>
> What about: *_symbol.class.class:param:param some text__ _ some more 
> text__*
>

hmmm. 

It doesn't work out with a "single" start char. Way to many problems with 
TW variable names eg: _element ... if there is no `_element` definition. :/

__is a probably a problem for python programmers__  ... ??

__.class:param some text__  would work well for me. ... ?? @ TT and TM

__ double-underscore can be a start and - underscore slash could be stop _/  
??? or triple underscore ___ as stop. I personally wouldn't have a big 
problem with those combinations. 

--

For everyone, which knows how to use Braille properly, ... input would be 
welcome!

I found out, that most fonts that we use by default for TW support Unicode 
Braille characters: 

So ⠪.class:param Braille 246 and Braille 2345⠞ may be an option. 

 - So it's Braille: 246 as a start, which seems to be not used by the 
default alphabet. 
 - And Braille 2345, which is letter: t

They will be hard to type, but can be predefined. .. 

What do you think about: 25 as start: ⠒ and 2356 as stop: ⠶

eg: 

⠒.x some text⠒. some nested text⠶⠶

I think I'll implement the above and this for testing.  start __  stop: 
___

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/fa563792-ffab-404d-8e5a-20a4dd18926fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Friday, October 23, 2020 at 1:28:39 PM UTC+2, PMario wrote:

*Pragma Comment*
>
> Could be
>
> \\ comment comes here till the end of the line
>
>
We are lucky :)
 

> \\ If pragma comments are used here they are faster as used in the define 
> block.
> \\ This comment doesn't produce a parse-tree element!!
>
 

> \\define test()   <- this is a comment now
> \\ this comment is as slow as
>  
>
\\end  <- this is a comment now
>

Will be active in V0.7.0 ... soon !!

-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/390848c0-9b60-4cdf-a2ca-e15906a2589eo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Friday, October 23, 2020 at 1:06:15 PM UTC+2, PMario wrote:

Writing all the above text  I was thinking: . . . . 
>
> What about: *_symbol.class.class:param:param some text__ _ some more 
> text__*
>

IF:

\customize inline="_" _element="u" ... is a default global definition it 
will do the same thing as __underline__ does now. ... 

So it should be backwards compatible but still let us do what we need. 


*Pragma Comment*

Could be

\\ comment comes here till the end of the line

If we are lucky, it may be usable like: ... BUT I'm not sure yet!!

\\\define test()
\\ your code comes here, but this definition is commented out
\\\end

-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/3878fb3c-744b-4571-bef5-3c2fae21ce43o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Thursday, October 22, 2020 at 1:53:41 PM UTC+2, @TiddlyTweeter wrote:
>
> I'm very alive on what PMario is doing. It's very, very useful.
>

I did some development, but it won't be seen. .. I did use the TW 
test-framework, to create automated tests. That's super boring but has to 
be done, otherwise it's much harder to find breaking changes. ... 

> The development of "inline markup" is of concern to me ...
>
> 1 - INLINE markup, I commented on before, that IMO we should AVOID 
> doubling. Having to type *@@textbits@@ *just to get a span is very 
> uneconomic.
>  IMO inline markup needs to be (a) the least obtrusive; (b) with the 
> least keystrokes.
>
>   I far prefer °textbits° for obvious typing a & visual readabilty 
> reasons
>

If we want to have nesting, we need to use at least 2 characters as a start 
and end sign. .. I was experimenting with: /° some text /° nested text °/°/

But I personally think, that's *confusing.*

IMO °° some text °° nested text/°/° is easier to read and understand.

The pragma will be:

\customize inline=symbol ... other params as is ... 

Yes. There will be only 1 inline maker and it should be nestable!  .. 
That's why we need to do it right!

It my be used like this:

°°symbol.class:param some text/°

The symbol allows us to use the same possibilities as the block mode. 

>
> 2 - On INLINE I also suggested that closure could be on SPACE very 
> effectively (regex: \s = space, tab or newline) so that *°textbit *could 
> work for items NOT explicitly closed.
>

At the moment *°textbit* will create an empty span. There has to be a 
closing sign. As shown above. I want to have the same possibilities as with 
block mode customisation.

*°C* is valid prose text. We can't use a single starter like this. .. We 
need the possibility for symbol.class.class.class:param:param some 
text

tick-tick ´´ is very close to backtick-backtick `` and will be confusing 
for most users. .. And we have ''bold'' which is very similar to double 
quoe " . So imo tick-tick is a _no_go. The same seems to be true for a 
single tick ... at least for me.

> 3 - Point 2 *implies *that we need TWO inline markers. One for doubling 
> (e.g. *´ **text bits/´ *). One for solo (e.g. *°textbit*)
>

It looks OK in your example, but if I use it like this: ´ text bits/´  
there is a big difference. I think it's very hard to read, for users that 
don't use monospace text in the editor.

 4 - IMO we should withdraw* ° *&* ´ * from block markup & replace them. 
> And RESERVE them for INLINE only. 
>

The initial idea was named: "dot - paragraph" ... We couldn't use the dot 
at the start of the line, because that clashes with wikitext (dynamic) 
stylesheets. We used the tick ´ instead, because it is "almost" invisible 
if you read the prose text. 

> We need glyphs SPECIFIC for inline to ensure minimalism in design.
> Those two characters are visually excellent for that job.
>

Writing all the above text  I was thinking: . . . . 

What about: *_symbol.class.class:param:param some text__ _ some more text__ 
*

I would have to make sure, that it doesn't clash with the __underline__ 
wikitext, but I think it may be possible. I personally would disable the 
"underline" wikitext to get this "inline thing" going. 

I would remove _ underscore from the block elements, because I didn't like 
it there anyway. But I think it looks good in _ inline text __. Start and 
end are easy to distinguish. ... right?

And it doesn't do too much harm if no customize plugin is installed.

I think the "underscore" character stand alone doesn't have a meaning in 
any language. ... I may be wrong here???

> I'm aware I'm giving a strong opinion to PMario as developer.
>

That's OK. ... I feel bad, that I have to say no to so many good ideas. ... 
But in one way or the other they clash with the initial idea or the 
requirements for the parser itself. 

> I think its good to be explicit when you can be.
>

That's right.

-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/68f45cc5-62b5-43a0-a658-af68f5f3d440o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread 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)

2020-10-22 Thread @TiddlyTweeter

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/22ac474f-328e-4a7f-874d-3b5533b81ed9o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread 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)

2020-10-22 Thread @TiddlyTweeter

Tony

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

I'm slightly warming to the idea.  A SERIOUS use case would be HOW to 
invoke dynamic style change via inline buttons.

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.

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/2e901a53-ddb2-43f7-8e62-404b9477a5fco%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread @TiddlyTweeter

I'm very alive on what PMario is doing. It's very, very useful.

The development of "inline markup" is of concern to me ...

1 - INLINE markup, I commented on before, that IMO we should AVOID 
doubling. Having to type *@@textbits@@ *just to get a span is very 
uneconomic.
 IMO inline markup needs to be (a) the least obtrusive; (b) with the 
least keystrokes.

  I far prefer °textbits° for obvious typing a & visual readabilty 
reasons

2 - On INLINE I also suggested that closure could be on SPACE very 
effectively (regex: \s = space, tab or newline) so that *°textbit *could 
work for items NOT explicitly closed.

3 - Point 2 *implies *that we need TWO inline markers. One for doubling 
(e.g. *´ **text bits/´ *). One for solo (e.g. *°textbit*)
4 - IMO we should withdraw *° *&* ´ * from block markup & replace them. And 
RESERVE them for INLINE only. 
We need glyphs SPECIFIC for inline to ensure minimalism in design.
Those two characters are visually excellent for that job.

I'm aware I'm giving a strong opinion to PMario as developer. I think its 
good to be explicit when you can be.

I hope this is clear. Ask if it isn't.

Best wishes
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/6875427e-0376-4e5b-9a14-edf4fcd68a58o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread 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: Custom markup (continued 3)

*--- Definitely OT --- Regarding a use case using "shorthand"*

PMario

>
> Do you have any server based setting to engage with your users? 
>
> I would go a slightly different route. Have eg: about a miniute readable 
> and for the rest you have to be logged in. ...
>

Interesting queries!

Though I have a server service I really don't want to have to code for it.

*Mainly I'm interested in how you can put your right foot behind your neck 
:-)*


IF I can get decent income from publishing my work online I'd PAY someone 
to do it for me :-)

TW is full of hobbyist system admins. But I'm not one of them :-). LOL!

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/41cb6862-020a-4fe3-9283-40b7fcf7d46do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*--- OT --- Regarding a use case using "shorthand"*
 
TT wrote ...

> Pb Ob Pbk Crl o ll at k // A1 Abk 1 L 2 R
>>
>
PMario wrote ... 

> That's very interesting. So you can read this and it makes sense to you :)
>

I DO :-).

IMO an internet that can't facilitate people who have minds already is a 
waste of time :-)

Where the net gets interesting for me is in what computers do well at: 
repetition, automation, scaling. 

I like to have a slave do grunt work :-). 

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/db0720ce-875f-407e-8fd5-9a1cf7d5a6d0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Light Relief: A sillygism (a faulty syllogism with a bit of truth)*

1. Unicode aims to support ALL written characters

2. Fonts aim to support SOME written characters

3. Documents support Fonts.

∴ (therefore) ...

SOME documents support SOME Unicode.

-- 
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/3fb7a85f-500f-44d8-9d1c-05e8df5849c1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao TonyM

THB I don't really understand what you are asking for!

The construct in Custom Markup (without a \customize pragma) for ...

´aside test

*already *produces in render ...

test

and

´aside.my-style test

produces in render

test


Likely I am missing your point!

Best wishes
TT



On Tuesday, 6 October 2020 00:49:16 UTC+2, TonyM wrote:
>
> 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/d3024a89-c6f1-4ad6-a5af-904a787789dfo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

TonyM wrote:
>
>
> I simply can't get over the power this adds to tiddlywiki. 
>

RIGHT! And Right! *But with power comes responsibility.* That is a cliche. 
But documenting the new approach I think we need to help PMario. Especially 
with examples.

TonyM previously wrote: 

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


RIGHT! See my comments at:  
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/KRj5Di3SBgAJ

And PMario's reply at: 
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/Tjd9crgpBwAJ

FWIW, I believe that what PMario has done steers a very NEAT course between 
"so open no one will master it" AND "it needs a bit of work to understand 
IF you are doing more complex layouts."

My tuppence
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/768ca2d9-5d3f-4c54-b7b6-287b9c82d03bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Should "Space, Space, Enter" be in Custom Markup too?*
 

> @TiddlyTweeter wrote:
>>
>> For readers on email in my last post prefaced *Regarding examples & 
>> WikiText "interactivity" *I deleted the last paragraph as it was 
>> misleading.
>> TT
>>
>
> PMario wrote: 

> I think it was the one with the space-space-enter, that produces a hard 
> linebreak. .. That's an effect that comes from the second plugin. 
> https://wikilabs.github.io/editions/custom-markup/#%24%3A%2Fplugins%2Fwikilabs%2Fspace-space-newline
>

AH! Got it!

Would it not be good simply to also include that in the Custom Markup 
plugin? 

Or do you think it would be confusing? 

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/db3a20c1-40aa-49fc-8a08-9d5c9b874a0bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

TonyM wrote:
>
>
> I simply can't get over the power this adds to tiddlywiki. 
>

RIGHT! And Right! *But with power comes responsibility.* That is a cliche. 
But documenting the new approach I think we need to help PMario. Especially 
with examples.

TonyM previously wrote: 

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


RIGHT! See my comments at:  
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/KRj5Di3SBgAJ

And PMario's reply at: 
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/Tjd9crgpBwAJ

FWIW, I believe that what PMario has done steers a very NEAT course between 
"so open no one will master it" AND "it needs a bit of work to understand 
IF you are doing more complex layouts."

My tuppence
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/5f911353-acfc-4050-808e-79bef39e179co%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

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)

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)

On Monday, October 5, 2020 at 11:05:20 AM UTC+2, @TiddlyTweeter wrote:
>
> For readers on email in my last post prefaced *Regarding examples & 
> WikiText "interactivity" *I deleted the last paragraph as it was 
> misleading.
> TT
>

I think it was the one with the space-space-enter, that produces a hard 
linebreak. .. That's an effect that comes from the second plugin. 
https://wikilabs.github.io/editions/custom-markup/#%24%3A%2Fplugins%2Fwikilabs%2Fspace-space-newline

space-space-enter at the end of the line is also specified in the new 
CommonMark spec. ... space-space-backslash-enter comes from me :) ... 
Sometimes I want to have a visual clue, that there are 2 spaces at the end 
of the line. 

I was also thinking about a plugin the uses: 

 - list
   - list

to produce this: 

   - list 
  - list 

I'm not really happy with 

* list
** list

Especially if there are 3 of them. 

-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/1d7881ff-eabc-47c4-a21c-81f1fd7703bao%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Monday, October 5, 2020 at 10:03:40 AM UTC+2, @TiddlyTweeter wrote:
>
> *Regarding a use case using "shorthand"*
>
> PMario wrote:
>>
>>
>> The point is, I'm completely clueless, why you write "content" with CSS? 
>> What is the purpose? Or is it just testing out the possibilities?
>>
>
> Its a good question to ask. It forces me to be explicit about it. Yeah, it 
> seems very bizarre at first. But its addressing a very specific use case. 
>
> For over a decade I have made manual SHORTHAND for lesson instructions for 
> bodywork. An example hand-written (on paper) shorthand for the start of a 
> lesson ...
>
> Pb Ob Pbk Crl o ll at k // A1 Abk 1 L 2 R
>
>
That's very interesting. So you can read this and it makes sense to you :) 
.. Nice!

PS. There is a side-effect too that is very good for me. Generated content 
> CSS can't be copied via select on screen. Since these lessons are very 
> costly to make I don't want users (or competitors) whom I don't work with 
> to be able to easily copy my work. Read fine. Copy or print, no. You have 
> to pay for that. CSS lets me make stealing lessons difficult without 
> requiring any server involvement.
>

Printing should be possible. ... But copy pasting is harder. ... 

Do you have any server based setting to engage with your users? 

I would go a slightly different route. Have eg: about a miniute readable 
and for the rest you have to be logged in. .. But you are right, this would 
need a server side. 

-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/cfb11cb5-c403-4019-b265-fa35b440d3b8o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Hi

´aside test asdf

is already possible

-- 
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/6479c286-fe4d-47bf-a126-da1dd4c84b8do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

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/855439cc-5204-4763-90e7-edd986fbb789o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote:

By the way I do nor think we shopuld say 
>
> =
>
> Since to me the tick degree etc.. is a symbol
>
>
This will be some docs changes only. I would be OK with this. 
 

> To me 
>
> =
> Would be better and note that name can be a single character, work or 
> character (the symbol).
>
>
-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/e1caf71e-06a6-42be-bd54-3b33d2160564o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

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)

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 
>>  
>> [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/8641a4ab-1b41-49bd-ac75-60a34ffe4024o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)


>
> PMario
> I was thinking about °/ some text and /°  ... Since start and end are 
> different, it should be possible to identify nesting. So 
> ›/ and /› .. may be a second option and ´/ and /´  a 3rd one. 
>
> I would like to keep °° some text °°
>

Well you are the developer :-).

TBH I don't like having TWO characters before and after. Following the 
parser you already launched would this be possible?? ... These are 
suggested defaults ...

(NOTE in the examples I am simply using degree, and single AS IF. I don't 
care if its another character ultimately.) 

*Mode 1 - Match the "word", close at space (any "\s") so ...*

This is an °example of usage.Just an example.

renders as ...

This is an example of usage. Just an example.

You add ONE character. Well good.

*Mode 2 - Match to "end-string" (pair is  › ... ‹)*

This is an › example of usage‹.Just an example.

renders as ...

This is an  example of usage.Just an example.

You add TWO characters.

Just ideas. The main thing being to have as minimal markup as possible, I 
think?

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/3246c327-9cfb-410d-8587-2a96b6671820o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

TT .. 

> I have two other simpler suggestions ...
>>
>> 1 - only have ONE character not two ... using @@ or °° is nowhere near as 
>> readable as @ ° alone. *Markup in-line should be the most readable and 
>> the most minimal *because that is where reading happens most.
>>
>
PMario ... 

> That's right. If we find the right "start" and "end" markers we could do 1 
> character as a marker. ... But 1 ° char seems to be valid plain text for 
> me. eg: 20°C ... should not start something special. ... 20 °C ... the ID 
> would be ° (degree) and the symbol would be "C". .. But that's probably not 
> intended. .. 
>

Right. Degree is used by mathematicians, for navigation, for temperatures 
etc ... So one needs an alternative ID :-) for users who use it a lot & 
where an occasional *""* won't be enough :-). 

Wher as °°C.class.class:param is a possible marker, that the parser can 
> identify. Especially if the inline mode starts a the beginning of the line. 
>
> °C will clash with the existing parser
>

Right. My concern here is a broader issue. 

Do you think its a good idea to use the same ID characters for inline as 
occur for block (i.e. single charter at line start) mode?

Would it not be better they were totally different?

Thoughts
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/26be8e0a-cd4e-45fd-854f-612f8ac8ca91o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

--- Largely OT 
 

> PMario ...
>
 

> The middle dot is very similar to the "Mediopunkt" in German "Leichte 
> Sprache" rule-set. So we can't really use it. "Leichte Sprache" and 
> "Einfache Sprache" are a "big thing" at the moment.  
>

Ha! I had a quick look at https://en.wikipedia.org/wiki/Leichte_Sprache. 
Most interesting.

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/c326f456-f4f1-49e2-8e8b-01e6a4bc55a3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Monday, October 5, 2020 at 11:34:48 AM UTC+2, @TiddlyTweeter wrote:

I was suggesting tentatively that there be two ID's for inline markup ...
>
> degree "°" (entity = )
>
>
> and another ... (I can help you find one :-) maybe ...
>

I was thinking about °/ some text and /°  ... Since start and end are 
different, it should be possible to identify nesting. So 

›/ and /› .. may be a second option and ´/ and /´  a 3rd one. 

I would like to keep °° some text °°, because I like it more than °/  ... 
(I would name this: °/ ... left eye and this: /° right eye .. And this 
looks like a face (°/°) )

>
> middle dot "·" (entity = )
>
>
> I'll explain in a later post why I think 2 IDs may be a good idea. 
>

The middle dot is very similar to the "Mediopunkt" in German "Leichte 
Sprache" rule-set. So we can't really use it. "Leichte Sprache" and 
"Einfache Sprache" are a "big thing" at the moment.  

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/617487b4-28a1-43e3-9564-6a4eb96024f7o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)


*Discussing putative inline IDs *

> @TiddlyTweeter wrote:
>  
>
>> 2 - ADD a second ID, maybe aimed at paired use by default?
>>
>  
>
PMario .. 

> Not sure, what you mean here.
>

I was suggesting tentatively that there be two ID's for inline markup ...

degree "°" (entity = )


and another ... (I can help you find one :-) maybe ...

middle dot "·" (entity = )


I'll explain in a later post why I think 2 IDs may be a good idea. 

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/1477abaf-5f4a-4e98-8df6-ead30ec52f52o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

For readers on email in my last post prefaced *Regarding examples & 
WikiText "interactivity" *I deleted the last paragraph as it was misleading.
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/b0f5252b-9bd1-4f27-9f67-0af35603f715o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Regarding examples & WikiText "interactivity"*

TT wrote:
>
>
>> These can variously interact under nesting. They can also change existing 
>> WikiText behaviors on line-spacing (when its nested inside some custom 
>> constructs) in a way that can be confusing at first.  Now I understand it 
>> much better. When you understand how it works its ROBUST and you can do 
>> pretty amazing things very elegantly & efficiently.
>>
>
> Yea, there is still some problems, with the TW core parser, that 
> introduces P tags, where they shouldn't be. .. I think there is no real way 
> to work around this. :/
>  
>
>> My point? I think we need to try help PMario document it. 
>>
>
> PMario 

> That's a good idea. Especially documented examples will be helpful. ... 
>

Hopefully I can give you one or two in time.

> In particular we currently lack a brief summary that indicates the 
>> "interactivity" that totally confused me at first.
>>
>
> What do you mean by "interactivity"
>

I mean only what can happen, especially under nesting, with WikiText & 
Custom Markup.

I think the bigger point I was trying to get at is that Custom Markup makes 
much, much easier vastly more sophisticated use of HTML & CSS using a neat 
compact method.
Along with that comes, I think, much higher chances users will trigger 
cases where the layout seems to go all wrong :-). 
So greater clarity of how parsing works is likely going to be needed if a 
user wants to do more advanced work.

A simple example is the current behaviour of adding two spaces at the end 
of a line with some WikiText.
I only just realised that two spaces at the end of a line inserts a * **I 
never grasped that before!*
SO, I think that some aspects of existing WikiText might also need a bit of 
clearer documentation?
Yes?

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/914cd487-c8f3-419a-8a57-18258a7c9322o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Users on email please note that in my last post prefaced *Regarding a use 
case using "shorthand" *I added a PS at the end reading ...

PS. There is a side-effect too that is very good for me. Generated content 
CSS can't be copied via select on screen. Since these lessons are very 
costly to make I don't want users (or competitors) whom I don't work with 
to be able to easily copy my work. Read fine. Copy or print, no. You have 
to pay for that. CSS lets me make stealing lessons difficult without 
requiring any server involvement.

-- 
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/5af953f6-c584-4fda-bc0f-3ccc73123e01o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Regarding a use case using "shorthand"

PMario wrote:
>
>
> The point is, I'm completely clueless, why you write "content" with CSS? 
> What is the purpose? Or is it just testing out the possibilities?
>

Its a good question to ask. It forces me to be explicit about it. Yeah, it 
seems very bizarre at first. But its addressing a very specific use case. 

For over a decade I have made manual SHORTHAND for lesson instructions for 
bodywork. An example hand-written (on paper) shorthand for the start of a 
lesson ...

Pb Ob Pbk Crl o ll at k // A1 Abk 1 L 2 R

These are instructions in a class I give voice to like this ...

Lay down on your back. Observe how you lay on the ground  bend your knees. Cross your right leg over your left ... 
etc

A whole lesson is written on ONE A6 card. 
Transcribed a lesson would be 4-6 pages of A4.

I now want to put online some of these lessons (demand from students). 
Since *hundreds of phrases are repeated i*n different lessons I want to 
avoid having to write those for each lesson. That is the background. Hope 
that makes clearer the issue!

I have done some experiments already in TW using transclusion (each 
sub-phrase a tiddler). It works, but (1) the styling (I need to hide/show 
parts of lessons) gets very complicated to manage; (2) its a barely 
readable forest of *{{...}}.*

NOW I'm experimenting with your Custom Markup and the results so far look 
very good. In fact it looks like I might be able to use a slightly modified 
version my existing shorthand system (mixed with typed text). So, for 
example ...

°Pb.-pos °Ob °.pbk IC.rl °.o °.ll It is important at  °.at °K // °.a-1 
°a-bk Rest, then °.L2r 

YES, its an experiment. But a well advanced one that looks very hopeful. 
Once setup it seems very effective!

I think its an interesting use case of efficient utilization of CSS. 

I may actually use it! :-)

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/f4b71668-5164-4f2b-82e1-758f938a2335o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

I was about to post a note on in-lining :-)

I'll update first. A dopo.

TT

On Sunday, 4 October 2020 14:23:33 UTC+2, 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/1e1f117e-f134-4bbc-b9b7-fa3d556dc69bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Regarding fonts ...*

 @TiddlyTweeter wrote:
>  
>
>> 2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed 
>> this. 
>> Its not an issue on the 6 IDs, at least not for European languages. 
>>
>> But it *is an issue if you want to use Unicode characters in \customize 
>> pragma*.
>>
>  

>
>> My point for TW? I'm wondering IF, we could assemble a *custom font *of 
>> say 100 Unicode *typographic *signs (e.g. punctuation marks, markup 
>> symbols, reference signs etc)  and *EMBED* this in a TW?
>>
>
>
PMario ... 

> I'm not the biggest fan of embedded fonts, because of size. ... BUT it 
> will be possible with a second plugin, so users can decide.
>

I agree for complete fonts. I should look at *how big a font of, say, 100 
characters is?*



I personally would install the font. 
>

On computer? Yes. But I'm just wondering if a more TW-centric approach 
would be viable too? (i.e. the embed route, IF font of limited character 
set is small enough?)
 

>  
>
>> Q: Is it possible? Your thoughts?
>>
>  

> I would even consider to create a browser AddOn, that will make the font 
> available for TWs, if users don't want to install new system fonts. 
> I'm not sure if this is possible, but it would be worth a test. 
>

That's encouraging! I had thought it would be very difficult.  

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/691478a9-fcca-40bd-8ddb-726554480aceo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

PMario wrote:
>
>
> Yea, there is still some problems, with the TW core parser, that 
> introduces P tags, where they shouldn't be. .. I think there is no real way 
> to work around this. :/
>

Right. I noticed that. I also noticed you can suppress that behavior. 
Though I haven't quite pinned down how and where you can. But, for 
instance, if you start a tiddler ** you get ...




But if you start it *»article* you get ...




Just a comment.

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/83cc061e-8282-41e0-b695-e3a5cab0d4e3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread 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: Custom markup (continued 3)

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/4357be03-4267-439d-a443-3897b5728588o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Saturday, October 3, 2020 at 10:18:14 AM UTC+2, @TiddlyTweeter wrote:
>
> Ciao PMario & all
>
> I been doing a lot of testing of using Custom Markup for layouts and 
> precision CSS application. It is VERY good. 
>
> A number of issues came up. I will post about each separately. First I 
> comment about Editor Look & Keys, then Fonts & Unicode.
>
> I did testing on English Win7 (DT), Italian Win10 (tablet) & Android6 
> (standard phone) computers.
>
> *1 - EDITOR LOOK & SETUP*
>
> *Key Availability *- It became clear quickly that whilst all three system 
> tested on have Font Support they all differ in native Keyboard Support. 
> *None has all 6 IDs available easily on keys.*
> This just confirms what we said before: *the tool requires buttons, 
> keyboard shortcuts and likely (for boilerplate WikiText) stamp tool use.*
>
> The approach PMario took to deal with this via buttons & key shortcuts 
> works well... 
> but ...
>

OK

*Too Many Buttons? - **I think there may be too many buttons :-). *For 
> instance are the buttons that just *remove *an ID needed at all?
> What is primary is to be able to insert IDs, which it does. 
> But I don't see added value (myself) to remove them where a single 
> "delete" stroke does it anyway!
>

With the default configuration, there will only be 2 buttons. Remove 
"angle" and Add "angle" ... To deal with paragraphs. 

The rest will be activated by the users, if they want them. 

 

> *Button Pictures - *This is ONLY an aesthetics comment; but why not just 
> have a *picture of the single ID* on a button and no more?
> Visually I think they are over-noisy. 
>

right! 

At the beginning, they where very similar to the "Apply bulleted list" 
buttons, but the icons where to small, to be seen, so I reduced them to 2 
lines instead of 3. .. BUT you are right. Now they are already different, 
so we can simplify them.

I'll have a closer look. 
 

> 2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed 
> this. 
> Its not an issue on the 6 IDs, at least not for European languages. 
>
> But it *is an issue if you want to use Unicode characters in \customize 
> pragma*.
>
 

> I tried to pin down some RELIABLE (typographic) characters available 
> through Unicode (i.e. that have "universal" font support).
> This is not an easy thing to do. Font substitution behavior of OS' systems 
> (a pretty amazing process BTW) that create "composite" fonts on the fly, 
> using available fonts on the computer can make it near impossible to 
> predict (1) glyphs that will appear in other people's TW; (2) what they 
> will look like (e.g. sometimes coloured, sometimes not, sometimes visually 
> very different).
>
> This is obviously NOT directly a TW issue. But it made me wonder whether 
> in fact we (the whole internet) are seriously under-using Unicode that 
> would make life much easier---and not just to better support Custom Markup.
>
> My point for TW? I'm wondering IF, we could assemble a *custom font *of 
> say 100 Unicode *typographic *signs (e.g. punctuation marks, markup 
> symbols, reference signs etc)  and *EMBED* this in a TW?
>

I'm not the biggest fan of embedded fonts, because of size. ... BUT it will 
be possible with a second plugin, so users can decide.
 

> I don't know how you'd embed it or access the font. But I know how to make 
> such a font set.
>

I personally would install the font. 
 

> Q: Is it possible? Your thoughts?
>

I would even consider to create a browser AddOn, that will make the font 
available for TWs, if users don't want to install new system fonts. 
I'm not sure if this is possible, but it would be worth a test. 

-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/49ad2f66-387b-4bcd-9ee1-9addaf05c939o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Saturday, October 3, 2020 at 10:56:44 AM UTC+2, @TiddlyTweeter wrote:
>
> Ciao PMario
>
> *A CONFESSION -* Using Custom Markup at first was very confusing for me!
> As soon as I started to do anything other than simple the layout would 
> break.
> *This is because of Custom Markup's richness. Because it can do a lot a 
> lot of different ways.*
>
> There are several dimensions which behave differently according to ID or 
> \customize settings ... In my own way of thinking you have ...
>
> *Scope Match of three types* (expressed in pseudo-regex) ...
>
>1. ^ID ... \n (for 4 IDs)
>2. ^ID ... \n\n (for 2 IDs)
>3. ^_endString (overrides default scope 1 & 2 in \customize)
>
> Yes. The _endString basically makes them the same! 
 

> *\customize Flow Setting of two types*
>
>1. _mode="inline" (default)
>2. _mode="block"
>
> That's the same behaviour, like the TW core parser. 
 

> These can variously interact under nesting. They can also change existing 
> WikiText behaviors on line-spacing (when its nested inside some custom 
> constructs) in a way that can be confusing at first.  Now I understand it 
> much better. When you understand how it works its ROBUST and you can do 
> pretty amazing things very elegantly & efficiently.
>

Yea, there is still some problems, with the TW core parser, that introduces 
P tags, where they shouldn't be. .. I think there is no real way to work 
around this. :/
 

> My point? I think we need to try help PMario document it. 
>

That's a good idea. Especially documented examples will be helpful. ... 

I did improve the _debug and \debugcustomize commands quite a bit. ... The 
can be also used for documentation now. ... 
 

> In particular we currently lack a brief summary that indicates the 
> "interactivity" that totally confused me at first.
>

What do you mean by "interactivity"

-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/8857a9f8-5e7b-41d1-bf0a-472a219a5fb7o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Saturday, October 3, 2020 at 11:56:54 AM UTC+2, @TiddlyTweeter wrote:
>
> Ciao PMario
>
> *Is Six ID's Enough? YES.*
>
> In practical use I think its a good number.
>
> - Good balance between strict TECHNICAL NEED to make it work (i.e. 2) and 
> ..
> - ... VISUAL VARIANCE to make typing variant markup a good experience.
>
> In my tests I used all 6. 2 extensively. 2 moderately. 2 for special cases.
> That number is well supporting of even complex markup.
>
> I would cap it at 6. More, I think, would be visually redundant.
>

Yea, .. I do think so too. ... In reality with 1 ID you also have the 
 character / name. So the possibilities are almost endless. 

I also wanted to use IDs, that should be available with different keyboard 
layouts. So depending on the keyboard layout there should be at least 1 or 
2 IDs available, that are easy to type. 

BUT we will see, once I introduce the plugin in the main group.

-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/3359d20e-c702-4230-afdc-f9345d2ba79co%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Sunday, October 4, 2020 at 8:42:31 AM UTC+2, @TiddlyTweeter wrote:

Its actually very complex so I've made a simplified single tiddler example 
> containing the \customize, markup example and style block for you to see.
> I hope that will help.The example attached is for using the markup in 
> BLOCK mode I already have working well. 
>

I did fall in my own trap. I had to rename _params to _classes, to see the 
style definitions :)

The point is, I'm completely clueless, why you write "content" with CSS? 
What is the purpose? Or is it just testing out the possibilities?
 

> In a post later today I'll try to make clearer the issues in INLINE mode I 
> was trying to explain.
>

OK

-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/760539ab-6780-4350-8d71-58fc604194f1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

On Sunday, October 4, 2020 at 8:42:31 AM UTC+2, @TiddlyTweeter wrote:
>
> PMario wrote:
>>
>> Interesting, but without the actual configuration it's really hard for me 
>> to see, what it should do. 
>
> .. Can you export your setting and attach a tiddlers.json, so I can see it?
>
>
> Its actually very complex so I've made a simplified single tiddler example 
> containing the \customize, markup example and style block for you to see.
> I hope that will help.The example attached is for using the markup in 
> BLOCK mode I already have working well. 
>
> In a post later today I'll try to make clearer the issues in INLINE mode I 
> was trying to explain.
>
> Many thanks for your patience!
>

I need the customize pragma definitions?!
-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/080ccc8f-a28a-459d-91c4-51824d79349ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread @TiddlyTweeter

PMario ...
 

>  I'll publish V0.6.0 with some incompatible changes on Sunday. ... We will 
> get global pragma rules, _parms -> _classes,  _maps -> _params ... angel -> 
> angle ;)


Noted! Global pragma rules will be brilliant for my use case. Thanks angel 
for the angle :-).

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/a2948582-7cc7-4bbd-9ea6-b68f32be29c2o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread @TiddlyTweeter

PMario wrote:
>
> Interesting, but without the actual configuration it's really hard for me 
> to see, what it should do. 

.. Can you export your setting and attach a tiddlers.json, so I can see it?

Its actually very complex so I've made a simplified single tiddler example 
containing the \customize, markup example and style block for you to see.
I hope that will help.The example attached is for using the markup in BLOCK 
mode I already have working well. 

In a post later today I'll try to make clearer the issues in INLINE mode I 
was trying to explain.

Many thanks for your patience!

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/576757a5-e0c3-4c73-b754-e41fcdda68cfo%40googlegroups.com.

TT-block-version-test.json
Description: application/json

[twdev] Re: Custom markup (continued 3)

2020-10-03 Thread PMario

On Saturday, October 3, 2020 at 12:57:31 PM UTC+2, @TiddlyTweeter wrote:

*Comments on INLINE markup.*
>
> At the moment I'm writing markup like this ...
>
>  »§
>   ›¶ `›¶` Example single line for SA phrase groups. Won't fully work till 
> custom-inline is finished. ([[TT Notes]])
>   »¶
>°O `»¶ ... ⁋` Example mutli-line block for SA phrase groups. 
>°O Good morning. Welcome to another 
>›ABsa 
>°O ... So, let's start ... 
>   ⁋
>   »¶
>°P.p-b-v 
>°O Observe how your body lays on the ground. What touches clearly. What 
> doesn't. 
>   ⁋
>   »¶
>
>°A.p-b-v
>°O Observe how your body lays on the ground etc ...
>°O
>   ⁋
>  §«
>
>
Interesting, but without the actual configuration it's really hard for me 
to see, what it should do. .. Can you export your setting and attach a 
tiddlers.json, so I can see it?
 

> each ° inserts a  into a paragraph (»¶ ... ⁋). I'm doing it this 
> way because at the moment to do it inline would make it (1) FAR LESS 
> READABLE  see below ...
> and I also want to insert (2) NON-SPAN inline elements easily like  ›ABsa and 
> (3) sometimes NEST elements.
>
>   »¶ °°.p-b-v°°   °°.o-ktl°° Now, observe how your body lays on the 
> ground, particularly °°.p-d.g-l°°   In this °°AB.sa°° movements are based 
> on "°°REF.r-jen.v°°143-9". 
>
> You mentioned before that the current inline parser need uses matched 
> pairs. 
> But *the pairs are identical *so inline NESTING becomes impossible.
>

That's right. I didn't do work on the inline settings yet. ... But it 
should be possible to define the _endInline string similar to the existing 
configs. 
 

> I had a thought (horror!) :-) In block parser for Custom Markup you 
> basically leverage off LINE SPACING
>
 

> I'm wondering IF the use of SPACE INLINE use could work give the leverage 
> needed (regex °\S* ). IF so MY case above would become ...
>
>   »¶ °.p-b-v   °.o-ktl Now, observe how your body lays on the ground, 
> particularly °.p-d.g-l   In this °AB.sa movements are based on 
> "°REF.r-jen.v 143-9". 
>

Interesting idea, but "spaces" are really hard to see ;) .. or to judge, 
how many of them are actually used. ... It needs some experimenting with 
the parser and the regexp's. ... 
 

> ... Now you gonna say that would ONLY match words ... so for anything 
> other than a word (string of chars that are not spaces) you use a closure.
> Let's pretend ... its /°
>
>   »¶ °.p-b-v   °.o-ktl Now, observe how your °.o-h body lays on the 
> ground/°, particularly °.p-d.g-l   In this °AB.sa movements are based on 
> "°REF.r-jen.v 
> 143-9/°". 
>
> Hope this is clear! I'm wondering if this approach is possible??
>

Not really sure what you want to get. I'd need the html + the text, that 
should be produced. So I can see, where your _endInline should be in the 
text. 
 

> I have two other simpler suggestions ...
>
> 1 - only have ONE character not two ... using @@ or °° is nowhere near as 
> readable as @ ° alone. *Markup in-line should be the most readable and 
> the most minimal *because that is where reading happens most.
>

That's right. If we find the right "start" and "end" markers we could do 1 
character as a marker. ... But 1 ° char seems to be valid plain text for 
me. eg: 20°C ... should not start something special. ... 20 °C ... the ID 
would be ° (degree) and the symbol would be "C". .. But that's probably not 
intended. .. 

Wher as °°C.class.class:param is a possible marker, that the parser can 
identify. Especially if the inline mode starts a the beginning of the line. 

°C will clash with the existing parser
 

> 2 - ADD a second ID, maybe aimed at paired use by default?
>
 
Not sure, what you mean here.

-mario

PS: I'll publish V0.6.0 with some incompatible changes on Sunday. ... We 
will get global pragma rules, _parms -> _classes,  _maps -> _params ... 
angel -> angle ;)

-- 
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/ccd43a55-68aa-4250-8545-3fb6ad191882o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*Comments on INLINE markup.*

At the moment I'm writing markup like this ...

»§
›¶ `›¶` Example single line for SA phrase groups. Won't fully work till
custom-inline is finished. ([[TT Notes]])
»¶
°O `»¶ ... ⁋` Example mutli-line block for SA phrase groups.
°O Good morning. Welcome to another
›ABsa
°O ... So, let's start ...
⁋
»¶
°P.p-b-v
°O Observe how your body lays on the ground. What touches clearly. What
doesn't.
⁋
»¶

°A.p-b-v
°O Observe how your body lays on the ground etc ...
°O
⁋
§«

each ° inserts a into a paragraph (»¶ ... ⁋). I'm doing it this way
because at the moment to do it inline would make it (1) FAR LESS READABLE
see below ...
and I also want to insert (2) NON-SPAN inline elements easily like ›ABsa and
(3) sometimes NEST elements.

»¶ °°.p-b-v°° °°.o-ktl°° Now, observe how your body lays on the ground,
particularly °°.p-d.g-l°° In this °°AB.sa°° movements are based on
"°°REF.r-jen.v°°143-9".

You mentioned before that the current inline parser need uses matched
pairs.
But *the pairs are identical *so inline NESTING becomes impossible.

I had a thought (horror!) :-) In block parser for Custom Markup you
basically leverage off LINE SPACING.

I'm wondering IF the use of SPACE INLINE use could work give the leverage
needed (regex °\S* ). IF so MY case above would become ...

»¶ °.p-b-v °.o-ktl Now, observe how your body lays on the ground,
particularly °.p-d.g-l In this °AB.sa movements are based on
"°REF.r-jen.v 143-9".

... Now you gonna say that would ONLY match words ... so for anything other
than a word (string of chars that are not spaces) you use a closure.
Let's pretend ... its /°

»¶ °.p-b-v °.o-ktl Now, observe how your °.o-h body lays on the
ground/°, particularly °.p-d.g-l In this °AB.sa movements are based on
"°REF.r-jen.v
143-9/°".

Hope this is clear! I'm wondering if this approach is possible??

I have two other simpler suggestions ...

1 - only have ONE character not two ... using @@ or °° is nowhere near as
readable as @ ° alone. *Markup in-line should be the most readable and the
most minimal *because that is where reading happens most.
2 - ADD a second ID, maybe aimed at paired use by default?

Very 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/cd7d49ab-1ef6-41b5-915d-cd03f1f5e52fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*Is Six ID's Enough? YES.*

In practical use I think its a good number.

- Good balance between strict TECHNICAL NEED to make it work (i.e. 2) and ..
- ... VISUAL VARIANCE to make typing variant markup a good experience.

In my tests I used all 6. 2 extensively. 2 moderately. 2 for special cases.
That number is well supporting of even complex markup.

I would cap it at 6. More, I think, would be visually redundant.

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/29060e65-7ff1-46e7-9ec3-fc44a96b839do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*A CONFESSION -* Using Custom Markup at first was very confusing for me!
As soon as I started to do anything other than simple the layout would
break.
*This is because of Custom Markup's richness. Because it can do a lot a lot
of different ways.*

There are several dimensions which behave differently according to ID or
\customize settings ... In my own way of thinking you have ...

*Scope Match of three types* (expressed in pseudo-regex) ...

1. ^ID ... \n (for 4 IDs)
2. ^ID ... \n\n (for 2 IDs)
3. ^_endString (overrides default scope 1 & 2 in \customize)

*\customize Flow Setting of two types*

1. _mode="inline" (default)
2. _mode="block"

These can variously interact under nesting. They can also change existing
WikiText behaviors on line-spacing (when its nested inside some custom
constructs) in a way that can be confusing at first. Now I understand it
much better. When you understand how it works its ROBUST and you can do
pretty amazing things very elegantly & efficiently.

My point? I think we need to try help PMario document it.
In particular we currently lack a brief summary that indicates the
"interactivity" that totally confused me at first.

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/223e83b5-5ec4-4756-8146-fcebf4207b11o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)