[twdev] Re: Custom markup (continued 2)

[TonyM]

Mario,

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

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

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

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

Perhaps the suggestion may be (brainstorm follows)

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

Questions?

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

For example >> for lists? or blocks

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

Regards
Tony

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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/21f638a7-5034-4f57-9870-0805a6cefbbeo%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Friday, September 25, 2020 at 12:42:07 PM UTC+2, @TiddlyTweeter wrote:

There are two issues in our context ...
>
> 1 - does the end user need to see what the author used? My guess is that 
> they *don't.* 
> I mean we are doing this to make WRITING easier. But most READERS won't be 
> writers so will never need to see the markup glyphs.
>

You are right, but 1 of my main goals for this project is to have the prose 
text as readable as possible.
 

> 2 - font support is a very complex issue. It is extremely difficult to 
> determine what glyphs are available visually universally (because of 
> sophisticated OS substitutions). HOWEVER, I made the point that in many 
> cases it is ONLY the author who needs to have them supported by a font.
>

Yea, it would be nice to have a 2 configuration tiddlers, that can 
initialize the IDs at wiki startup. ... I don't want to read these tiddlers 
with every occurrence of the  \customize pragma. This can considerably slow 
down this parser. 

But it would allow users to create their own IDs. 

THE downside of this approach is: It may create a new Tower of Babel.  

-mario.
PS let's use: Custom markup (continued 3) 


-- 
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/d7a101ad-a31a-44c2-9736-f7c2ce07ac88o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

On Friday, 25 September 2020 13:35:17 UTC+2, PMario wrote:
>
> On Friday, September 25, 2020 at 12:13:08 PM UTC+2, @TiddlyTweeter wrote:
>
> Can you PLEASE correct angel to angle. 
>>
>
> I knew, that someone would have a problem. But for me this looks like an 
> angel »|« , with some phantasy. 
>

A lot of phantasy since its just the one wing "»" at the moment. :-)  
Anyway it is a right-pointing guillemet.

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/b20673f6-ea43-408c-88e5-aea978cfff3bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

Hi folks,

We should go on here: Custom markup (continued 3) 


have fun!

-- 
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/d520f9b7-8c2a-41cc-844d-a65fd1039e90o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Friday, September 25, 2020 at 1:26:12 PM UTC+2, PMario wrote:
...

Tony wanted the possibility to add more key=value _params. .. And I think 
> it should be possible, in the _params section and calling it. eg: 
>
> °☐:a This is a Test
>

It should be also possible to use the Ballot Box 
 as an ID instead of the degree 
eg: 

\customize ballot=check ... 

☐check:a This is a test
☐check:b This is a test

Which would make it a "very very" specific ID for a special usecase. ... 
I'll need to think about it, if that should be done. 

mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2ff77286-b956-468c-a613-8ea1b7e0d6d9o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Friday, September 25, 2020 at 12:13:08 PM UTC+2, @TiddlyTweeter wrote:

Can you PLEASE correct angel to angle. 
>

I knew, that someone would have a problem. But for me this looks like an 
angel »|« , with some phantasy. 

I'll think about it, since there may be some "religious" concerns too. ... 
But otherwise I'd definitely keep it ;)

And we have the "almost" ID too, which can be used instead ;)

-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/66164b46-dcd6-436a-a2fd-9a7970c39120o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Friday, September 25, 2020 at 12:00:22 PM UTC+2, @TiddlyTweeter wrote:
>
> To clarify my last point about TWO configs, nasty & irritating as the idea 
> is :-(...
>
> I think it very LIKELY that PMario's Custom Markup system will be, 
> eventually, widely used by AUTEURS (originating author geeks).
>

I did have an idea, this morning. .. You know the time, where you are not 
sleeping anymore, but also not awake. ... I was thinking about a 
possibility to completely customize _every_ possible widget, that has a 
visual representation. 

It really bothered me, that the following fails, if you change the text. 

\customize degree=☐ _element="$macrocall" $name="xx" 

\define xx(src) 
<$checkbox tiddler=<<__src__>> tag=done class="db"> <<__src__>>
\end

°☐ This is a Test
°☐ This is a test 1

Tony wanted the possibility to add more key=value _params. .. And I think 
it should be possible, in the _params section and calling it. eg: 

°☐:a This is a Test
°☐:b This is a test 1    or something similar

Where "a" and "b" can be unique identifiers, that makes it possible to 
change the "This is a test" text, without loosing the state. It will also 
make it possible to use "system states", without the need for the user to 
type $:/state/xx, because they only need to type the "xx". 

 

> I am NOT convinced that a TW that uses that brilliant system should expose 
> it to every user. I think it would be a support issue of scale to do so.
>

You are right, but IMO it is a similar idea as Jeremy proposed at github: 
Implement 
wikitext shortcuts as macros 
. 
 
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/e6178c4b-5840-444a-980e-55e1868075fao%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

Ciao PMario

Right. But beyond 16 it looks like *A* character it isn't exactly that. But 
glad you'd be happy with that.

Sure there are many pairs not to use because of common usage already. That 
still leaves a lot of Unicode pairs available. There are more than I 
pointed too.

My POINT, I think, was IF we took Unicode more seriously *pairing would be 
so much easier*.

There are two issues in our context ...

1 - does the end user need to see what the author used? My guess is that 
they *don't.* 
I mean we are doing this to make WRITING easier. But most READERS won't be 
writers so will never need to see the markup glyphs.

2 - font support is a very complex issue. It is extremely difficult to 
determine what glyphs are available visually universally (because of 
sophisticated OS substitutions). HOWEVER, I made the point that in many 
cases it is ONLY the author who needs to have them supported by a font.

Thoughts 
TT

On Friday, 25 September 2020 12:20:12 UTC+2, PMario wrote:
>
> On Friday, September 25, 2020 at 11:11:56 AM UTC+2, @TiddlyTweeter wrote:
>
> Unicode does provide many *paired glyphs*, albeit some are outside the 
>> UTF-16 range. 
>> See, for instance, *some *of them: 
>> https://www.compart.com/en/unicode/mirrored
>>
>
> For javascript, it's not necessary, to use UTF-16. It can work with 
> unicode. So technically, we should be able to use any character in the 
> unicode space. 
>
> ... BUT I would need feedback, which of them make sense. The "mirrored" 
> chars are mainly math. So only very view of them can be used, without 
> creating unintended "meaning". 
>
> -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/b61051f8-2b47-4161-b992-ea7b8a94e754o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Friday, September 25, 2020 at 11:11:56 AM UTC+2, @TiddlyTweeter wrote:

Unicode does provide many *paired glyphs*, albeit some are outside the 
> UTF-16 range. 
> See, for instance, *some *of them: 
> https://www.compart.com/en/unicode/mirrored
>

For javascript, it's not necessary, to use UTF-16. It can work with 
unicode. So technically, we should be able to use any character in the 
unicode space. 

... BUT I would need feedback, which of them make sense. The "mirrored" 
chars are mainly math. So only very view of them can be used, without 
creating unintended "meaning". 

-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/a85cd6fe-a8d1-4e00-9701-fe55c44a09c3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

Ciao PMario

Can you PLEASE correct angel to angle. 

You may not realise the cognitive dissonance it causes.

In English my life partner was Angela (German, deceased), I am godfather to 
the child Angelo (Italian, male) & friend of Angelo (an Italian policeman).

Add in the generic issue that *no way is an Angel an angle*.

Please. It is confusing!
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/36cfa2a7-966e-47ca-955b-5865f05d6be0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

To clarify my last point about TWO configs, nasty & irritating as the idea 
is :-(...

I think it very LIKELY that PMario's Custom Markup system will be, 
eventually, widely used by AUTEURS (originating author geeks).

I am NOT convinced that a TW that uses that brilliant system should expose 
it to every user. I think it would be a support issue of scale to do so.

Ongoing thoughts. Just thoughts.
Best wishes
TT

On Friday, 25 September 2020 10:59:08 UTC+2, @TiddlyTweeter wrote:
>
> This for PMario & TonyM
>
> Its a thought.
>
> *TWO config modes ...*
>
> Config 1 - that adds the editing tools to enable the PMario Custom Markup 
> explicitly (i.e for any user)
>
> Config 2 - that adds the tool BUT adds NOTHING to the editor. I'm thinking 
> of cases where USER needs basic usage but NOT to ever see complexity of 
> PMario Custom Markup system.
>
> Thoughts on real utility (never add visible tools an end-user does not 
> need).
> TT
>
> On Friday, 25 September 2020 10:26:40 UTC+2, @TiddlyTweeter wrote:
>>
>> Ciao TonyM
>>
>> As ever from you an inclusive, broad reply.
>>
>> I'm actually wondering a slightly different way. Narrower. But very real. 
>> ... For instance ...
>>
>> *Does it matter if an end-user on web has the markup character in a font?*
>>
>> Personally I like to use glyphs from any of the UTF-16 doable Unicode 
>> (=Unicode “Basic Multilingual Plane”, choice of 55k plus characters). That 
>> way you can have symbols that actually have *meaning* (open, close, 
>> paragraph, section etc). I have local fonts available for that. So *I* will 
>> see them in TW (OS font substitution or explicit invoke in TW settings). A 
>> user may not; likely will not. 
>>
>> BUT, since the BESPOKE markup is mine for my use they DO NOT need to have 
>> the font for the markup character since they will NEVER edit a Tiddler in 
>> an application I build using this approach. that would be blocked. Its for 
>> reading, not editing.
>>
>> In any case it would not be compatible with providing, on-line, 
>> *editable* TW. 
>> BUT it is GOOD from point of view of author making TW for USE, not edit, 
>> by users.
>>
>> I think this comment encapsulates my point well enough?
>>
>> Regarding the OP I am wondering a bit about whether PMario's setting of 
>> the "base glyphs" to be in a "European language" font is necessary.
>>
>> Its a thought :-) I'll expand on a bit later.
>>
>> Best wishes
>> TT
>>
>>
>> TonyM wrote:
>>>
>>> TT,
>>>  
>>>
 But, as I work with it myself I sometimes struggle with the 
 PERMUTATIONS possible.

>>>
>>> This is so often the case in tiddlywiki, the customisations and 
>>> possibilities are virtually infinite in many directions.
>>> This is just another few dimensions of control.
>>>  
>>>
 My main wondering is WHO is it FOR, mainly?

>>>
>>> Just as for tiddlywiki, we will not know except through lived 
>>> experience. 
>>>
>>

-- 
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/7e09e227-ea21-4998-9d57-805f64626752o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

PMario & TonyM

Unicode does provide many *paired glyphs*, albeit some are outside the 
UTF-16 range. 
See, for instance, *some *of them: 
https://www.compart.com/en/unicode/mirrored

Best wishes
TT

On Friday, 25 September 2020 10:26:40 UTC+2, @TiddlyTweeter wrote:
>
> Ciao TonyM
>
> As ever from you an inclusive, broad reply.
>
> I'm actually wondering a slightly different way. Narrower. But very real. 
> ... For instance ...
>
> *Does it matter if an end-user on web has the markup character in a font?*
>
> Personally I like to use glyphs from any of the UTF-16 doable Unicode 
> (=Unicode “Basic Multilingual Plane”, choice of 55k plus characters). That 
> way you can have symbols that actually have *meaning* (open, close, 
> paragraph, section etc). I have local fonts available for that. So *I* will 
> see them in TW (OS font substitution or explicit invoke in TW settings). A 
> user may not; likely will not. 
>
> BUT, since the BESPOKE markup is mine for my use they DO NOT need to have 
> the font for the markup character since they will NEVER edit a Tiddler in 
> an application I build using this approach. that would be blocked. Its for 
> reading, not editing.
>
> In any case it would not be compatible with providing, on-line, *editable* 
> TW. 
> BUT it is GOOD from point of view of author making TW for USE, not edit, 
> by users.
>
> I think this comment encapsulates my point well enough?
>
> Regarding the OP I am wondering a bit about whether PMario's setting of 
> the "base glyphs" to be in a "European language" font is necessary.
>
> Its a thought :-) I'll expand on a bit later.
>
> Best wishes
> TT
>
>
> TonyM wrote:
>>
>> TT,
>>  
>>
>>> But, as I work with it myself I sometimes struggle with the PERMUTATIONS 
>>> possible.
>>>
>>
>> This is so often the case in tiddlywiki, the customisations and 
>> possibilities are virtually infinite in many directions.
>> This is just another few dimensions of control.
>>  
>>
>>> My main wondering is WHO is it FOR, mainly?
>>>
>>
>> Just as for tiddlywiki, we will not know except through lived experience. 
>>
>

-- 
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/b5b611d7-b4d7-4261-9847-320dd61e5aa7o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

This for PMario & TonyM

Its a thought.

*TWO config modes ...*

Config 1 - that adds the editing tools to enable the PMario Custom Markup 
explicitly (i.e for any user)

Config 2 - that adds the tool BUT adds NOTHING to the editor. I'm thinking 
of cases where USER needs basic usage but NOT to ever see complexity of 
PMario Custom Markup system.

Thoughts on real utility (never add visible tools an end-user does not 
need).
TT

On Friday, 25 September 2020 10:26:40 UTC+2, @TiddlyTweeter wrote:
>
> Ciao TonyM
>
> As ever from you an inclusive, broad reply.
>
> I'm actually wondering a slightly different way. Narrower. But very real. 
> ... For instance ...
>
> *Does it matter if an end-user on web has the markup character in a font?*
>
> Personally I like to use glyphs from any of the UTF-16 doable Unicode 
> (=Unicode “Basic Multilingual Plane”, choice of 55k plus characters). That 
> way you can have symbols that actually have *meaning* (open, close, 
> paragraph, section etc). I have local fonts available for that. So *I* will 
> see them in TW (OS font substitution or explicit invoke in TW settings). A 
> user may not; likely will not. 
>
> BUT, since the BESPOKE markup is mine for my use they DO NOT need to have 
> the font for the markup character since they will NEVER edit a Tiddler in 
> an application I build using this approach. that would be blocked. Its for 
> reading, not editing.
>
> In any case it would not be compatible with providing, on-line, *editable* 
> TW. 
> BUT it is GOOD from point of view of author making TW for USE, not edit, 
> by users.
>
> I think this comment encapsulates my point well enough?
>
> Regarding the OP I am wondering a bit about whether PMario's setting of 
> the "base glyphs" to be in a "European language" font is necessary.
>
> Its a thought :-) I'll expand on a bit later.
>
> Best wishes
> TT
>
>
> TonyM wrote:
>>
>> TT,
>>  
>>
>>> But, as I work with it myself I sometimes struggle with the PERMUTATIONS 
>>> possible.
>>>
>>
>> This is so often the case in tiddlywiki, the customisations and 
>> possibilities are virtually infinite in many directions.
>> This is just another few dimensions of control.
>>  
>>
>>> My main wondering is WHO is it FOR, mainly?
>>>
>>
>> Just as for tiddlywiki, we will not know except through lived experience. 
>>
>

-- 
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/29b77784-e673-490b-8096-5df9e041589do%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

Ciao TonyM

As ever from you an inclusive, broad reply.

I'm actually wondering a slightly different way. Narrower. But very real. 
... For instance ...

*Does it matter if an end-user on web has the markup character in a font?*

Personally I like to use glyphs from any of the UTF-16 doable Unicode 
(=Unicode “Basic Multilingual Plane”, choice of 55k plus characters). That 
way you can have symbols that actually have *meaning* (open, close, 
paragraph, section etc). I have local fonts available for that. So *I* will 
see them in TW (OS font substitution or explicit invoke in TW settings). A 
user may not; likely will not. 

BUT, since the BESPOKE markup is mine for my use they DO NOT need to have 
the font for the markup character since they will NEVER edit a Tiddler in 
an application I build using this approach. that would be blocked. Its for 
reading, not editing.

In any case it would not be compatible with providing, on-line, *editable* 
TW. 
BUT it is GOOD from point of view of author making TW for USE, not edit, by 
users.

I think this comment encapsulates my point well enough?

Regarding the OP I am wondering a bit about whether PMario's setting of the 
"base glyphs" to be in a "European language" font is necessary.

Its a thought :-) I'll expand on a bit later.

Best wishes
TT


TonyM wrote:
>
> TT,
>  
>
>> But, as I work with it myself I sometimes struggle with the PERMUTATIONS 
>> possible.
>>
>
> This is so often the case in tiddlywiki, the customisations and 
> possibilities are virtually infinite in many directions.
> This is just another few dimensions of control.
>  
>
>> My main wondering is WHO is it FOR, mainly?
>>
>
> Just as for tiddlywiki, we will not know except through lived experience. 
>

-- 
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/09c65ffa-b7b9-4718-807c-2016de878924o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[TonyM]

TT,
 

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

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

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

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

The most substantial features this introduces in my view is;

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

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

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

Regards
Tony

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8cb42266-862f-4a65-a9fb-bef18b665a77o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

Ciao PMario

I read through all the threadd from the start again.

*Doing that is interesting! The evolutions!*

I'm looking at it thinking "is this for MAKERS of Wikis mainly?"

It would certainly enable me to make BESPOKE solutions much more easily. 

Why? Simpler leverage of HTML & CSS. 

Your approach POTENTIATES writing base CSS & HTML end-code very efficiently 
& flexibly.

HATS OFF!

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

My main wondering is WHO is it FOR, mainly?

Just a question.
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/94a8c6b1-3f81-47ae-ba76-d5c0e4fa0b6co%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[@TiddlyTweeter]

Comments as I work on a concrete example for PMario to see.

UPSIDES

1 - I think use cases will be able to BETTER leverage the more modern 
usefully semantically supportive HTML5 elements, like ...

*nav*
*main*
*article*
*section*
*header*
*footer*


2 - open-up much EASIER use of CSS because ...

3 - ... the way that \customize works is a VERY GOOD balance between old 
and new WikiText.

DOWNSIDES

1 - Only READABILITY (in the strict Gruber [Markdown] sense) is not so 
clear. Part of the issue is CHARACTERS used in markup got EATEN already.

I could write a lot about Unicode and reliability in fonts. BUT the issue 
is this: we do NOT actually know clearly WHAT characters are available for 
use. The result is that we take from the common European code pages. I am 
NOT convinced that is ideal. But can't find any definitive solution that 
could embrace Unicode Plane One better.

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/3ef5bb8d-0490-4dec-a17a-4907bb2626c4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[TonyM]

Mario,

Is it not your bed time?

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

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

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

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


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

I will explore this further and report, however;

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


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

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

   - I will identify and document as I go

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