[twdev] empty.html should start with "fluid-fixed" layout

[PMario]

Hi folks, 

I did just create a PR, that sets the default layout of empty.html to: 
fluid-fixed

See: https://github.com/Jermolene/TiddlyWiki5/pull/5492

Please vote +1 if you think it should be merged!

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/67846d53-4c3f-460a-b197-106454afb425n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi Folks,

We continue at: https://github.com/wikilabs/plugins/discussions/56

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/a1093ef9-aef8-47e6-b89e-20b9669a555bn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Wednesday, December 9, 2020 at 4:58:35 AM UTC+1 TonyM wrote:

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

If a font is about 1 MByte I'd add it to my PC, but in now way I would want 
to add it to my wiki. I'm thinking about something in the 10th of kiloBytes 
up to 100+kByte, that is acceptable. 

-mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/99a912a0-cc89-475b-88b8-cfb2af55a8d7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Tuesday, December 1, 2020 at 6:42:53 PM UTC+1 @TiddlyTweeter wrote:

*...* It would be *a very minimal font embedded in TW for JUST markup 
> glyphs. It would be kilobytes, not megabytes*. To get to the point of 
> proof-of-concept I need some days yet, but I'm getting close. Its just 
> trudge over the Unicode BMP to establish which fonts would provide the 
> glyphs needed, cost free, to make a good "TW-MarkupGlyphsFont".


If that would be available I'd be happy to test it. I'd install it directly 
on my PCs, to keep up with performance. ... But there are possibilities to 
add them with CSS too. So it should be simple to create a new plugin, that 
would provide this function. 

-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/89c69b8f-031d-432c-9714-84304a04fbefn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, November 28, 2020 at 6:44:01 PM UTC+1 codacoder...@outlook.com 
wrote:

*Scoping rules*
> What is the scope of \somepragma? Is it possible to globally define them 
> easily? I feel like I'm missing something obvious here. Wondering if 
> $:/tags/Macro might do the job - it shouldn't but I'd understand if it did.
>

The scope is "per tiddler" .. but see: 
https://wikilabs.github.io/editions/custom-markup/#Global%20Pragma%20Definitions:%5B%5BGlobal%20Pragma%20Definitions%5D%5D%20global-pragma-definition%20global-macro-definition

AND

Search for "global" at: https://wikilabs.github.io/editions/custom-markup 

-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/0b601810-f6b4-4126-9e92-6bcba6f21440n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Sunday, November 29, 2020 at 2:13:53 AM UTC+1 TonyM wrote:

> CodaCode
>
> Nice to see someone else buying into the vision.
>
 
+1
 

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

Right. See the right sidebar: Contents !! .. There is a little bit of docs 
already. 


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

I'd second that. The definitions should be as understandable as possible. 
 

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

Right. Have a closer look at the "test-" prefixed tiddlers. I use them to 
test the different versions, to see if something is broken. ... The problem 
is, extending the code sometimes it's intended to be broken. Which makes it 
a bit difficult atm. 

The "content" tab in the right sidebar will hold the docs in the future. 

 The "special toolbar" and keyboard shortcuts are kind of broken atm. 
... I'll need to fix it. ... but atm core TiddlyWiki is super busy and I 
need the new actions functions for radio-buttons for this project !!!

-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/1c647d8a-0bde-4a9e-903e-c775a21a2c7en%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Thursday, November 26, 2020 at 11:17:50 AM UTC+1 @TiddlyTweeter wrote:

> *BUG? v.0.8.1 -- Block Nesting Broken?*
>

Try: 

\\ CUSTOM POETRY 
\\ -- container - 
\customize angle=POEM _element="div" _endString="/POEM" _mode=block 
_classes=".poem-c"
\\ -- components --- \\
\customize single=P-H _element="h3"
\customize pilcrow=P-B _element="div" _endString="/P-B" _mode=block


»POEM

  ›P-H JABBERWOCKY

  ¶P-B ´Twas brillig, and the slithy toves
  Did gyre and gimble in the wabe:
All mimsy were the borogoves,
  And the mome raths outgrabe.
  /P-B

/POEM

See _mode=block !!

-- 
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/d93f8cf2-b879-436a-b681-18992bbd6ee6n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Sorry for the late reply. ... I Wasn't aware, that I can only see, if 
something is going on, if I change the group :/

On Wednesday, November 18, 2020 at 11:48:23 PM UTC+1 TonyM wrote:
...

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

Hi folks, 
Interesting discussion. I did implement the different glyphs, for 
experimentation, so we can see how it works out. My conclusion atm is: That 
it creates way more problems, as it solves. .. Really! I don't want to 
explain, that users need a special font. .. It has to work out of the box. 

At the moment we have:

   - There are 4 "inline" elements
  - __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
   - There are 6 "block" elements
  - pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
   
I did play around with "braille" a little bit and for me it is _not_ 
visible enough in plain text. ... So I'm inclined to remove it for the 
initial (beta) release. ... 

I do like "underscore" because it's easy to see in plain text, but it needs 
more internal code :/.

"little" causes unicode problems. ... I'd like to remove it.

So I may end up with "underscore" and "slash". They don't cause unicode 
problems and are present on every keyboard. 

---

I'm inclined to stick with the block elements for the initial release. 



My main point is, that I don't what to deal with the unicode support 
problems. The advanced usecase of the plugin is difficult enough to 
explain. 

just some thoughts. 
-mario


-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/7ac5056e-5afa-43ae-8154-86e1136b355an%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi,

I did a bit more docs for table formatting. So there are the same 
formatting options as available with standard wikitext. 
The only problem is, to find good "start" and "end" symbols, to make the 
wikitext readable. 

-m

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/eb7de9b3-dac3-40f3-a101-aa702250d5ebo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 9:19:43 AM UTC+1, @TiddlyTweeter wrote:
>
> PMario wrote:
>
> Inline nesting seems to have a problem. 
>
>
> Right. I noticed that. Hope its solvable!
>

V0.8.1 should have fixed it. If not please report!
-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/02f1441b-e752-4d41-a900-20bdcbabe2c1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 11:05:06 AM UTC+1, @TiddlyTweeter wrote:

P.S.: By the way the Pilcrow was originally used inline (often coloured 
> red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the 
> flow of a text. 
> Vellum / parchment was very expensive so text is as condensed as possible. 
> Paragraphs separated by lines evolved much later and was more to do with 
> the development of printing and cheaper paper.
>

Yea, I've seen that. I did find this:

Scribes would often leave space before paragraphs to allow rubricators 
>  to draw the pilcrow. With the 
> introduction of the printing press, space before paragraphs was still left 
> for rubricators to draw by hand; however, rubricators could not draw fast 
> enough for printers and often would leave the beginnings of the paragraphs 
> as blank. This is how the indent before paragraphs was created.[11] 
>  Nevertheless, the 
> pilcrow remains in use in modern time in the following ways: 
>

very interesting. ... I did ask myself for some time, where the indented 
first line in paragraphs comes from.  Now I know :)

-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/a7c70fd3-ef03-4d1f-8af1-b15d0da408a1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 11:05:06 AM UTC+1, @TiddlyTweeter wrote:

The use case I am thinking of is allow me to simplyfy & share with others 
> an approach to correct manuscripts. 
> I work often using specialist software to proof edit articles & books for 
> publishers.
> This uses a specific method and its own system of glyphs (based on 
> "printers' corrections").
> The software involved is very complex and expensive.
> I believe there is a way I could do this work in TW using your Custom 
> Markup if I had a few special glyphs.
>
> I could explain it in detail if you wanted---but I don't want to overload 
> you more than we have already :-)
>

*It would be interesting to know*. .. Otherwise may implement changes, that 
work against your usecase, because I don't know it. .. Which probably has 
happend already as using the pilcrow as a "paragraph" marker. ... Which 
makes it impossible to be used as an inline marker. ... 

-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/cecd0bdb-d337-42be-bc0e-c33b838e2c18o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 10:01:42 AM UTC+1, @TiddlyTweeter wrote:

Can you please clarify what you mean here!
>
> Do you mean that are TWO different Unicode glyphs for Underscore being 
> used?
>

The default behaviour, should do the exact same thing as the existing 
__underline__ does. ... But it can be customized, if users want. 
At the moment, there is a little problem, since custom-markup needs 
__some text__ ... I'll need to fix that. 
-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/7d6e822f-ced1-449f-8333-2ab2e3fdba65o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 1:44:27 AM UTC+1, TonyM wrote:


> This would allow redefinition of mark-up already in a text perhaps even 
> making it behave like another mark-up language.
> and additions like
> \customise glyph="-" _element="li"
>
> - to accept bullets pasted from GitHub
>
>
I was thinking about that too. BUT the github bullet points work in a 
different  way. eg:

 - 
- 

and so on. I think I'll create a new plugin for 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/2c1966bc-0781-4d67-9188-54bbde392384o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 1:36:14 AM UTC+1, TonyM wrote:

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

As default, it will do the same thing. So it shouldn't be a problem. But I 
need to fix it. Atm it isn't 100% the same.
 

>
> It is available on most keyboards.
>

yes 
-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/81f63c41-220b-4e6a-8bc3-b28f0b7eeb78o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi folks,

I'd like to discuss with you the table syntax as shown in

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

\customize tick=! _element=th 

\customize tick=cell _element=td _classes=".hl"
\customize tick _use=cell

\customize angle="===row" _element=tr _mode=block _endString="---"
\customize angle=cmulti _element=td _classes=".hl" _mode=block 
\customize angle=| _use=cmulti

´table ´caption Some caption text
»===row
´! header 1
´! header 2
´! header 3
---
»===row
»| 1 text 

»| 12 text «  and  » 

»|
* cell 13 text
* line 2 
* line 3 
---
»===row
»| 2 text 

»| 22 text 

»| 23 text 

---
/endTable

and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table

Do you think it could be used as a default, shipped with the plugin. .. The 
CSS for multiline and eg: bullet lists will need some adjustment .. 

tick-cells are use for single line cells terminated by \n
angle-cells are used for multi, block like cells terminated by \n\n

»===row
   ends with 
---

-mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/4d80861d-3ad5-4b05-83ef-f313fe6ca11co%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Friday, October 30, 2020 at 1:09:16 AM UTC+1, TonyM wrote:

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

Have a look at this: https://en.wikipedia.org/wiki/Pilcrow

Pilcwrow is used at the beginning of a new paragraph and by default stops 
with \n\n in the customize implementation. ... Similar to TTs suggestion. 
... 

I did try to implement pilcrow / reverse pilcrow as an inline markers too. 
.. BUT it produces really strange and invalid HTML code. Ps inside SPANs 
inside Ps if stuff was nested. .. So I did move it to "block" like syntax, 
where it produces some predictable html output. 

One of my goals still is, to produce html output that is well formed. ... 
There is a pending PR and some discussion at GitHub, that try to fix the 
problems with too many Ps in TW wikitext output. Especially in the UI 
sections, where it causes theming problems. 

-m

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/153413bf-a8da-4bdd-b762-678052f69d2fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi Folks,

There has been so much feedback lately, that I'm still a bit overwhelmed. 
.. I need to read and re-read the infos several times. 

At the moment we have maximum flexibility, except user-glyph-configuration. 
... But let us test, what we have atm. ... 

I'll need to create a lot more automatic tests, to avoid regressions in the 
future. Since "inline"-like configuration can do the same things as 
"block"-like customs I think we have a lot to test ;)

It may be even possible to reduce the number of used glyphs. ... BUT I 
think there is enough variety to satisfy the users preferences. Especially 
as every glyph can have unlimited "symbols"

-m

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

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi,

Inline nesting seems to have a problem. 

-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/dfc96463-8c76-4529-8e4f-32270c2214a0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi,

V 0.8.0 - 2020-10-29

   - There are 4 "inline" like elements
  - __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
   - There are 6 "block" like elements
  - pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
   
and it's crazy!

The "inline"-like elements do have predefined _endStrings but *all* the 
other parameters can be defined. 

There are 6 "block"-like elements now. pilcrow uses a P aragraph as default 
and terminates \n\n as default.

__underscore__ behaves exactly as the existing wikitext ... so it uses an 
html U element by default. This can be re-defined if needed. 

"braille" and "shlash" are nestable by default. 

Shortcut buttons and docs is missing. 
I didn't test all the possible combinations, since that's really a lot. ... 

Have a look at: 
https://wikilabs.github.io/editions/custom-markup/#test-underscore-mode-block:test-underscore-mode-block%20test-inline-small-bracket%20test-tonys-examples

WE WILL NEED TO SIMPLIFY THIS! ... but it's cool to play with it ;)

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/d507143f-5a1a-426f-816d-0f586c439919o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Thursday, October 29, 2020 at 1:17:11 AM UTC+1, TonyM wrote:
>
> Gentlemen,
>
> The attached local view template demonstrates the use of additional code 
> in a specific tiddler. 
>
>- In this case of you add the field local-viewtemplate to any tiddler 
>in the edit view and a new editable field appears. This will be applied 
>through the view template.
>- Please try it, it is immensely useful for research and 
>experimentation on view Template code.
>
> Hi Tony, 
*I got it working*, but I think I'm the wrong person here. The problem I 
have with that approach is: I don't understand it. 

I can't see the usecase, because my philosophy is completely different in 
this regard. 



For me only 1 multiline field exists: The text field. The tiddler is the 
smallest element in TW. 

If I need "combined multiline content" I think there should be different 
stories. IMO the Streams concept 
 is the way to go. In TW 
5.1.23 there will be some (invisible) elements, that will make working with 
"combined tiddlers" and multiple stories easier. 

As soon as I need a multiline field I think it is much easier to go the 
multi-tiddler / multi-story way as shown in the video from 9:30 to 10:30 
  
TW 5.1.23 will contain some elements, that will make this approach easier. 
... BUT there is still more work to do. There are some open PRs and 
discussions at GitHub.

-mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5a69fe6a-bfe1-4400-891a-ac045e9c4f73o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Thursday, October 29, 2020 at 1:05:53 AM UTC+1, TonyM wrote:

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

Those definitions will need to be done at startup time. 
 

> Then all the existing definitions would be transferred into this form, 
> but could be altered.
>

That's right.

Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent 
> use such as 
> \customise openenc _classes=".highlight-green"
> In effect a redefinition, like the current customise.
>
> In the worst case there will need to be a start-up process that puts glyph 
> definitions in a specific tiddler into a table, ie reload to add new glyphs.
>

That would need to happen. ... When \customize definitions are parsed, the 
whole initialisation process is in the past. So there would need to be a 
configuration tiddler, that contains the necessary definitions. 

The problem is, that the user, which wants to define the config tiddler 
would have to know exactly, how the parser works, to do the right things. 
... I think it will be an education / documentation problem. 
 

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

I do have a little problem with too many different "glyphs". .. It may also 
be a "tower of babel" problem, which could make interchanging content much 
harder. ... So if something is hardcoded, all users have to use the same 
"mechanisms". ... 
 

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

If something is defined on a per tiddler basis, I don't see a big problem. 
... The problem for content interchange comes with global definitions. .. 
If users forget to export the global definitions and the tiddler don't 
contain any info, that there actually IS a global definition.

That's why at the beginning there had to be an \importcustom [[abc]]. If a 
tiddler contains this info. Everyone knows what to request. ...
 

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

At the moment the core TW doesn't know how to deal with custom mime-types, 
which basically makes it impossible to use them.

-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/ab2b2a4a-5d17-45d3-b07a-f3faef0f0a01o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
>
> *Regarding User Possibility To Set Markup Glyphs?*
>
> TonyM wrote:
>>
>>
>> *Question - customised Glyphs, a glyph too far?*
>>
>>- As you can see the wide range of glyphs available that have meaning 
>>or structure makes me wish to ask if we could allow the user to nominate 
>>glyphs either single (line/para/blocks) or pairs for inline or block. ie 
>>customise the customise glyphs.
>>
>>
>  Ciao TonyM & PMario
>
> IF this were possible I WOULD use it.
>

... need to think about it. But it would make configuration a hell lot more 
complex.
 

> Why? Because the kinds of Markup I do would benefit from me being able to 
> choose glyphs VISUALLY SUITED to the purpose.
> For instance, for simple paragraphs ...
>
> ¶ Start of a paragraph,
> more of the same pargraph endedon the next line.
> ⁋ <--- End String
>
> I understand if its not possible. 
>

It would be possible to use pilcrows as "start" and "end" of a paragraph, 
but I don't understand why. 

TW Pargraphs end with \n\n by default

So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
personally it is confusing, since Libre Office and Word use: ¶  as a 
paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
paragraph. ... So the reverse pilcrow feels completely wrong at that 
position.

*I could implement:*

¶ some text \n\n

Since it would be the right thing to do. see: Wikipedia Pilcrow 
<https://en.wikipedia.org/wiki/Pilcrow>. It would be easy to explain, with 
the link to Wikipedia. It will create a HTML P tag by default.

If you want you can define an _endString. ... Default would be \n\n

-mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/861387d1-7ccc-490e-b75c-b55e76b1ea9bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi Tony,

Very good questions. ... all of them. 

As I do read the requests, I think we shouldn't make a difference between 
\customize and \customize inline  But this could cause a lot more 
consistency problems, like:

´d ´s some text<-- only works that way because I liked it. 

With strict rules it would need to look like this:

´d
´s some text
some text
   <--* _endString*

I'll think about the ideas .. while I'm sleeping ;)

-mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/6b0df58a-4bd9-41a9-8249-44861f31741fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Wednesday, October 28, 2020 at 1:50:19 AM UTC+1, TonyM wrote:
>
> Mario,
>
>> _endString will be _not_ configurable. 
>>
>
> I agree with this but ask if if it makes sense to be auto-terminated with 
> \n or \n\n  
> am I wrong to think *Typically inline does end at a line or paragraph 
> break?*
>

No. Inline ends with a predefined endString and it uses inline mode only!

﹙.hl some text
! new line <- no H1 here since we are in inline mode!
3rd line
﹚some more text

If you need H1 to be rendered, you'll need to use "angle" or "tick" with 
_mode=block and an _endString

*-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/47060e51-8a0c-4170-b7a7-723215e704f1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Wednesday, October 28, 2020 at 1:14:30 AM UTC+1, TonyM wrote:
>
> *A few observations.*
> Again please don't be overwhelmed just consider these ideas please. Nor do 
> these ideas imply it demands your work, although in some cases that is most 
> likely.
>
> The key issue I am grappling with is the systemisation of glyphs, symbols 
> and the scope of customises wiki text. To make this easy to use and 
> remember. Presently I always need to lookup the reference material and 
> slowly construct wikitext, if its slow and hard for me (involved in this 
> project from the start) it may appear impossible to future new users. There 
> are differences in the way Mario, TT and myself envision this, until this 
> is cleared up even testing will be clumsy apart from helping future users.
>
> Observed - In a tiddlywiki without custom mark-up
> This is some Text __.test Inline text ___ with more
> fails gracefully
>
> ;This is some Text __.test Inline text _/ with more
> Fails *un*gracefully. Disrupts future wiki text.
>

You are right. ... I didn't consider this. ... But may be we should remove 
underline. It seems to cause more problems as it solves. And we do have 
enough other possibilities now. 

-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/cb2f03ff-9eb6-4a5e-9ea5-c072ff964540o%40googlegroups.com.

[twdev] Re: Documentation about plugin dependencies

[PMario]

Hi Matt, 

If you open the import plugin mode, you can click the  expand button. The 
text that is shown also shows the dependencies, if there are any. 

-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/d71ece1a-9ac4-4972-947a-1e40ee17347bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Tuesday, October 27, 2020 at 9:33:07 PM UTC+1, TonyM wrote:

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

It is able to detect start / end and nested inline definitions. But at the 
moment it only sets class-names. ... No possibility to call widgets. ... 
Will follow soon.

At the moment the plans are: 

_element should be configurable. ... I think it will be limited to widgets 
and html inline elements 
, or may 
be even a subset of them. 

_endString will be _not_ configurable. 

_mode has to be fixed to inline

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

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

-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/27e35a52-83b8-4c49-a064-75e0bb16bffeo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi, 

V 0.7.0 - 2020-10-23

   - New Inline functions
  - _symbol.class.clsss:param:param some text__
  - .class and :param work the same way as "block" definitions
   - Removed underscore from "block" definitions, because it's used by 
   "inline"
   - Added: \\ pragma comments
  - It's faster than HTML comments , since it can be 
  used outside macro \define x() blocks
   


*NO \customize inline functions yet. *

Have a closer look at the tiddler code: 
https://wikilabs.github.io/editions/custom-markup/#tick-inline-simple  


As you can see in the code below there are 4 possibilities atm.  I intend 
to reduce them to 2 if possible!

a)
 - start: 2 underscores: __ 
 - end: 3 underscores or 1 underscore slash : ___ or _/

b)
 - start: /°
 - end: °/

c) 
 - start: ⠒
 - end: ⠶

d) 
 - start: ﹙
 - end: ﹚

a,b,c are nestable if using them again. 

d) is only nestable if one of the others is used. I'm not sure, if I like 
this behaviour. ... 

-mario

switch (this.match[1]) {
case "__":
reEnd = /___|_\//g
break;
case "/°":
reEnd = /°\//g
break;
case "⠒":
reEnd = /⠶/g
break;
case "﹙":
reEnd = /﹚/g
break;
}

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2f6a4117-3174-4e34-88c6-02107094fed6o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

Hi folks,

Please continue discussions here: Custom markup (continued 4) 


-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/b957b596-e847-4de4-ba54-deef2f397553o%40googlegroups.com.

[twdev] Custom markup (continued 4)

[PMario]

 Hi folks,

This is the continuation of 
 - Custom markup 
 
[1] 
 - Custom markup (continued) 

 - Custom markup (continued 2) 
 [2]
 - Custom markup (continued 3) 
 [3]
 
Let's start a new one before [3] 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/ 
 !

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/ccf2f7c4-d765-418d-b271-f8fe43bd604eo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

On Tuesday, October 27, 2020 at 6:19:56 AM UTC+1, TonyM wrote:
...

> ﹙symbol.class:param some text﹚
>
> Where if you use ﹙ as the glyph, the end string is "﹚" for inline. The 
> symbol remains free for other configurations
>
> A specially formatted quote ﹙q.large some text﹚ in line ﹙ the default 
> result ﹚ inline. (Assumes trailing space before ﹚ not needed, although 
> training space for ﹙ is needed. )
>


Ahh OK. .. I kind of like it that way: ﹙symbol.class:param some text﹚.. But 
I still don't like the spacing:﹙.class:param some text﹚.. 

It: "﹙" looks like char ... ... 

Did you find a "smaller version"?

-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/8f5b1191-a2e3-4784-8ef1-74796672e4a9o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

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

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

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

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

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

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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: Basic Question Regarding TW5 Framework

[PMario]

Hi Christopher,

You may be interested in this hangout, where 2 D and TW enthusiasts 
present their stuff. 
https://www.youtube.com/watch?v=Imx-EzCOWGc=PLVT_2PPd-1p34gGCQ5qpwC8QdykxVAI3u=2

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/bc96e893-b079-40a0-828c-04c9fb64627do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

[PMario]

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)

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

[PMario]

On Wednesday, September 30, 2020 at 5:10:49 AM UTC+2, TonyM wrote:

I have published [RFC] Request for Comment and collaboration - Unique 
> renamable Tiddlers and children with any name, a total Database? 
> 
> Just now, the features of which could be leveraged by custom wiki-text 
> especially when looking for state and unique tiddlers;
> Eg; Rather than qualify use [prefix[$:/checkboxes/]suffix[a]]... 
> perhaps checkboxes against children. 
>

The problem I have with TSNs as you described them is, that they are not 
universal unique. .. But that's not only your problem. I do have the same 
problem with aliases. ... 

The DAT/HYPER infrastructure may be a solution here, since they use a UUID 
as their address. eg: 
hyper:///recipes/{recipe-name}/tiddlers/{tiddler-name}

if the  is hashed and stored with the tiddler, it can 
be used to identify tiddlers with the same name. 

Question(s)?
>
>- Given "_params = class definitions" perhaps it could become _classes 
>and _map becomes _params?
>   - It would be easy/clearer to say the syntax is 
>   .class(s):param1:param2
>
> Yea, I did think about this myself. At first I wanted to use _params like: 
=".a.b:a:b", but it gets really messy with longer names. 

It will be a breaking change. So may be in 0.6.0, which should also use 
angle instead of angel... which makes me sad a little bit :/
 

>
>- I have experimented to see If I can introduce custom definitions in 
>the story list or view templates as I am keen to get at least a 
> conditional 
>global customise pragma.
>   - I am not concerned, too much, how we achieve this, only that we 
>   document at least one method to do it, that does not demand \customise 
> or 
>   something similar in the text field.
>   - Transcludeing a tiddler of definitions should work, but if this 
>   could relate to a tag not unlike $:/tags/macro  
>   - For example if a tiddler has object-type[book-page] bring in a 
>   set of *custom wiki-text *and styles can be handled separately.
>   - One day I hope to toggle custom-wiki text definitions such that 
>   one can render for a screen, newsletter or PDF print layouts using the 
> same 
>   content and wikitext but alternate customise pragma.
>
> As I wrote earlier. I couldn't find a way to have global parser pragmas. 
.. The problem is: Internally TW core creates a new Parser() for every 
tiddler, similar to:

tiddler-parser = new Parser(type,text,options), which parses the tiddler 
text. eg: 

\define test()
test-parser=new Parser(type,text,options)
test
\end

some text

As you can see, there will be a new parser for the tiddler and a different 
completely independent parser for the macro content. ... So as soon as a 
template uses a macro, the settings from the "outer" parser are invisible 
to the "inner" parser, because they use completely different memory. 

The same is true for many widgets, that create several temporary parsers 
... That's the reason why the \whitespace pragma has to be used per macro. 
... I do have the same problem. 

I couldn't find a way, to "climb up the memory ladder", to store parser 
info persistently. Parsers are created and thrown away on demand. I'll have 
a second look. 

 

> *Review discovery;*
>
>- If I clone test-checkbox-widget-maps-transclusion and change the 
>text in one of the checkboxes, I seem to get the same state tiddler as in 
>the original (only on refresh), that state tiddler is listed by not 
>honoured. 
>   - I was wondering about checkboxes that are internal vs global, one 
>   checklist could prefill another using different text marked elsewhere.
>
> Yea, the new tiddlers have 2 lists: Global stat tiddlers, which is the 
default now and "local state" tiddlers, which are responsible for 1 
tiddler. 
 

> FYI
>
>- I have discovered a number of powerful techniques on top of custom 
>Wikitext I have not had the time to share yet.
>
> I'm looking forward to see the tests. 

-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/3a8a79da-9b99-4e6c-9052-96770b3d5819o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

I did add a bit more colour to the examples, to visualize the data-flow a 
bit better.
-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/9ec6cdaf-6513-4efb-9fb3-a03bc9cc45a3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

Hi,

I'm not 100% sure about the parameter names. So they may change. 

-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/52dea22b-ad9e-4cb0-bd01-f7a272ec2373o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

Hi folks, 
I did just upload V 0.5.3 that contains 3 more very powerful parameters. It 
lets us do the following: 

\customize degree=☐ _element="$macrocall" $name="check" _1=tid 

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

°☐:a This is a test
°☐:b This is a test 
°☐:c This is a test 

With the "old" mechanism only 1 state tiddler would have been created. With 
this mechanism it is possible to add 2 new parameters to the macro. eg:

°☐:a .. a is the text, that will be written to the tid parameter of the 
"check" macro. 


It's possible to have 2 new parameters. If there are more, it gets way to 
complicated. IMO it will be much more readable to use the existing 
mechanism. 

\customize degree=☐ _element="$macrocall" $name="check" _1=tid _2=test

\define check(src, tid, test) 
<$checkbox tiddler=<> tag=done class="db"> 
<<__src__>> - $test$ 
\end

°☐:a:noSpacesAllowed This is a test

Since this

°☐:a:noSpacesAllowed This is a test

may be too much clutter it is possible to define a new _maps parameter eg: 

\customize degree=☐ _element="$macrocall" $name="check" _1=tid _2=test 
_maps=":a:noSpacesAllowed"   

°☐ This is a test

More info can be found in the examples. .. The _maps parameter can do some 
cool stuff. 
See: Examples in GG 


Have fun!
mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c0f711e0-f524-41f3-9edf-bf7fc5c1734co%40googlegroups.com.

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

[PMario]

Hi,

That's a very interesting topic. Printing books has been developed and 
improved since about 500 years. .. HTML and the internet was able to 
"destroy" it in 20 years. .. In the last may be 10 years the standardizing 
groups try to implement elements from "printed media" into "web media"

We got new HTML/CSS elements like flexbox, grid, masking and others, that 
allow us to improve and control the layout of a web page. ... BUT we are 
still miles away from printing a good looking page, directly from the 
browser. 

We need to convert HTML to TeX with 3rd party tools, to be able to get a 
good looking printed page, that we can read with joy as a PDF. .. No trees 
need to die ;)

-mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3aeca82c-7bc5-4c4c-a9d7-cc561c5e93e8o%40googlegroups.com.

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

[PMario]

Hi,

It's still possible to create a ::first-letter in CSS. See: 
https://developer.mozilla.org/en-US/docs/Web/CSS/::first-letter

Especially the variant h2 + p::first-letter {} is very interesting. 

-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/ca7a0e82-9112-44f5-abb5-34c9ca99e8c2o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

On Saturday, September 26, 2020 at 1:33:40 PM UTC+2, @TiddlyTweeter wrote:

Quick point. In my USE CASE I'm interested in using CSS classes AS the 
> "code" / shorthand (actual end-user text is inserted via CSS *::before *) 
> . The user would see NO comprehensible text at all if they opened a Tiddler 
> in edit mode ... They would see stuff like this ...
>
> °.x-4x
> °A.standard-back
>
> etc ...
>

OK. ... That's interesting. 
 

> My point in my OP was to open-up what "readable" means. My "shorthand" is 
> totally readable to me. It produces (in render) ...
>
> On all fours. First attend your back. Can you form a mental image of where 
> it is in space?
>
> I don't think that approach is like Gruber Markdown at all. But the 
> concepts Gruber initiated have had enormous shaping influence on how we 
> think about markup. Especially in wikis.
>

It's true, readability is different for every user. ... My intention is, to 
allow "styling" markup like .x-4x directly after the ID like: °.x-4x  but 
if the user chooses to make the wikitext more "verbose" they can move the 
"cryptic" elements into the _params parameter and define a wikitext like 
so: °this-and-that-should-happen ... 

For me it's important that both variants work. 

So when PMario talks about "readability" I want to push it :-) I think what 
> he means is text in *"Gruber mode"*. I.e. part of normal language use 
> with markup symbols that compliment that.
>

That's right, as written above.
 

> But PMario's tool actually opens up totally what "readability" could be. 
> When you start thinking this through it gets liberating.
>

Yes. That's the intention. 
 

> TBH Tony, I don't think it is a programming syntax per se (in my use case 
> it is just standard CSS, there is NO programmatic logic. Its simple text 
> SUBSTITUTION).
>
 

> The easiest was I could describe it is "*Private Shorthand Supporting 
> Public Messaging*".
>

That's 1 usecase and it has been the initial one :)
 

> It is provision of an efficient method for supporting AUTHOR writing 
> methods. Full stop.
>

yes .. over and out (for this post) q;-)

-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/22295f71-3a1c-4280-ab3e-014a33fc123fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

[PMario]

On Saturday, September 26, 2020 at 3:28:40 AM UTC+2, TonyM wrote:

2. Setting and using evaluated variables
> \customize tick=ghost _element="$set" name=ghost 
> filter="""[all[current]addprefix[$:/ghost/]]""" _endString="/ghost"
>
> ´ghost <>
>
> And <> the value is here
>
> <$set name=new-var value=<> >
>
> My <>
>
> 
> I did not use the end string here! Is that a problem?
>

No .. It parses till the end of the tiddler. 
 

> Are they "self closing"?
>

kind of. .. The end of the tiddler is the "closing" tag. Add this _after_ 
the  of you code.

 shortened above

/ghost

<>

<>

Then remove the _endString ... You'll see the difference. 

That's the reason, why many of my text-xxx tiddlers have a line at the end 
like: "some more text".. 

-mario

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/94f8237f-43fe-4e50-9cf7-da6219ff1181o%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)

[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] Custom markup (continued 3)

[PMario]

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/20175a5f-43b6-4680-a06e-7fe6d931cc2fo%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 
<https://www.compart.com/en/unicode/U+2610> 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)

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

[PMario]

On Wednesday, September 23, 2020 at 11:13:10 PM UTC+2, TonyM wrote:
 

> However, without customisations
> Count: `<$count filter="[prefix[$:/state]]"/>` works
> Count: `<$count filter="[prefix[$:/state]]"` does not
>

There is a typo: you need to close the first widget element: `<$count 
filter="[prefix[$:/state]]">` 
 

> So I think this observation still stands. 
> Since customise will generate  It will not work
>

Not really. The string   is like the _endString parameter for the 
standard TW parser. So it doesn't need to be created. 

I do not know how to identify others without exhaustive testing or reading 
> (understanding) widget definition code.
>

see above typo.

As written with the _srcName parameter, there should be almost no limit in 
> using any widget. ... except may be the <$button widget, if you want more 
> than 1 parameter from the line.
>
>
>- *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. 
 

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

Wouldn't it be better to use the "real" widget call instead of making 
"custom markup" more complex. I think, if we have parameters in the first 
line, we loose the "readablility" advantage. 
 

> Here is another experiment that has WORKED!
> \customize tick=style _element="style"
>
> ´style .mystyle {  border: 1px solid green; border-style: dotted; }
>
> ;.mystyle Content
> ;Perhaps also;
>
> ´style {{myStyleSheet}}
> so one could have a 
>

Yea, but that is not best practice. It will hide a 

[twdev] Re: Custom markup (continued 2)

[PMario]

Hi
I did update the page and the pluginlibrary 5 minutes ago
-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/955cb7c2-7dc3-44b0-a64e-1b15687f7a96o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Wednesday, September 23, 2020 at 1:20:52 PM UTC+2, TonyM wrote:
 

> I think you suggested this before, but our use of widgets is limited by 
> those who do not honour the close part of <$wiggetname 
> params>content rule
>

It needs to be content or template in the body. 
 

> A case in point is the <$count widget, as it can only be closed with /> 
> not 
>

Every widget that is used "self closing" like <$count /> there should be 
_no_ problem. They should all work. _And with the _srcName you have *one 
parameter*, that can be defined in the "user line"..
 

> Going forward
>
>- Perhaps we should raise this as a fix, for each widget we find, just 
>to get the consistency we need that all widgets to allow the full close
>- I do not think you should cater for this because it could compromise 
>nesting (a guess)
>
> As written with the _srcName parameter, there should be almost no limit in 
using any widget. ... except may be the <$button widget, if you want more 
than 1 parameter from the line. 

-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/eb10b3c1-e7ce-498a-9242-986bfc130034o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Wednesday, September 23, 2020 at 12:22:54 PM UTC+2, TonyM wrote:
 

> Especially the use of src
>
> Do I understand correctly the _srcName=filter effectively says, assign 
> the value found in the line, to the parameter filter, in this case that is 
> in the list?
>

Right! 

If _element is a widget the content of the line is automatically added as 
an parameter named: src   src is the default. 

eg: copy-to-clipboard and the docs-wikitext uses this name. some others use 
text. That's why it needed to be configurable.

-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/bdddfd42-e936-454b-90ba-796e0adce0dao%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Wednesday, September 23, 2020 at 10:49:18 AM UTC+2, TonyM wrote:

\customize tick=children _element="$list" filter="[parent]"
>
>
> And the last one children has set me of on a one and many to many 
> relationship solution
> * now that what TocP is no longer magical to me :)
>

I see :)
-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/1f1b5eae-3cf0-4fe8-8820-dc0290b761d1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Wednesday, September 23, 2020 at 10:49:18 AM UTC+2, TonyM wrote:

This example not only shows that the customise pragma can be used to store 
> a canned filter for reuse, but also shows how the first in a nested list 
> can be concealed behind a helpful name like system-shadows 
> \customize tick=system-shadows _element="$list" filter=
> "[all[shadows]is[system]]"
>
> ´system-shadows <$list filter="[all[current]has[caption]] +[!is[blank]]"
> >{{!!title}} {{!!caption}}
>

Very interesting! .. If you use the template=xx parameter in the pragma and 
move the second list into the template, it could look like this. 

´system-shadows-plus-caption

Similar to my examples in the last post, but without the _srcName parameter
 

> I am confident with* Mario's nesting method* a simple line could define a 
> set of nested lists with the content of the line equal to each final record.
> If named well the variable set for each nested level will make the wiki 
> text look like some 4th Generation reporting languages.
>

Yea, I think using the right naming is essential to create "wikitext" that 
is selfexplaining.
 

> 'customers `country `state {{{ [all[current]size[large]] }}} Automatic end 
> string for each on \n?
> But in this example I think the last filter here, on the line, needs to be 
> in a list because otherwise it generates unnecessary line breaks
>
This is approaching simpler than SQL
>

 

>
>- Of course if somehow we can pass the filter to each nested level, 
>not only would canned filters be used.
>
> That's possible with the _srcName config. ... For 1 parameter


>- However if one has structured data in a wiki it would be simple to 
>create the set of canned filters for handling the structured content in 
> the 
>wiki.
>   - For users of a wiki (rather than owner designers) it may be 
>   simple to provide them the info they need to generate any list or report
>   - Especially with some useful templates.
>
> In the following case we use a list template
> \customize tick=all-tiddlers _element="$list" filter=
> "[is[tiddler]!is[system]]" template="$:/core/ui/ListItemTemplate"
>
> ´all-tiddlers This does nothing so can describe it
> This is another case where passing the template value may be helpful
>

;) See last post.
 

> I am working on a better way to name templates/transclusions so the above 
> could read
> \customize tick=all-customers _element="$list" filter=
> "[is[tiddler]!is[system]object-type[customer]!archive[yes]]" template=
> "(customer-record)"
>
> ´all-customers List all customer-records
>
>
 

> By the way, If the List widget was to contain two new parameters before 
> and after, that could provide header and footer content, Only if there were 
> content, this would expand further, allowing content and or table headers. 
> I miss foreachtiddler still :(
>

You can use a $macrocall widget here. IMO it should be simple. The default 
_srcName is src . So the macro will bet a "src" parameter, which can be 
used in the macro. src can be passed to the list-widget and the macro body 
can contain "before" and "after" elements. 

IMO it's not needed in the list-widget. 

 Thx for sharing
-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/42912d3b-ea6b-4cba-801b-d22edefc8b1ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Wednesday, September 23, 2020 at 8:46:08 AM UTC+2, TonyM wrote:

A little experimental fun;
>

:)
 

> This method uses the vars widget to pre-define a set of variables for use 
> inside the custom markup. As in this examples we have all out standard 
> address details using well known names. You choose which to use and how to 
> arrange them. Of course the variable are only available inside the vars
>
> \customize tick=address _element="$vars" address="N Blah St Randwick" name
> ="Anthony Muscio" phone="612 4075581847" email="to...@virtual.com 
> "
>
> ´address  Here we use <> <> <> 
> ´address  Here we use <>Phone: <><>
>
>
Nice idea! I like it.  

>
> The following shows how the list widget with a pre-set filter can be used 
> to choose if the content is to be displayed or not, emptyMessage can be 
> used as well.
> \customize tick=debug _element="$list" filter=
> "[all[current]has:field[debug]]"
> \customize tick=design _element="$list" filter=
> "[{$:/config/design-mode}match[yes]]"
> \customize tick=draft _element="$list" filter=
> "[all[current]has:field[draft.of]]"
>
> ´debug  Debug: in <>Transclusion=<>
> ´design Show only when global design mode is set. to yes
>
> ´draft `Show only when Tiddler is in draft mode`
>
>
Very interesting. I didn't think about that use case
 

> This also triggers me to ask *Mario*
>
>- How do I get a new line, but not double, newline to be used in the 
>result(s)?
>   - Was it a specific Character?
>
> The space-space-enter plugin is installed on the page. So you can use 
either space-space-enter or space-space-backslash  \
at the end of the line, to create a newline. 

But playing with your examples and newline .. I think, there is still a bug 
with \n and \n\n and whitespace handling. Will have a closer look.
 

>
>- Would it be costly to have an alias to \customize of \customise? For 
>me this is a common error.
>
> Very ;) ... No, it should be simple. 
 

> As expressed earlier, I would so love to pass the filter to a customized 
> list definition.
>
> Here we simply use list to access a canned list of tiddlers defined by a 
> filter
> \customize tick=toc _element="$list" filter="[tag[toc]]"
>
> ´toc <>
>
> ´toc <$link/>
>
> ´toc <$transclude/>
> Notice how common wiki text is all you need that refers to currentTiddler?
>

There is a new paramete 
r:
 
_srcName ... use this: 

\customize tick=list-a _element="$list"  template="currentTiddler-template" 
_srcName=filter
\customize tick=list-b _element="$list"  template="link-template" 
_srcName=filter
\customize tick=list-c _element="$list"  template="transclude-template" 
_srcName=filter

´list-a [tag[toc]]

´list-b [tag[toc]]

´list-c [tag[toc]]

The *-template tiddlers use: <>  \   and  <$link/>and   
<$transclude 
mode=block/>  
as their content. 


>- Empty message can also be used in the customise.
>
> In this case you can test is the current tiddler, or a named tiddler is a 
> member of the canned filter
> \customize tick=toc _element="$list" filter="[tag[toc]]"  
>
> ´toc <$text text={{{ [all[current]match[Basics]then[Matches Basics]] 
> }}}/>
>
> ´toc <$text text={{{ [all[current]matchthen[In TOC list]else
> []trim[]] }}}/>
> - however this second one produces empty lines.
>

Nice experiments. 

I'd like to ad them as test-xxx to the published version. Is that OK?

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/a062cbd8-7e1a-423e-b7e3-0cbd8e3a833fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Tuesday, September 22, 2020 at 8:46:25 PM UTC+2, Mat wrote:
>
> So, if the CSS is defined elsewhere, do I understand it right that the 
> user has to insert the following bit in every tiddler that he wants to make 
> such styled notes in?
>

See the \importcustom pragma 
https://wikilabs.github.io/editions/custom-markup/#Import%20Predefined%20Pragmas
 

> For real world I think this needs to be a template of some kind.
>

\importcustom can use filter syntax to import pragmas only from several 
tiddlers eg: [tag[basic-pragmas]] ... 
 

> E.g any tiddler tagged "book" has this automatically applied, i.e 
> triggered via someting intuitive that the user probably already does (e.g 
> tag). It is unrealistic to think that a user would manually add this even 
> via a stamp unless he is totally into it and working with a dedicated 
> book-note-taking wiki. The wiki user who occasionally wants to make a "book 
> notes tiddler" would otherwise need to dig this out, which it just unlikely 
> IMO. Or do I misunderstand something?
>

At the moment it's not possible to make pragmas global. 

»note ´page [[book]] 30-5
>>
>
> How is the above to be interpreted?
>

You may have missed the docs. 
https://wikilabs.github.io/editions/custom-markup/#Basics:Basics%20Advanced 
Start with Basic. 

Your question will be answered at Reference: 
https://wikilabs.github.io/editions/custom-markup/#Custom%20Markup%20Definition 
and Advanced

Style it with "note", yes, but then there's also "page" style? But [[book]] 
> 30-5 are "headlines" seen in the text, right?
>

angel » is the ID. "note" is the  the class definitions are 
defined in _params

-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/85948bc2-3e29-49e3-b805-6a9c2777b6beo%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

Hi,

If you have some text from the book, ASIDE would be an option too. 

https://wikilabs.github.io/editions/custom-markup/#test-aside-without-pragma:test-aside-without-pragma%20test-aside-clearfix

So your comments can be the aside element. 

-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/52d8a102-4133-43d0-ac4c-f84a5ce558ddo%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

On Tuesday, September 22, 2020 at 2:20:08 PM UTC+2, PMario wrote:


»note ´page [[book]] 1-5
> your comment!
> --
>

You can define a stamp of the above text to be quicker. 

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/74a6acb9-cc67-40af-9b2c-91344267990ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[PMario]

Hi Mat, 

I think it can be done in a similar way to the html DETAILS element. 

I'd go with something similar to this: BUT the  section should be in 
a separate CSS tiddler

\customize angel="note" _element="div" 
_params=".note.notop.cbox.cbox-primary.hard-linebreaks"  open _mode=block 
_endString="--"
\customize tick="page" _params=".margin-init.page"