Custom markup (continued)

[Mat]

Last thread paginated.

Apropos what character is appropriate for PMarios construction, PMario wrote:

I'll be happy to change it, if someone has a good idea.

I think proper keyboards should be prioritized here, not "screen keyboards" because presumably most people do their full blown wiki editing on real keyboards, not on their their phones.

The generic currency symbol i.e  ¤  can be found on a few keyboards, including both Swedish and the Tastaturbelegung_E2 ;-)

<:-)

[TonyM]

Folks

First a comment on the character selected. I belive it should be unlikely to be used on any key board or language in normal text especialy that it not be the first character in a line or used in its double form for use in line.

There are more than enough opportunities to use shortcuts or toolbar buttons to access a special character. When on mobile devices we are used to using a button rather than a keyboard for special functions. we tend to select and apply.  

What ever character is chosen it should be easy to find when looking for it at the beginning of a line and when doubled inline. However similtaniously it should be almost invisible when reading text. To be honest tick is perfect but for its similarity to others.

I will search for some possibilities today.

Regards

Tony

[TonyM]

Mario,

I want to respond to your latest "state of play" post.

I admit i am not sure about the details in pragma but i belive you have addressed my rule in or out needs.

This is looking fantastic especialy your handling inline now. Thank so much for your systematic, all inclusive and openness to feedback. Your are a rare developer in this regard.

Finaly i need to understand, or ensure we have addressed;

• when your syntax says "name" this is effectivly a html tag name including arbitary names?
•  the difference between \n and \n\n handling
• How we handle applying the same to a block ie content containing more than one \n or \n\n?

Other forshadowed possibilities can wait until later but we must not compromise thier use in the future

I will list them if requested.

In closing for now I belive this will be revolutionary especialy for advanced users, but easy to package solutions for new users.

Regards

Tony

On Tuesday, 8 September 2020 at 06:39:57 UTC+10 Mat wrote:

[PMario]

On Tuesday, September 8, 2020 at 3:41:17 AM UTC+2, TonyM wrote:

This is looking fantastic especialy your handling inline now. Thank so much for your systematic, all inclusive and openness to feedback. Your are a rare developer in this regard.

Thanks

 

Finaly i need to understand, or ensure we have addressed;

• when your syntax says "name" this is effectivly a html tag name including arbitary names?

\tickblock tick=<symbol> tag=<html-tag> endString=<ends a block> mode=<block/inline> use=<name of previous tick= definition>

tick=asdf ... will be used in the prose text as: <symbol> is better than <name> since it can be $ or § or & or text

´asdf your text comes here.

----------------------------

tag defaults to: div  .... for ticks ... if parameter is missing

tag defaults to: p .... for angel ... if parameter is missing

-----------------------

endString and mode see text below

----------------------

use= ... is a special parameter eg:

\tickblock tick="a-long-name-comes-here" tag=span mode=... endString=...

\tickblock tick="$" use="a-long-name-comes-here"

If "use" parameter is used, it will search for a definition that already exists. It will ONLY use params from the definition referenced in "use="

It does _not_ use any of its own params if it has some. (this may change )

"use" is important for \importparagmas, to make usage and the text more verbose and meaningful for other readers. Tiddlers that contain "templates" should use "speaking" names. ... Users may want to use short names in the prose text

\importpragmas [[table-definitions]]

\tickblock tick="h" use="header"

\tickblock tick use="cell"

the last definition is used in text like so:

´ text comes here. ... It is a shortcut for ´cell 

This is the "shortest" definition for a complex structure we can have.

•  the difference between \n and \n\n handling

default mode is inline

"tick" defaults to single line break: \n

"angel" defaults to souble line break: \n\n

Both of them can handle endString if mode=block

• How we handle applying the same to a block ie content containing more than one \n or \n\n?

if mode=block and endString="---" the content in between can have anything.

endString can be any character combination you want. EXCEPT whitespace and regexp definitions.

I use "---" because it will be rendered as an HL element if the plugin is not installed. ... So the text may make a little bit of sense.

have fun!

-mario

[PMario]

Hi,

New version uploaded: https://wikilabs.github.io/editions/tick-text/#test-table-use-degree-as-tick

It allows ticks to be used as ´ or ° ... degree sign ... ATM both work.

-m

[PMario]

Hi, help requested

I'm searching for a new name for \tickblock and \tickinline

I'm not happy with

\tickblock tick=<symbol>  and \tickblock angel=<symbol>

\tickinline tick ... there will be no angel

mario

[Mat]

@PMario

First, I just have to agree with Tony: You're a rare developer, doing fantastic stuff! :-D

Regarding

\tickblock tick=<symbol> tag=<html-tag> endString=<ends a block> mode=<block/inline> use=<name of previous tick= definition>

May I suggest the following parameter name changes:

\tickblock ---- change to \customblock or \indicatorblock (the word tick is too specific IMO and also ignores anglequotes)

tick ---- change to indicator

tag ----- change to htmlTag

Just my opinions.

<:-)

[Mat]

PMario wrote:

Hi, help requested

LOL! I didn't see your post before posting mine!

 

I'm searching for a new name for \tickblock and \tickinline

So as noted \customblock or \indicatorblock, possibly \iblock

Q: Will it ever only concern styling? If yes, then possibly \stylesection or even just \style (... "apply a style pragma")

I'm not happy with 

\tickblock tick=<symbol>  and \tickblock angel=<symbol>

So, yeah, IMO indicator is the right name and one that turned up naturally in our discussions.

 

<:-)

[TonyM]

Mario

I see now you have abstracted this even further such that our original usecase is but a small subset of the possible. 

Is it posible for the user to select the character?

I particulary love the details example because optional display of content has being way too fidly.

In the naming game i would think somehow this is a wikitext way to escape from the the limitations of wikitext. In fact it allows us to define that escape character and what follows multiple times. So i would be happy with

\esc ...

\excape ...

\excape-wikitext ...

or all three

Thus escblock if needed.

Then rather than tick= it could be esc= which is what is used to excape from wikitext and apply the htmltag and classnames.

• I have some questions for clarity. I will compose these my tomorrow.
• Shall I / we start to write some end user doco?

I continue to be amazed at this development, infinite extencibility in another direction.

Regards

Tony

[TonyM]

Post script,

Prior work playing with the power of class names, that tick and angle enable on any line, not yet starting with a wikitext symbol and most wikitext symbols, was revolutionary on its own. 

By the way please call it htmltag and not tag, there are too many unqualified things that use the word tag around already.

The fact is these development almost over shadow the use of classnames on any line, and now use of any htmltag.

I thought an included set of css short class names should be put forward as a de facto standard so unless people need to vary from that standard it is easy to use and reuse on adoption of the tick solution. Or could I say the escape wikitext solution. So I hope we can put together an optional stylesheet to include with the solution. A little pre-configuration of highly extensible solutions are wise so as to help with adoption, provide a base on which to build and send most people in a simular direction rather than it be an unnecessary but optional "free for all.".

Perhaps a new thread here to discuss the development of this defacto short classname definitions that we can include in a stylesheet for use with current wikitext character and the new solution.

If nothing else give us a standard around which to demonstrate the use of the new solution.

Regards

Tony

[TonyM]

Post Post script,

Given this unlimited suite of rapidly typing in wiki test and custom variations that result in bespoke formats and layouts, the fact is this is converted to html to be rendered, and it can be copied as html for use elsewhere (including tiddlywiki)

Then perhaps we have enhanced and built a meta html language for writing html body code? 

although without the ability to insert javascript functions.

I wonder if another pragma would allow code to be included that is ignored in tiddlywiki, but capable of action in the resulting html once placed in a file?

Tiddlywiki could become a html page or site SDK with automation and self documentation capabilities that can be previewed in iframes. Build your own "Square space".

Just dreaming because that is what you all, and tiddlywiki do to me. Clearly alone in my time zone beyond midnight.

Regards

Tony

[PMario]

On Tuesday, September 8, 2020 at 3:21:26 PM UTC+2, TonyM wrote:

I see now you have abstracted this even further such that our original usecase is but a small subset of the possible. 

Is it posible for the user to select the character?

<symbol> can be freely choosen.

tick, angel, comma, degree, underline ... are fixed internal IDs ...... And YES, there are 5 possible config names now. BUT BUT BUT atm that's just for testing. We may reduce it in the final version.

 

I particulary love the details example because optional display of content has being way too fidly.

Yea, this construction can easily repalce a macro.

 

Then rather than tick= it could be esc= which is what is used to excape from wikitext and apply the htmltag and classnames.

it's tick, angel, comma, underline and degree now. .. :)

 

• Shall I / we start to write some end user doco?

Not yet. Naming will change completely in V0.1.0

 

I continue to be amazed at this development, infinite extencibility in another direction.

Yes. While programming and testing I did see much more flexibility and usability coming up. ... There is some complexity, if needed. ..Most users will only use it to indent paragraphs. But advanced users can be creative.

I wasn't sure, if it would be possible to create a different configuration for tables with "multi-line cells". .. That's a nightmare with the default tabe wikitext. ... It's simple with "tick-text" .. I'll probably keep the plugin name ;)

As written. ... V0.1.0 .. first beta  is in the making. It will have more possibilities

I'll post it soon.

============================================

V0.1.0 will be

\customize <ID>=<userSymbol>

           htmlTag=<tag>

           params=<class definitions eg: .i.hl.x.y>

           endString=<string>

           use=<userSymbol reference>

Possible IDs: tick, angel, comma, degree, underline

Pragma usage:

\customize tick="§" htmlTag="div" params=".hl"

"In text" usage:

´§ my text comes here. default end is \n

The only ID, that has default end as \n\n is angel. It is intended to style paragraphs. .. All the others are intended to be creative.

have fun!

mario

[TonyM]

Mario

Thanks, Loving it. Like a pig in mud :)

I just realised the >> correlates with \n\n

tick single character with \n is that correct?

Tony

[PMario]

On Tuesday, September 8, 2020 at 4:05:10 PM UTC+2, TonyM wrote:

Thanks, Loving it. Like a pig in mud :)

I just realised the >> correlates with \n\n

yes

tick single character with \n is that correct?

yes

[PMario]

Hi,

V 0.1.0 is uploaded for testing: https://wikilabs.github.io/editions/tick-text/

 - All the pragma names have changed.

 - tag is htmlTag now.

 - Possible IDs: tick, angel, comma, degree, underline

So you can test, what works best for you. ... I'll probably remove some of them in V 1

have fun!
mario

[Mat]

Interesting developments.

\customize is the perfect name for this pragma!

A critical question (which kind of brings back things I stated in the very beginning of this thread/discussion): Who should use this? 

As noted, there's a distinction between tiddlyfiddling/coding vs. notetakeing/authoring. But even for the former, those are very complex pragmas and if one is even supposed to add multiple of them... hmmm. Maybe the whole construct should be a stamp? (But, there's already four from this!)

<:-)

[TonyM]

Mat et all

Please excuse my long winded reply howevery i belive it contains some very powerfull oportunities.

Mario needs to confirm this but as I understand the pragma demonstrates the mechanisium and customisation however the defaults can be used once installed. Especialy my proposed defacto standard for author styles could be used without learning about the pragmas.

How ever if someone wants to build additional wikitext shortcuts or html constructs for their own writting or to provide tools for refactoring external content using the pragmas add substantial features and customation. Pragmas within text help in transferability with the plugin and perhaps the core eventualy the only requirement along with tiddlers self contained pragma.

If you are an author or designer and develop a suite of customised markup or wikitext escape sequences that you want to publish you will need to document and package with the instructions and dependancies just as you may a macro or plugin. I think code clarity can be developed such as using import pragma to rule in a set of custom pragma.

In a recent post Eric provided a CSS solution to customised bullets, subsequently i asked how to stop an inline style tag from impact other tiddlers on screen, the answer is to qualify every class. I realise now that with this new solution we can define the custom styles inline since they can be applied with the tick in the body, and they may only be reflected in applied ticks. This reduces css bleeding into other tiddlers on screen unless they use tick. From this i can forsee the invisible display of pragma and styles hidden on screen that applys to all displayed tiddlers using the defined excapes. I can imagin alternate styling and pragma definitions being used without tiddler changes.

I imagin designers may write a set of pragma and styles that map to different writting or layouts, such as newpaper, magazine, govt documents, scientific papers, (even using additional markup like katex). This why i see value in a de facto perhaps even de jure additional markup pragmas and styles. They would be focused around the kind of elements on page eg block quote, asside, footnote references, bullets, article, section, multiple columns, header, footer, code, warnings and cautions etc... keep in mind that the css content attribute allows unicode icons to be introduced as well. I can forsee someone building a set of pragma and styles that resemble say the dummies and idiots guide books. If your text used the de facto markup pragmas and styles an import pragma would imediatly lay it out similar to a dummies guide.

With all this in mind i think we can come up with a defacto extended markup by starting with identifying evey kind of element not already in wikitext you may choose to use in text and provide a MVP.

We can also support interactive and print ready cases like the details widget transforming to an open text box for print.

It may be easy to build a layout set that makes text look like say wikimedia output. In fact i am not sure but it may be possible to generate output that is infact a reparsing of wikitext into another markup you can copy as text and paste.

further inspired

Tony

[@TiddlyTweeter]

PMario wrote:

So you can test, what works best for you. ... I'll probably remove some of them in V 1 (my emphasis)

Please don't! If anything increase their number to 6 or 8!

I'll explain more later. But the basic reason is this: It would enable users who work in a specific fields to avoid using it for markup if it conflicts  (like the law which extensively uses § & §§) . The simple example is § . It is a vaguely semantic glyph that is great for markup (meaning "section"--i.e. some HTML sector) but let's protect lawyers. Another reason is keyboards, at least in Europe, where many desktops will have some of those symbols but none will have all of them.

Hope this is clear! Its a thought.

TT

[@TiddlyTweeter]

PMario wrote:

V 0.1.0 is uploaded for testing: https://wikilabs.github.io/editions/tick-text/

 - All the pragma names have changed.

 - tag is htmlTag now.

 - Possible IDs: tick, angel, comma,

degree,(my emphasis)

IMO for standard inline markup this is an EXCELLENT choice. Its on many European keyboards. Its on Android keyboard sub-keyboards. 

Additionally its visually nice for Markup Readability. It avoids the issues with readability of quote & accent marks. Its not commonly so often used unless you an industrial chemist or weather fetishist in normal use. 

Just guesses. But I think ° is neat for standard inline markup constructs!

Best wishes

TT

[@TiddlyTweeter]

Mat wrote:

Interesting developments.

\customize is the perfect name for this pragma!

A critical question (which kind of brings back things I stated in the very beginning of this thread/discussion): Who should use this? 

As noted, there's a distinction between tiddlyfiddling/coding vs. notetakeing/authoring.

Mat & PMario

Mat, I think you right to mark that point again.

But I believe that PMario intends that there is a DEFAULT where markup symbols are used for clearly defined action.

The more complex "custom pragmas" enable a lot more. But I think he intends the latter are built on top of the former?

This is just a guess that PMario would know how to answer better than me.

Best wishes

TT

[@TiddlyTweeter]

TonyM & PMario

TonyM wrote:

Is it posible for the user to select the character?

Originally I thought that too! Not now. WHY? Because if you do that it breaks portability.

I think PMario is correct to HARD-CODE the Extended WikiText invoke glyphs because you need a set point so that IF a user installed the tools the characters would be invariant even when you used the tool for very complex machinations.

What I suggested earlier was to expand the total number of glyphs slightly (to 6-8) so that variant types of specialist users can choose markup glyphs that never conflict with their fields of interest.

Best wishes

TT

[@TiddlyTweeter]

This is the big picture ...

What does not exist for prime use is a universal markup font/language.

WikiText gets hampered by "struggling with the remains." (like to find any markup character is a PITA).

In the Future, hopefully, we will have a common, compact, markup system. 

Not yet though. All our current solutions are half-cut because there is no agreed orthodoxy.

Just a comment

TT

[PMario]

On Tuesday, September 8, 2020 at 10:52:59 PM UTC+2, Mat wrote:

Interesting developments.

\customize is the perfect name for this pragma!

A critical question (which kind of brings back things I stated in the very beginning of this thread/discussion): Who should use this? 

From my point of view, the following behaviour is for the default user that wants paragraph indentation

» Some paragraph text which gets some predefined classes, that can be used for styling.

»» An other paragraph text that is indented 2.9em and has the same classes as level 1

For more advanced users

».myClass Some text with myClass assigned

For the lazy folk. The 2 pragmas needed will be 1 line in the next version.

\customize angel=basics params=".myClass"

\customize angel use=basics

» Some text with my Class assigned but with less visual clutter in the prose text

For those who need different configurations with predefined behaviour

\importcustom [[tiddler with my class definitions]]

\customize angel use=basics

» Some text with myClass assigned but with less visual clutter in the prose text

The crazy people (we)

The rest of the functions.

As noted, there's a distinction between tiddlyfiddling/coding vs. notetakeing/authoring. But even for the former, those are very complex pragmas and if one is even supposed to add multiple of them... hmmm.

 

Maybe the whole construct should be a stamp? (But, there's already four from this!)

Some basic stamps yes. But it should work with \importcustom.

-mario

[TonyM]

TT

In my previous reply I suggested with the tick solution in a plugin or core and the defaults used, then it is transportable.

If you use custom definitions the if course they must be included but then they are transferable like the default case.

Otherwise I would like to know if you see any other limits to transferability?.

regards

Tony

[PMario]

On Wednesday, September 9, 2020 at 9:50:14 AM UTC+2, @TiddlyTweeter wrote:

PMario wrote:

 - Possible IDs: tick, angel, comma, degree, underline

So you can test, what works best for you. ... I'll probably remove some of them in V 1 (my emphasis)

Please don't! If anything increase their number to 6 or 8!

You are aware that

\customize tick=a ...

\customize tick=b ...

\customize tick=c ... are completely different "symbol-spaces". So

´a can do something completely different than

´b can be different to b

The only advantage having different IDs is, if they are completely redefined, using the "use" parameter.

-mario

[PMario]

On Wednesday, September 9, 2020 at 10:00:56 AM UTC+2, @TiddlyTweeter wrote:

PMario wrote:

V 0.1.0 is uploaded for testing: https://wikilabs.github.io/editions/tick-text/

 - All the pragma names have changed.

 - tag is htmlTag now.

 - Possible IDs: tick, angel, comma,

degree,(my emphasis)

IMO for standard inline markup this is an EXCELLENT choice. Its on many European keyboards. Its on Android keyboard sub-keyboards. 

I did find all of the possibilities on the Android "sub" keyboards.

 

Additionally its visually nice for Markup Readability. It avoids the issues with readability of quote & accent marks. Its not commonly so often used unless you an industrial chemist or weather fetishist in normal use. 

I think readability also depends on the users tast. I do like the ´´inline´´ definition, but I did consider °°inline°° as an option. (not implemented in V0.1.0)

 

-m

[PMario]

On Wednesday, September 9, 2020 at 10:35:16 AM UTC+2, @TiddlyTweeter wrote:

Mat wrote:

Interesting developments.

\customize is the perfect name for this pragma!

A critical question (which kind of brings back things I stated in the very beginning of this thread/discussion): Who should use this? 

As noted, there's a distinction between tiddlyfiddling/coding vs. notetakeing/authoring.

Mat & PMario

Mat, I think you right to mark that point again.

But I believe that PMario intends that there is a DEFAULT where markup symbols are used for clearly defined action.

That's right.

 

The more complex "custom pragmas" enable a lot more. But I think he intends the latter are built on top of the former?

Yes. At the moment it's still "beta", and it probably will be published as beta-with docs :)

While testing the possibilities I found out, that it should be possible to create something like the new DETAILS hmtl tag, with wikitext markup.

I think that

\importcustom [[Details]]

´details ´summary Details - Summay text
------
line 1
line 2
adsf
---

Is a self describing text and once rendered it does what it says.

After finding out, that DETAILS worked I wanted to be able to find a different way for TW TABLEs. The existing markup is OK for simple tables, but it gets super complex, if you need advanced tables. It breaks, if you need multiline text in a table.

I wanted to fix that. .. With the existing experiments, it seems to be possible for users to dynamically create tables, with existing core widgets.

The naming needs to be improved, but once that's done I think the power is endless.

-mario

[PMario]

On Wednesday, September 9, 2020 at 11:08:27 AM UTC+2, @TiddlyTweeter wrote:

TonyM & PMario

TonyM wrote:

Is it posible for the user to select the character?

Originally I thought that too! Not now. WHY? Because if you do that it breaks portability.

As shown in: https://groups.google.com/d/msg/tiddlywikidev/Os_LCSCP_l8/8RxKeMDIAQAJ

The IDs have to be hardcoded: tick, angel, comma, degree, underline ...

The representations of the IDs have to be hardcoded too. ´, », ,, °, _

The symbol name can be a users choice. so ´a and ´b are completely independent elements.

-m

[PMario]

On Wednesday, September 9, 2020 at 1:54:22 AM UTC+2, TonyM wrote:

We can also support interactive and print ready cases like the details widget transforming to an open text box for print.

Switching from "default" to "open" in DETAILS should be simple, if all tiddlers work with an \importcustom "template" ... You only need to change the template. ... This can be done with the TW --build command. So if you create static pages, that are intended to be printed, you can do that.

-m

[TonyM]

Mario, et al.

FYI: I try and always build solutions that work in both single file and node. In this case I think the class name can be used with @media to respond to the print preview. I will develop the case later, the key idea here is if we make an interactive class, its worth providing an open/print version, or if necessary a mobile version. This is just a design suggestion.

The following helps highlight where in a text you have used tick or angles 

<style>
.wltc { background-color: lightblue; }
</style>

I continue to explore.

Regards

Tony

 

[TonyM]

Mario et al

I just came across this reveal/slideshow plugin;

https://sukima.github.io/tiddlywiki-reveal-js/

The code can be as simple as follows in a self contained tiddler.

<$presentation>
<$slide>Welcome to ''Reveal.js''</$slide>
<$slide>Embedded inside TiddlyWiki</$slide>
<$slide>
  <$slide>Vertical Slides</$slide>
  <$slide>Can also me manged with one level of nesting</$slide>
</$slide>
</$presentation>

In this you can see its one widget $presentation wrapping multiple slide widgets.

I raise this now, although do not want to slow progress, because I wonder if the tick solution could handle, or be made to handle widgets?

<$presentation>
'slide Welcome to ''Reveal.js''
'slide Embedded inside TiddlyWiki
'slide
  'slide Vertical Slides
  'slide Can also me manged with one level of nesting
?
</$presentation>

or similar

Of note the slides do not refresh immediately which may provide a wrapper for iframes to defeat unnecessary refreshes.

Regards

Tony

[TonyM]

Mario,

Forgive this question, because I expect the answer exists in the thread, but do I read it correctly that I can tick my way to a htmltag without a pragma?

eg

'article.classname<space>Content of a html article tag?

I would home it was so because then its easier to use and teach, withyout needing to go into pragmas.

Even 

'article<space>Content of a html article tag?

Would be very powerful in the user uses a css stylesheet to apply to the html tag.

Also is there a reason both tick and angle etc... apply by default the same classes such as 

class="wltc-l1 wltc"

As it would be valuable if there were a class that applied to all tick, all degree and all angels separately along with the existing global class="wltc" 

eg

class="tick wltc-l1 wltc"

Is there relevance to the order here?

Regards

Tony

On Wednesday, 9 September 2020 22:05:00 UTC+10, PMario wrote:

[PMario]

On Thursday, September 10, 2020 at 4:35:24 AM UTC+2, TonyM wrote:

Forgive this question, because I expect the answer exists in the thread, but do I read it correctly that I can tick my way to a htmltag without a pragma?

eg

'article.classname<space>Content of a html article tag?

 

At the moment no. .. It doesn't know if it needs to use block or inline mode. The tick _and_ angle by default are inline functions. Using the mode parameter makes them block functions. .. So you can use eg: ! heading to create a <h1> element. In inline mode it would be rendered as text.

Some elements have a "special" behaviour on their own. ... Will need to test it. Should be easy to implement

I would home it was so because then its easier to use and teach, withyout needing to go into pragmas.

Yea, but the result will be kind of "random" ...

 

Even 

'article<space>Content of a html article tag?

Would be very powerful in the user uses a css stylesheet to apply to the html tag.

Will test it V0.1.1 should have it.

 

Also is there a reason both tick and angle etc... apply by default the same classes such as 

class="wltc-l1 wltc"

Yes. wltc-l1 is a level indicator used for indenting. ... Will only there for "angel" quote, since the others don't have this usecase anymore.

wltc is there for easy debugging. It can be used, with eg: .wltc {border: 1 px green;} so see, where it is used.

 

As it would be valuable if there were a class that applied to all tick, all degree and all angels separately along with the existing global class="wltc" 

eg

class="tick wltc-l1 wltc"

Is there relevance to the order here?

Order is only important in the CSS definition. ... The last one wins

Classes are assigned from right to left ... So in combination with CSS it has a meaning.

So tick can easily overwrite wltc definitions, if it is later in the CSS file.

also see: https://wikilabs.github.io/editions/tick-text/#%3A%2Fplugins%2Fwikilabs%2Ftick-text%2Fstyles the first definition.

-m

[PMario]

On Thursday, September 10, 2020 at 3:35:27 AM UTC+2, TonyM wrote:

...

I just came across this reveal/slideshow plugin;

https://sukima.github.io/tiddlywiki-reveal-js/

I've seen the post, but didn't have a look to the implementation.

 

The code can be as simple as follows in a self contained tiddler.

<$presentation>
<$slide>Welcome to ''Reveal.js''</$slide>
<$slide>Embedded inside TiddlyWiki</$slide>
<$slide>
  <$slide>Vertical Slides</$slide>
  <$slide>Can also me manged with one level of nesting</$slide>
</$slide>
</$presentation>

 

Should be possible to create. Is similar to the DETAILS html tag

In this you can see its one widget $presentation wrapping multiple slide widgets.

I raise this now, although do not want to slow progress, because I wonder if the tick solution could handle, or be made to handle widgets?

<$presentation>
'slide Welcome to ''Reveal.js''
'slide Embedded inside TiddlyWiki
'slide
  'slide Vertical Slides
  'slide Can also me manged with one level of nesting
?
</$presentation>

or similar

We would need to use ´$slide ... to detect the use of a widget if it starts with a $. ... I don't know at the moment how those widgets are called in the parser ... We'll see. 

But it will be interesting. May be in V0.1.1

-------------

I did experiment with calling macros .. That's a complete fail. ... It doesn't work conveniently. It's been removed. I wanted to use it for simple documentation. ... Now the debug mode has to do :/

-mario

[PMario]

Hi,

It's crazy and it works \o/ macro code needed to be changed a little bit.

\customize tick="pres" htmlTag="$presentation" mode=block endString="----"
\customize tick htmlTag="$slide"

\customize angel htmlTag="$slide" mode=block endString="--"

´pres
´ Welcome to ''Reveal.js''
´ Embedded inside TiddlyWiki
»
  ´ Vertical Slides
  ´ Can also be managed with one level of nesting
--
´ End!
´ Have fun!
----

BUT BUT only for simple things. But it's impressive anyway.

-mario

[PMario]

Hi,

I did upload V0.2.0

 - It contains the possibility to use widgets:

   - htmlTag=<widgetName> ...eg:

   - htmlTag="$slide" ...

   - The $ sign is important. It is used to identify the widget.

The "list widget" example has a problem. .. More debugging is needed. ... But the result is impressive. 

-mario

[Mat]

Widgets? What is this? @PMario, could you please show some example using native widgets?

What does it actually do? Style the output from the widget?

Very interesting nonetheless!

<:-)

[@TiddlyTweeter]

Ciao cari

Quick comment

I been working on testing the last release to solve an issue I had for years. 

Looking good.

The tool has a flexibility & utility that is quite surprising!

I think quite a lot more than any of us anticipated!

I will post an example of usage to solve a difficult problem once I have enough content for it to be understandable by others.

Thanks!

& best wishes

TT

[PMario]

On Thursday, September 10, 2020 at 7:05:51 PM UTC+2, @TiddlyTweeter wrote:

 

The tool has a flexibility & utility that is quite surprising!

I think quite a lot more than any of us anticipated!

That's right. It was surprising.

If I did use different IDs I could have made the whole list widget thing into a completely cryptic line of almost nothing.

\customize degree htmlTag="$presentation" mode=block endString="---"
\customize angel htmlTag="$list" mode=block endString="--" filter="[tag[slide]sort[title]]"
\customize tick htmlTag="$slide" mode=block endString="-"

° » ´ <$transclude mode=block /> - -- ---

 

It works and is an equivalent of

<$presentation>
<$list filter="[tag[slide]sort[title]]">
<$slide>
<$transclude mode="block" />
</$slide>
</$list>
</$presentation>

If wikitext {{}} transclusion would have a syntax for block mode, it could be:

° » ´ {{}} - -- ---

That's the highest level of abstraction ... I would love to demonstrate something like this.

It should be less code with importcustom. ... But there seems to be an issue.

I will post an example of usage to solve a difficult problem once I have enough content for it to be understandable by others.

Looking forward to the "problem" and the "solution"

-mario

PS: The latest version V 0.2.3 allows endString to be within the code somewhere. ... No extra line needed atm. .. I'm not sure if this will stay, but it creates cool looking "something" ;)

[PMario]

On Thursday, September 10, 2020 at 6:23:41 PM UTC+2, Mat wrote:

Widgets? What is this? @PMario, could you please show some example using native widgets?

I really need to get the docs going. Sorry! ... It's now possible to call widgets like eg: the <$list filter="[tag[xx]]"/> with pragmas and "tick-like" wikitext.

\customize comma="list-tagged-x" htmlTag="$list" filter="[tag[x]]"

,list-tagged-x <<currentTiddler>>,

does the same thing as:

<$list filter="[tag[x]]"><<currentTiddler>>, </$list>

With better naming of the parameters, the wikitext could be more readable. .... That's not the best example. But it's fun to play with it.

 

What does it actually do? Style the output from the widget?

No it calls the widgets. See above.

-mario

 

[PMario]

On Thursday, September 10, 2020 at 9:43:14 PM UTC+2, PMario wrote:

If I did use different IDs I could have made the whole list widget thing into a completely cryptic line of almost nothing.

\customize degree htmlTag="$presentation" mode=block endString="---"
\customize angel htmlTag="$list" mode=block endString="--" filter="[tag[slide]sort[title]]"
\customize tick htmlTag="$slide" mode=block endString="-"

° » ´ <$transclude mode=block /> - -- ---

Something "bad" needs to happen! I need to rename the pragma parameter names :/

As you can see, the <$transclude mode=block /> widget call has a "mode" parameter. ... This parameter causes a naming conflict with the "mode" param from the pragma. That's why it's impossible to "replace" the transclude widget with a wikitext call.

In Version 0.3.0 all the params will be renamed, like so:

\customize <ID>=<userSymbol>
           cHtmlTag=<tag> .. or <widget-name>
           cParams=<class definitions eg: .i.hl.x.y>
           cEndString=<string>
           cUse=<userSymbol reference>

I did check all TW widgets. There should be no naming conflict with the new names. 

As you can see, there is an other minor issue now. cHtmlTag isn't the right name anymore, since it can be a HtmlTag or a $widgetname 

So a question. Will we keep cHtmlTag or should it be customTag or cTag? 

Feedback please!

-mario

[TonyM]

Mario,

Widgets

There is a lot of serendipity in this "Custom Markup" project, as I said before it is opening up a number of different directions all of which approach infinity. Truly amazing but only possible because of tiddlywikis underlying openness.

• I think it is worth persisting before release so we do not compromise the future possibilities, or release something which is later very different and confuses people.
• Not with standing this perhaps a MVP just for paragraphs and div's plus classnames and no customisation? 
• This could allow a set of companion stylesheets to be build and tested

On parameter names

• Using a naming standard like your proposed one, always makes things harder for me to read, especially coming back to it after some time away, that is the leading c as when I scan wikitext the c interferes with spotting the name
• Have you considered using parameter names with the $ as we do elsewhere to separate it from another fieldname like in the macro-call $name?
  
• .name and _name and others should be possible, perhaps there is a precedent somewhere?
• They will not be used outside the pragma?

On underline

Can I suggest you stop referring to "_" as Underline as it is an underscore, sure wiki text uses double underscore to wrap text and underline it. But the character is underscore and its used to underline in some cases.

On Custom tag

If the one parameter can now be used for html tags and widgets, although they are tags, we do not call widgets tags, perhaps a different name like "element"? which doco will say is a "html tag or widget name" Arbitrary html tags permitted. 

See https://www.w3schools.com/html/html_elements.asp where element is valid for html and not a long way to referring widgets as elements as well, elements beginning "<$elementname" and ending with "</$elementname>"

Other

I wonder if arbitrary widget names can be used?, and by customising we can toggle if that widget introduced by that tick can be disabled/enabled. eg debug mode.

´.debug This when in debug mode like <<transclusion>>

I note that

Top

<$arbitrary>
Content of arbitrary widget
</$arbitrary>

bottom

Produces;

Top

Undefined widget 'arbitrary'

bottom

I wonder if we could toggle this "Undefined widget " message off, when not debugging, on by default.

Regards

Tony

[TonyM]

Mario,

On the demo I spilt [[test-table-1]] so that the customise pragma were in a different tiddler to the table.

Transclusions or import pragma to import the customise code failed to make it work.

Is this just an in progress issue or is it a limitation?

Regards

Tony

[TonyM]

Mario et al,

I was reviewing the current demo, and saw how Mario uses "-" "--" etc... as end string. In this case we have to refer back to the customise pragma

First a question;

• Can a specify endstring "\n" or "\n\n" even "\t" tab? 
• If so I would be happy to forgo the current » for 'p

I was wondering if we could make use of the pair of characters

» alt-175

« alt-174

Such that rather than specify the end string build it from the symbol

\customize angel=row tag=tr mode=block

»row
Row content
«row

Similarly one could allow nesting and auto detection

»table
»»tr
»»»td row detail
»»»td 1 not block
««
«

And inline, thinknig more of my first example.

Blah blah »highlight This is highlighted text« and this is not

It would be easy to have a tool that wraps a selection in 1 2 or more pairs eg »selection« line or block then the user defines each

Or an editor toolbar where on selection you can choose from a list of characters and symbols even depth. »»two deep««

Regards

Tony

[PMario]

On Friday, September 11, 2020 at 4:46:23 AM UTC+2, TonyM wrote:

• I think it is worth persisting before release so we do not compromise the future possibilities, or release something which is later very different and confuses people.

I think °°<symbol>.classes inline°° implementation is missing, but then it should be "feature complete" ... IMO it is already a "monster" and far way from "doing 1 thing well ;)"

• Not with standing this perhaps a MVP just for paragraphs and div's plus classnames and no customisation? 
• This could allow a set of companion stylesheets to be build and tested

That's right. The intro will start with the possibility to "style" default TW paragraphs. .. Show indentation and some "color boxes"

 

On parameter names

• Using a naming standard like your proposed one, always makes things harder for me to read, especially coming back to it after some time away, that is the leading c as when I scan wikitext the c interferes with spotting the name
  

• Have you considered using parameter names with the $ as we do elsewhere to separate it from another fieldname like in the macro-call $name?
  

 OK. $name is established by TW action-widgets, for the exact same reason. So if we would use it, the chance is, that we will get naming problems. ... But I do like the underscore idea. It's not as intrusive as $

• .name and _name and others should be possible, perhaps there is a precedent somewhere?

I think I'll try the _underscore ;)

• They will not be used outside the pragma?

No it's only needed for the \customize pragma. It will allow something like

\customize tick=transclusion _element="$transclusion" _mode=block mode=block

The first mode will be for the pragma and the second for the transclude widget.

 

On underline

Can I suggest you stop referring to "_" as Underline as it is an underscore, sure wiki text uses double underscore to wrap text and underline it. But the character is underscore and its used to underline in some cases.

OK

On Custom tag

If the one parameter can now be used for html tags and widgets, although they are tags, we do not call widgets tags, perhaps a different name like "element"? which doco will say is a "html tag or widget name" Arbitrary html tags permitted. 

IMO _element is OK

 

Other

I wonder if arbitrary widget names can be used?, and by customising we can toggle if that widget introduced by that tick can be disabled/enabled. eg debug mode.

´.debug This when in debug mode like <<transclusion>>

I note that

Top

<$arbitrary>
Content of arbitrary widget
</$arbitrary>

bottom

Produces;

Top

Undefined widget 'arbitrary'

bottom

I wonder if we could toggle this "Undefined widget " message off, when not debugging, on by default.

This info is created at the rendering stage. ... We can't avoid this info, except using valid widget names.

IMO this is an issue for the TW core.

-mario

[PMario]

On Friday, September 11, 2020 at 5:13:33 AM UTC+2, TonyM wrote:

On the demo I spilt [[test-table-1]] so that the customise pragma were in a different tiddler to the table.

Transclusions or import pragma to import the customise code failed to make it work.

pragmas _can't_ be transcluded. \importcustom .. seems to have a problem atm. It only works if you do

\importcustom [[tiddler with pragmas]]

\customize tick=asdf use=<symbol defined in "tiddler with pragmas">

´asdf some text should work.

If you only have

\importcustom [[tiddler with pragmas]]

´asdf some text should work.

It doesn't work atm. .... but it should.

-mario

[PMario]

On Friday, September 11, 2020 at 10:02:38 AM UTC+2, TonyM wrote:

I was reviewing the current demo, and saw how Mario uses "-" "--" etc... as end string. In this case we have to refer back to the customise pragma

That's just my convention. you can use any endString="asdf" if you want.

First a question;

• Can a specify endstring "\n" or "\n\n" even "\t" tab? 

No .. I did test it, and it didn't work. ... There seems to be problems with the core parser functions ... that's the reason why I did name it endString and not end.

• If so I would be happy to forgo the current » for 'p

I was thinking about to double up default "paragraph" related IDs. May be ~

 

I was wondering if we could make use of the pair of characters

» alt-175

« alt-174

Such that rather than specify the end string build it from the symbol

\customize angel=row tag=tr mode=block

»row
Row content
«row

It should be possible if you define your endString="«row"  It should already work that way with V0.2.3 that is online.

 

Similarly one could allow nesting and auto detection

»table
»»tr
»»»td row detail
»»»td 1 not block
««
«

I personally have no idea, what that should do. The following should be possible already, with the online version.

»table
 »tr
  »td row detail

  »td 1 not block



 «tr
«table

Be aware: » works with \n\n .. BUT you can define your endString as you want





If mode=block there needs to be an endString.


 

And inline, thinknig more of my first example.

Blah blah »highlight This is highlighted text« and this is not

°°inline uses degree with the next version°°

»highlight This is highlighted text« .. Some countries use this in valid prose text. So we can't use it


 

It would be easy to have a tool that wraps a selection in 1 2 or more pairs eg »selection« line or block then the user defines each

Yea the °°degree°° will need to get a new toolbar. ... We will need a lot more toolbars. ... But I'll only want to have 1 for each ID and it will only insert the character at the "editor caret" position.

-mario

[TonyM]

Mario,

First I made a mistake and tried to use

\import

Is there a reason we cant use the same mechanisium?

Regardless I did use

\importcustom {{mytablecode}}

and it works well, it also helps limit the applicability while allowing re-usability.

In the same vein would it be possible to tag such a tiddler with $:/tags/Macro or similar to make them global?

• No need to protect the user from redefinition's etc.. style-sheets and existing macros already permit this, it is even safe to call it a feature!
• Perhaps we need to make clear what in a customise pragma will result in redefinition occurring if customised a second time.
• Eg the tick=name 

In the previous reply on widgets

I wonder if we could toggle this "Undefined widget " message off, when not debugging, on by default.

I understand it is a core feature, I just ask if it may be of value to raise an issue?, does it's opening to arbitrary widget names, introduce the ability for "custom markup" to customise, the widget name used, in effect to disable that widget.

Regards

Tony

[TonyM]

Mario,

Quick clarifications,

Similarly one could allow nesting and auto detection

»table
»»tr
»»»td row detail
»»»td 1 not block
««
«

I personally have no idea, what that should do. The following should be possible already, with the online version.

The ides was if you use  » or »» looks for an endString (unless specified the reverse is automatically looked for «« or «. as the end string.

°°inline uses degree with the next version°°

Are you suggesting here double degree, for inline?, single degree for line., I like the look °° and its better than the ugly @@

 

»highlight This is highlighted text« .. Some countries use this in valid prose text. So we can't use it


 

It would be easy to have a tool that wraps a selection in 1 2 or more pairs eg »selection« line or block then the user defines each

Yea the °°degree°° will need to get a new toolbar. ... We will need a lot more toolbars. ... But I'll only want to have 1 for each ID and it will only insert the character at the "editor caret" position.

With building a toolbar, and for the existing buttons, perhaps its fair to place them behind a special dropdown similar to the existing more or stamp buttons. I would be happy if asked to build a content dropdown. This allow a little guidence text against each button anyway.

Tagging it with editor toolbar button will put it on the toolbar anyway.

Regards

Tony

[PMario]

On Friday, September 11, 2020 at 1:00:52 PM UTC+2, TonyM wrote:

First I made a mistake and tried to use

\import

Is there a reason we cant use the same mechanisium?

Yes, there is a reason. \import creates variable widgets for the widget-tree, that are available for rendering

\importcustom creates internal javascript variables, that are used for parsing, for the actual parser instance.

 

Regardless I did use

\importcustom {{mytablecode}}

and it works well, it also helps limit the applicability while allowing re-usability.

importcustom allows to use a filter: so [tag[pragma-config]] will be possible. yours should be [[mytablecode]] .. not a transclusion. ..

I don't know why a transclusion does work. I'll have to have a look what's going on. ... but it's OK that it works :)

 

In the same vein would it be possible to tag such a tiddler with $:/tags/Macro or similar to make them global?

I knew, that this question would come up. But at the moment I don't have a clue, how to make parser-variables global. ... If you write something like this:

<$button> some text here </$button> ... The button widget instantiates a new Parser for "some text here". This is a completely independent memory, that doesn't know anything from the pragma rules at the top of the tiddler :( ... We are at parsing stage ... _not_ rendering!!

And it has to work that way, otherwise <$transclusion/> couldn't be done, because it would bleed side effects into the existing parser instance.

 

• No need to protect the user from redefinition's etc.. style-sheets and existing macros already permit this, it is even safe to call it a feature!
• Perhaps we need to make clear what in a customise pragma will result in redefinition occurring if customised a second time.
• Eg the tick=name 

That's the point. It is not even global to 1 tiddler, because every widget call will create a new parser, that is completely independent.

Widgets do parse their content at rendering time. ... That makes it possible to be dynamic and change attributs. ...

pragmas are like "stamps". Once you defined them, you can use them in the exact same way. You can only change them, if you create a different one.

 

In the previous reply on widgets

I wonder if we could toggle this "Undefined widget " message off, when not debugging, on by default.

I understand it is a core feature, I just ask if it may be of value to raise an issue?, does it's opening to arbitrary widget names, introduce the ability for "custom markup" to customise, the widget name used, in effect to disable that widget.

I'm OK with the "undefined" message, since a user immediately sees, that there is a problem. If we would say nothing and display nothing, those problems can be hidden for a long time and will cause hard to find problems.

 

-mario

[@TiddlyTweeter]

In haste, PMario & TonyM

TonyM wrote:

Mario,

• I think it is worth persisting before release so we do not compromise the future possibilities

I agree. PMario opened a lot of doors. We need time to go through them to TEASE out the power yet ensure workable default behavior.

ONE thing on my mind is INLINE nesting. Current @@ ... @@ prevents it. I'd like time to show how a markup inline of  »...« could support it and correct closure of inlined elements. So »tag-A ...»tag-B ...«« get closed correctly.

Best wishes

TT

[PMario]

On Friday, September 11, 2020 at 1:09:12 PM UTC+2, TonyM wrote:

Similarly one could allow nesting and auto detection

»table
»»tr
»»»td row detail
»»»td 1 not block
««
«

I personally have no idea, what that should do. The following should be possible already, with the online version.

The ides was if you use  » or »» looks for an endString (unless specified the reverse is automatically looked for «« or «. as the end string.

That would dramatically limit the possibilities. ... You can define the endString and you have to. But you can define your endStrings as you want.

 

°°inline uses degree with the next version°°

Are you suggesting here double degree, for inline?, single degree for line., I like the look °° and its better than the ugly @@

At the moment we can use ´´ and °° for inline, because they are not used yet.

V 0.2.3 uses ´´.class some text`` only. ... The goal is to have °°<symbol>.class some text°° where <symbol> is defined with a pragma. .. BUT I'm not sure yet, if this makes sense.

It would make it possible to write something like: °°buttonX some text°° and define a \customize degree-inline ....

The problem is, the inline-rule is completely different than the block detection rule. .. So I don't know if it can handle pragma rules.

-mario

[PMario]

On Friday, September 11, 2020 at 2:26:53 PM UTC+2, @TiddlyTweeter wrote:

In haste, PMario & TonyM

TonyM wrote:

Mario,

• I think it is worth persisting before release so we do not compromise the future possibilities

I agree. PMario opened a lot of doors. We need time to go through them to TEASE out the power yet ensure workable default behavior.

ONE thing on my mind is INLINE nesting. Current @@ ... @@ prevents it. I'd like time to show how a markup inline of  »...« could support it and correct closure of inlined elements. So »tag-A ...»tag-B ...«« get closed correctly.

As I wrote, we can't use single angle quotes, since they are part of standard prose text in some countries.

Both forms are standard like:

»some quoted text« and «some quoted text» in different countries. .. We will need to use double-something.

It may be possible to detect: °°a some text °°b nested text °°b °°a  ... May be!

-mario

[PMario]

On Friday, September 11, 2020 at 2:43:56 PM UTC+2, PMario wrote:

It may be possible to detect: °°a some text °°b nested text °°b °°a  ... May be!

It may be also thinkable to use

°°a some text °°b bbbbbbbbbb-- ---

Where endString for °°b is -- and endstring for °°a is --- ... or

°°a some text °°b bbbbbbbbbb° °° ... So °°b and °   belong together and °°a .. °°   It depends on the user, what they think looks better or is more verbose.

-m

[@TiddlyTweeter]

Ciao PMario

It may be possible to detect: °°a some text °°b nested text °°b °°a  ... May be! 

You probably could but the ISSUE then is the user gets in a fog as the Closure is identical to the Opener. 

NOT good for users doing nesting as their input code is not indicating closure.

Surely this would be better?

I'm styling °.ul in°.red line/°/°

Thoughts before it is too late! :-)

TT

[@TiddlyTweeter]

PMario

This is likely most for YOU :-)

Since HTML is perfectly nested WHY do we need to define closure via "---" or "happyClosure"?

The user should have a  way to mark it, of course...

BUT do they need to define that marker? Surely its implied already by HTML structure? 

That is the basic question.

For instance I start a block § and finish it /§. Now, SAY I NEST a block within it of § nested /§ can't we sort that out through code?--since legal HTML is perfectly nested?

In short, are special closure strings (like "---".) needed? Would not a standard open symboil/close symbol PAIR work better?

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

Best wishes

TT

[@TiddlyTweeter]

Ciao PMario

My point before that we have REDUNDANT characters so we can address internationally a user can use some not all.

They chose for EACH MAIN MARKUP between two options.

Portability would be adequate

I will comment separately on "escape".

The BASIC issue is this: Getting stuck in a limited approach to keep Euro keyboards happy could damage code thinking.

You get the point? Ask if its not clear.

I'm sure we can work round it.

Best wishes

TT

[PMario]

On Friday, September 11, 2020 at 3:21:44 PM UTC+2, @TiddlyTweeter wrote:

Since HTML is perfectly nested WHY do we need to define closure via "---" or "happyClosure"?

Because there is a default endString, that you don't see.

angel ID uses \n\n and all the others IDs use \n. ..

That's also true for every <symbol>. ... Since it makes sense. eg:

100 lines of text copy pasted from somewhere.

line 1

line 2

line 3

:

line 100

If you want every line to be something special you just add an eg: tick ´  at the start of the line.

´ line 1

´ line 2

´ line 3

:

´ line 100

If the first line should be "special" and some of them should be indented you can add:

´special line 1

´.i line 2

´.i.i line 3

:

´ line 100

If the endString would be /´ you'd need to modify every single line with an endString too. ... That's not part of the "very first" initial goal, why the project exists at all. ... It needs to be fast.

I did create the "Add a new-line at the end of the line" toolbar button, that will double up every existing \n to convert a marked block of text into html P tags.

This will allow us to use the "angel quote" in a second step.

 

The user should have a  way to mark it, of course...

BUT do they need to define that marker? Surely its implied already by HTML structure? 

No html involved at this stage. We are at wikitext parsing stage.

 

That is the basic question.

For instance I start a block § and finish it /§. Now, SAY I NEST a block within it of § nested /§ can't we sort that out through code?--since legal HTML is perfectly nested?

html-parser is a completely different thing, then wikitext parser. Wikitext typically only has a start-info eg

! heading 1

We detect an exclamation mark at the beginning of the line and assume the endString is \n. The result of our parser findings are written to the parse-tree.

That's exactly how the default "tick" and all the others works.

 

In short, are special closure strings (like "---".) needed?

If you want to combine more than 1 line ... yes. The endString only defines the end of the block. It will be rendered in "inline" mode. If the parameter mode=block is set, it will be rendered as block mode.

 

Would not a standard open symboil/close symbol PAIR work better?

IMO not really. If you want to work with <html> tags, then you should use <html> tags. ... right?

One goal is, that the "prose text" is readable and it should be possible to abstract the "distracting" elements away.

eg: Insert a list of tiddlers tagged "x":

°list-tagged-x

Some more text

--------------

I think this is much more readable then the construct that is needed using the <$list widget. .. The disadvantage is, that we need pragma definitions. 

A macro call would do the same thing <<list-tagged "x">> and would also be dynamic. ...

So in this special case I'd use the macro. In other cases the pragma way win. --- We will see!

mario

[PMario]

On Friday, September 11, 2020 at 3:58:51 PM UTC+2, @TiddlyTweeter wrote:

My point before that we have REDUNDANT characters so we can address internationally a user can use some not all.

They chose for EACH MAIN MARKUP between two options.

Portability would be adequate

I'm thinking about a possibility to disable the markup on a "per ID" basis. So it may be possible to say:

\rules except customtick customdegree

To disable elements per tiddler. Or to use the ControlPanel : Info : Advanced : Parsing tab. .. At the moment there is only ticktext which will disable all of them.

We do have

 - 3 pragma rules: customize , debugcustomize,  importcustom

 - 1 inline rule: tickinline

 - 1 block rule: ticktext

The block rules should be

 - customtick

 - customdegree

 - customcomma

 - customunderscore

 - customangle

 - customtilde ..... may be I'll this one as default endString \n\n too

I need to have a closer look if that's possible, without duplicating any code js.

-mario

[TonyM]

Mario,

It is good to state and restate the current state of play on this one. So thanks for your summary.

I am not sure, but I wonder if we are on the same page, most likely, but it is worth checking on the original paragraph suggestion;

My feeling this needs to be very precise because its not so easy to express this.

This is what is making me unsure, around the \n and \n\n cases;

I did create the "Add a new-line at the end of the line" toolbar button, that will double up every existing \n to convert a marked block of text into html P tags.

Is this so you can take multiple lines and combine them into one paragraph?

• so you use \n\n as the end of block "endString"? 
• Is this why you started using div for blocks because P separated every line?

The reason I wanted to do this based on \n only is as follows;

• if \n can be used as the end string to create a paragraph, once a paragraph is created there is always a blank line that follows that paragraph, HTML standard with P
• if there is a second or third \n, ie blank lines and you apply the same prefix to each then please follow what happens below;

Original text

Paragraph


penultimate paragraph
Last paragraph

In this example I use 'p to represent the custom tick for paragraph

Individually or bulk inclusion of the 'p<spaces> to every line gives

'p Paragraph
'p
'p
'p penultimate paragraph
'p Last paragraph

Becomes on render

<p>Paragraph</p>
<p></p>
<p></p>
<p>penultimate paragraph</p>
<p>Last Paragraph</p>

And is displayed as

Paragraph

penultimate paragraph

Last paragraph

ie: multiple blank lines are collapsed to a minimum of 1 blank line, missing blank lines become a minimum of 1 blank line (are added in the HTML render step by the rules of html P)

It seems to me that my use case exclusively needs only \n as the end string, it's when you wish to block format such as a div that this changes, and where we may want to have an alternative end string such as \n\n, 

• Are you placing "\n\n" in the content effectivly so you can use it as an end string?
• Or Can you NOT rely on the \n\n in the content in many cases, thus you need to add it?

Given we can now specify the end string, perhaps the default behaviour should be endstring "\n" on newlines (visible or not). After all this is what confuses everyone new to tiddlywiki, ie when using line based wiki text the line feed is honoured

eg * # ! a newline is created, but any "free text" ends up concatenated with the content above and the (first) new line hidden.

It seems to me that given the value of a 'p to resolve this issue, with line breaks, just as every other wikitext special character does as well, 

• but in this case on any/every line then this should be a primary focus, 
• with the \n\n cases only secondary?

Restated, we need to fix the fact that in the editor

This is a line or paragraph
This is another line or paragraph

Automatically becomes

This is a line or paragraph This is another line or paragraph

And

This is a line or paragraph

This is another line or paragraph

Looks the same after render

Note: There is no way to display this as entered (without workarounds)

This is a line or paragraph
This is another line or paragraph

I have chosen to use paragraphs to help when the content has many extra line breaks, but other html tags will deliver the output as seen in the editor text.

• Note this is \n in action not \n\n

I hope this is clearer.

As a mentor once said to me if you perceive a problem then consider some possible solutions then come to me with the "problem and possible solution", not just the problem. So I will try.

Thanks

Tony 

[TonyM]

FYI

This below demonstrates in every wiki that the selected special characters can be or be contained in macro names.

I have used ~ in the past to represent the current tiddler title, as occurs in dictionaries and other reference material.

\define ´() tick ´
\define _() underscore _
\define ,() comma ,
\define ~() tilde ~
\define °() degree °
\define »() angle »
* <<´>>
* <<_>>
* <<,>>
* <<~>>
* <<°>>
* <<»>>

Why,

Because if one wanted a macro version or extended functionality it is possible to have a macro that maps to such symbols.

Regards

Tony

On Tuesday, 8 September 2020 06:39:57 UTC+10, Mat wrote:

Last thread paginated.

Apropos what character is appropriate for PMarios construction, PMario wrote:

I'll be happy to change it, if someone has a good idea.

I think proper keyboards should be prioritized here, not "screen keyboards" because presumably most people do their full blown wiki editing on real keyboards, not on their their phones.

The generic currency symbol i.e  ¤  can be found on a few keyboards, including both Swedish and the Tastaturbelegung_E2 ;-)

<:-)

[TonyM]

FYI 2

I note the pre-release says 

• Extended the internal <$element> widget to add a hook so that plugins can intercept DOM node creation

Just mentioning because we are considering the "element" parameter. I doubt there is an issue

Tony

[PMario]

On Saturday, September 12, 2020 at 12:26:14 AM UTC+2, TonyM wrote:

This is what is making me unsure, around the \n and \n\n cases;

I did create the "Add a new-line at the end of the line" toolbar button, that will double up every existing \n to convert a marked block of text into html P tags.

Is this so you can take multiple lines and combine them into one paragraph?

No. If I want to combine multiple lines I remove the single line break. ... Except for the last one it gets 2.

• so you use \n\n as the end of block "endString"? 

That's the default behaviour of TW. 2 newlines give a P tag. Angle qoute internally uses \n\n .... All the others use \n

• Is this why you started using div for blocks because P separated every line?

1 newline gives a DIV, that is styled with the same margin-top and -bottom as a P tag. I used a DIV, because it is more flexible with valid html content.

If you create a <p><div>....</div></p> you create an invalid html structure, because P tags should only contain "phrasing content". .. Sure browsers show it, but technically it is wrong.

 

The reason I wanted to do this based on \n only is as follows;

• if \n can be used as the end string to create a paragraph, once a paragraph is created there is always a blank line that follows that paragraph, HTML standard with P
• if there is a second or third \n, ie blank lines and you apply the same prefix to each then please follow what happens below;

try the following lines in 0.2.3 and you'll see, it works as you expected. .. There is no need to add ticks to empty lines.

´ line 1
´ line 2


´ line 3

 

In this example I use 'p to represent the custom tick for paragraph

Individually or bulk inclusion of the 'p<spaces> to every line gives

'p Paragraph
'p
'p
'p penultimate paragraph
'p Last paragraph

Becomes on render

<p>Paragraph</p>
<p></p>
<p></p>
<p>penultimate paragraph</p>
<p>Last Paragraph</p>

The actual code doesn't work that way anymore. ... Have a closer look.

 

[...]

It seems to me that my use case exclusively needs only \n as the end string, it's when you wish to block format such as a div that this changes, and where we may want to have an alternative end string such as \n\n, 

Yes. That's your usecase. But in my texts there is no single linebreak for a pragraph. If I do have 1 newline, I will double it. So TW will create P tags. Those P tags will be styled using the "angle quote".

 

• Are you placing "\n\n" in the content effectivly so you can use it as an end string?

Yes. That was the reason for the toolbar button.

• Or Can you NOT rely on the \n\n in the content in many cases, thus you need to add it?

If there are 2 newlines it's OK, if there is only 1 I'll add more or remove it. ... That's how it works for me.

 

Given we can now specify the end string, perhaps the default behaviour should be endstring "\n" on newlines (visible or not). After all this is what

 confuses everyone new to tiddlywiki, ie when using line based wiki text the line feed is honoured

Most wikitext parsers works that way. That's not specific to TW. 

eg * # ! a newline is created, but any "free text" ends up concatenated with the content above and the (first) new line hidden.

That's the default behaviour of every wikitext engine. It's the same behaviour for most markdown parsers. There is only 1 exception "markdown github flavour".

Even the new Commonmark spec uses this behaviour. Have a look at the "soft linebreak" ... scroll up a little bit and you'll see "hard linebreaks" definition.

 

It seems to me that given the value of a 'p to resolve this issue, with line breaks, just as every other wikitext special character does as well, 

• but in this case on any/every line then this should be a primary focus, 
• with the \n\n cases only secondary?

That's you point of view. --- From my point of view it's completely different. I don't have blocks of text with only 1 newline. And if I have them I either need to remove them or make 2 to indicate a new paragraph. (Single newlines are poison for me. They will create problems in the future. Trust me. I remove them, or use 2! Always)

 

Restated, we need to fix the fact that in the editor

This is a line or paragraph
This is another line or paragraph

Automatically becomes

This is a line or paragraph This is another line or paragraph

No. That's OK and standard. TW core will not change this and it shouldn't. HTML ignores \n characters completely and there is a reason! They use CSS settings to show hard-line breaks. .. That's OK. We can do so now.

´ This is a line or paragraph

´ This is another line or paragraph

And

This is a line or paragraph

This is another line or paragraph

Looks the same after render

If we use ticks now. ... Yes.

Note: There is no way to display this as entered (without workarounds)

This is a line or paragraph
This is another line or paragraph

 Sure. Just change the CSS settings and you are good to go.

I have chosen to use paragraphs to help when the content has many extra line breaks, but other html tags will deliver the output as seen in the editor text.

• Note this is \n in action not \n\n

I hope this is clearer.

I think I know what you want, and all the IDs work that way. .. Except the "angle quote". It works with \n\n by default, because I need it that way to indent and style TW paragraphs. 

As a mentor once said to me if you perceive a problem then consider some possible solutions then come to me with the "problem and possible solution", not just the problem. So I will try.

As I wrote. It seems my workflow is completely different to yours. But that's OK. With the "tick-text" plugin I think we both can have what we wanted and much more.

have fun!

mario

[PMario]

On Saturday, September 12, 2020 at 2:06:01 AM UTC+2, TonyM wrote:

I note the pre-release says 

• Extended the internal <$element> widget to add a hook so that plugins can intercept DOM node creation

Just mentioning because we are considering the "element" parameter. I doubt there is an issue

There should be no problem. I'm using _element now.

-m

[PMario]

Hi,

New version V0.3.0 uploaded. It uses new parameter names

\customize <ID>=<userSymbol>
           _element=<tag>
           _params=<class definitions eg: .i.hl.x.y>
           _endString=<string>
           _use=<userSymbol reference>
           _mode=<block / inline=default>

Known issues

 - There are some examples, that don't work. 
 - 1 "aside" example floats outside the tiddler "frame"
 - importcustom needs some improvements. 

But I hope we don't have to change the parameter names again. 

-mario


 

[TonyM]

Mario,

Thanks for your extensive reply, a few notes: These alternate work flows and emphasis will most likely be accommodated, but to be clear on my own perceived need, some comments.

try the following lines in 0.2.3 and you'll see, it works as you expected. .. There is no need to add ticks to empty lines. 
´ line 1
´ line 2

´ line 3

I come from the opposite position, I want to be able to "select all" and apply tick, so I am happy for every line to have it, so I do not need to add ticks selectively. Although I may go through later and remove them or add content.

• Unfortunately I can no longer see how to achieve this in the latest version even with customisation and especially if I use the tick or angle buttons and there are blank lines in the select.

I understand the issues with \n and \n\n so I am researching this a little more.

• One use that may differ from your own is I have recently started writing a book and generating copy for another book. 
• As a result I edit to author the content, and only when I am happy, I work through and decide the headings and emphasis etc. 
• That is the content entry is a separate step, to the finessing of its display. Sure I use bullets headings etc... if I know that is what I will use. 
• When one is dumping ideas, needing to think too much about how you are typing, gets in the way of creative output.
• But If I am not using a wikitext prefix (only) the result is either unwanted concatenation in view or unwanted additional lines "\n\n" in the raw editor.
  

And also In reality a lot of editors especially WYSIWIG, word as an example places a Paragraph marker in the content when one hits enter. 

• In word processors You have to shift-enter to insert a new line only.
• It may be standard to do <enter><enter> in Wikitext and markup but this is not intuitive for those not used to writing in markup or some programming.
• Perhaps a toggle between the enter key returning one or two new lines, perhaps we call 2 newlines "paragraph break" in wiki text.
• Or I could use a keybord shortcut tool to make my numeric pad enter generate \n\n as a paragraph break?

On data entry or writing in wiki markup.

• If I am typing away, and I have entered a set of lines, that I may latter apply tick to, to turn into a paragraph or div, section or article or even simple bullets, 
• I have already followed each line with a new line, perhaps this is good enough as a draft effort, however when I change to view it all collapses/concatenates to an unreadable single paragraph.
• This forces me at writing to either prefix with tick etc... or use "\n\n" from the get go, its forcing me to think about my layout while entering text.
• Perhaps a button on a tiddler in view mode, could toggle if collapses/concatenate lines occurs in the view?

Yours Sincerly,

Somewhat lost again

Tony

[PMario]

On Saturday, September 12, 2020 at 4:12:52 AM UTC+2, TonyM wrote:

Thanks for your extensive reply, a few notes: These alternate work flows and emphasis will most likely be accommodated, but to be clear on my own perceived need, some comments.

try the following lines in 0.2.3 and you'll see, it works as you expected. .. There is no need to add ticks to empty lines. 
´ line 1
´ line 2

´ line 3

I come from the opposite position, I want to be able to "select all" and apply tick, so I am happy for every line to have it, so I do not need to add ticks selectively. Although I may go through later and remove them or add content.

• Unfortunately I can no longer see how to achieve this in the latest version even with customisation and especially if I use the tick or angle buttons and there are blank lines in the select.

I think that's an issue now. I'll have to investigate.

 And also In reality a lot of editors especially WYSIWIG, word as an example places a Paragraph marker in the content when one hits enter. 

Yes. That's OK. 

• In word processors You have to shift-enter to insert a new line only.

Yea, and that's the point. In my world, there is _no_ shift-enter in a paragraph. Most of the time, they only cause problems later, when the text is revised or if it needs to be translated by a 3rd party and so on. ... I can live best without them. There are very rare cases I need one.

• It may be standard to do <enter><enter> in Wikitext and markup but this is not intuitive for those not used to writing in markup or some programming.

 I don't know. If I want to set 2 paragraphs of texts apart in a standard text editor, I have to type 2 <enter>.

• Perhaps a toggle between the enter key returning one or two new lines, perhaps we call 2 newlines "paragraph break" in wiki text.

We do. .. That's how TW works since the beginning. There are more and more users coming from the markdown-side of things. They do have the same behaviour.

I know, that many users want hard linebreaks. .. That's why the plugin will ship with a class definition, that will easily let them do this. eg:

».hl line 1

line 2

If you copy the above 2 lines into https://wikilabs.github.io/editions/tick-text/ it will work just fine.

• Or I could use a keybord shortcut tool to make my numeric pad enter generate \n\n as a paragraph break?

If it works for you. Fine. 

On data entry or writing in wiki markup.

 

If you generally need hard line-breaks you can use the existing suggestion from tiddlywiki-dot-com. Then it would only need a tag, instead of ticks.

As I remember, the initial goal was to use ticks if long texts are copy pasted from other resources.

 

Yours Sincerly,

Somewhat lost again

hmmm, That shouldn't be the case.

If you copy this to the page

».hl line 1
new line
new line

You get 1 paragraph with hard linebreaks. If you copy these

´ line 1
´ new line
´ new line

You get 3 DIVs, that are styled like paragraphs.

That's exactly what you wanted. The toolbar buttons have to be fixed for the new behaviour, but that's probably a fast fix.

-mario

[PMario]

On Saturday, September 12, 2020 at 4:12:52 AM UTC+2, TonyM wrote:

Thanks for your extensive reply, a few notes: These alternate work flows and emphasis will most likely be accommodated, but to be clear on my own perceived need, some comments.

try the following lines in 0.2.3 and you'll see, it works as you expected. .. There is no need to add ticks to empty lines. 
´ line 1
´ line 2

´ line 3

I come from the opposite position, I want to be able to "select all" and apply tick, so I am happy for every line to have it, so I do not need to add ticks selectively. Although I may go through later and remove them or add content.

• Unfortunately I can no longer see how to achieve this in the latest version even with customisation and especially if I use the tick or angle buttons and there are blank lines in the select.

This was a bug. We need to "rethink" the toolbar buttons. The next version should have something more powerful.

The next version will get:

1 ... Add an additional new-line to every selected line

2 ... Add an angle bracket + a <space> at the beginning of selected lines

3 ... Add a the pattern selected in 5 at the beginning of selected lines

4 ... Remove any pattern from the beginning of the selected lines

5 ... The dropdown to select a pattern eg:

`.i.c.cs.j.r some text  The whole string at the start of the line can be inserted. The user can define new elements that should be part of the dropdown. 

This function is similar to the stamp utility.

I need to make the dropdown more informative. .. But it should be uploaded soon.

-mario

[PMario]

Hi,

If empty lines are selected, they don't get a marker anymore. They will stay empty.

-mario

[TonyM]

Mario,

If empty lines are selected, they don't get a marker anymore. They will stay empty.

Is there a way I can force this? I want empty lines to get a special character, that is honoured, if at all possible!

• Even if I need an alternate approach, or a special character for it.
• This worked, perhaps as a side effect earlier, but It was a key desire of mine
• The original idea was that a leading dot created a paragraph, out of each line (terminated by \n), in this case I assumed empty lines beginning dot would also be honoured.
• I did state the reason before
  
• but in short we can apply a .classname to any wiki text character, and now with tick etc to any line
• But you are saying "not blank lines", so it is no longer "any line"!
• I often harvest text from other sources, I want to be able to force every line to be a paragraph as they often have unnecessary line breaks.
• Or more to the point I would like to prefix all lines with a special character and have a custom element or classnames assigned to every line, no exceptions like blank lines.
• I would prefer it to be an option in this solution, because it makes sense to be there.
  
• It is a desirable feature for the whole tick solution, for example 
• CSS may be included to generate line numbers in a code display, this means counting blank lines as well.
• I may use this to display an <enter> in a view that shows special but invisible characters like \n or \n\n as ¶ \t and more
• Not if I can't apply to blank lines?

yours sincerely

Tony

[TonyM]

Mario,

Yes these Editor Tool bar features will be very helpful.

I thought of a generic one;

• Select the character, select the element and any parameter and click to apply to selected lines (ending \n OR \n\n)
• This could be extended to add class names to existing wiki text like *.classname <space> by making * available as well.
• Perhaps a different tool, but very close to what you are working on.

Great work

Tony

[@TiddlyTweeter]

Ciao PMario & Tony

Broad comment. Important, I think.

PMario has abstracted WikiText and reapplies it. 

In regular TW we have standard situations recognized via \n[^\n] = ONE LINE BREAK without a second and \n\n+= ONE PARAGRAPH.

But HTML does not care about space at all.

The issue is this: What WikiText syntax for complex markup is most compact given PMario's abstractions?

To help understand my point ... PMario is JUGGLING older style WikiText with, basically, a FREER WikiText (more potentially prone to problems; but X-FACTOR BETTER for compact REAL writing).

What is my point?

It is simply that there is BOTH code developing but also a "PHILOSOPHY" of INTENT.

I want to encourage PMario NOT to cut off serious questions his approach enables that current WikiText does not go to. 

Let us NOT compromise extension of FUNCTION be being SLAVES to continuity.

An example is obviously INLINE WikiText. Currently it is crude, verbose & not particularly efficient. His revised understanding would permit NESTING and more compact code (NOT XXtextXX, but Xtext/X and nested XtextXtext/X/X).

Conceptual innovation it useful practically! :-)

Thoughts

TT

[@TiddlyTweeter]

Ciao PMario

Your good reply helps me restate the issue ...

1 - IN Tiddler markup characters should NOT conflict with reasonable USE cases.

2 - GIVEN that available characters (i.e. available in all common fonts ... or ... for liberal basic setups]) are FINITE, provide user CHOICES within the limited repetiore of characters.

3 - ... THEN (1) is addressed IF the characters available in (2) are sufficient.

Hope this is clear and logical!

TT

[@TiddlyTweeter]

Ciao PMario

Probably more for you than the others :-)

I'm sure that a reason for DOUBLING in INLINE markup is simply that in ...

Text XXteXtXX

... the single "X" character can be used without escape, as in teXt.

An alternative that is worth attention is simply ...

Text Xte\Xt/X

 Where, rather than need an override "\rule" ... "\X" is a simple escape inline without need of understanding rules.

Seems pretty compact to me and can help avoid visually inelegant DOUBLING. 

Just comments

TT

[PMario]

On Sunday, September 13, 2020 at 2:11:00 AM UTC+2, TonyM wrote:

Mario,

If empty lines are selected, they don't get a marker anymore. They will stay empty.

Is there a way I can force this? I want empty lines to get a special character, that is honoured, if at all possible!

It's not necessary. Try the following code in 0.3.0

´p line 1


´p line 2
´p line 3

You'll see, that it works as you expect it, in terms of distance between "paragraphs". .. Without the problem to produce 2 empty Ps. 

The problem with empty html elements is, they are invisible .. sometimes ... but as soon as a user defines a CSS definition, that makes them visible, you have a problem. ...The "misused" empty Ps are now visible, and will completely confuse users. .. Because the plain text contains "no content" lines. ... Why does the rendered HTML show something ...

eg:

<p>paragraph 1</p>
<p></p>
<p></p>
<p>paragraph 2</p>
<p>paragraph 3</p>

There is nothing visible in between paragraph 1 and 2 at first ... BUT in reality there is.  Now try this:

<style>
p {
  border: 1px red solid
}
</style>

<p>paragraph 1</p>
<p></p>
<p></p>
<p>paragraph 2</p>
<p>paragraph 3</p>

-----

´p line 1


´p  line 2
´p  line 3

You will immediately see, that the Ps look completely ugly. ... And look how clean the tick configuration is.

You'll also see, that the TW UI in the right sidebar has a P problem. It makes styling of the UI elements extremely unpleasant for theme authors. Because there are a lot of elements, that shouldn't be there at all.

So misusing Ps isn't a way to go. .. I can't. It produces a lot of maintenance and support requests in the future. .. And it isn't necessary as you can see.

I did adjust the toolbar buttons that their behaviour fits the parser rules.

I need to read your post again, to see, if I've missed something.... But I don't think so.

-mario

[PMario]

On Sunday, September 13, 2020 at 2:11:00 AM UTC+2, TonyM wrote:

• I often harvest text from other sources, I want to be able to force every line to be a paragraph as they often have unnecessary line breaks.

• Or more to the point I would like to prefix all lines with a special character and have a custom element or classnames assigned to every line, no exceptions like blank lines.

What do you mean with "special character"? .. If it is a "non whitespace" character it can be prefixed.

-m

[PMario]

I will add "forced" ticks. There was a problem in the parser, which couldn't do

´

´

´p some text

But the default buttons will ignore empty lines for selections. ... But I'll add an option to the dropdown, to allow "ticking" empty lines.

May be the toolbar button configuration needs some more parameters.

-mario

[Mat]

Hi guys. I've lost track of this discussion. Is there documentation now? What's the best demo (perma-)link, if any?

Is there any issue where my input could contribute value?

Thanks!

<:-)

[PMario]

On Sunday, September 13, 2020 at 9:40:07 PM UTC+2, Mat wrote:

Hi guys. I've lost track of this discussion. Is there documentation now?

Not really. In the last Version 0.3.0 the parameter names changed completely, because I discovered a naming problem with the <$transclusion mode parameter. .... We use _mode _xxx for the \customize pragma. This should avoid naming problems using TW widgets.

There is still some usability discussion going on, since Tony's and my workflow seem to be "different" ;) ... but that makes it interesting. I think in the end the plugin will cover more usecases and should be more consistent.

I also found a bug in 0.3.0 that should be fixed in 0.3.x but I have to redo the toolbar icons + keyboard shortcuts. They don't fit the actual state of the functions anymore.

This post https://groups.google.com/d/msg/tiddlywikidev/Os_LCSCP_l8/G4cjvnE2BAAJ will give a mini overview about the next version. I need to redo the svg icons since they are also obsolete now.

 

What's the best demo (perma-)link, if any?

At the moment the best way is to open the "new" tiddlers and see, how the code looks like. ... But many of them work with "edge cases" and are probably not relevant for standard users.

Is there any issue where my input could contribute value?

I'll need some time to make the workflow pleasant again. At the moment it's a little bit bumpy.

Especially making the different IDs like tick and angel easily available is the biggest problem. I try to solve this using a "small" set of new toolbar buttons.

 

Thanks!

-mario

[TonyM]

Mario,

Thanks soo much

Tones

[PMario]

Hi folks,

There is a new version V0.3.1 at: https://wikilabs.github.io/editions/tick-text/

It contains some Basic Docs. A little bit of reference docs a TOC in the right sidebar.

The new toolbar

Line prefixes can be defined using tiddlers tagged: $:/tags/TextEditor/LinePrefix

The "Add your own" can add new ones similar to the "stamp" function

The ID selector can define the IDs. and

The checkbox "use in empty lines" is for Tony ;) ...

The "+-" button mean "toggle"

And >> + and >> -  allow to add several of them.

The "All -" will remove every custom markup at the beginning of the line.

have fun!

mario

[PMario]

Uups,

Forgot to say: Keyboard shortcuts are not properly set yet. will be the next step

-m

[Mat]

PMario - thanks for updates. I just tested the latest. When clicking something in the dropdown, e.g "Colorbox danger" there's a "Copied to clipboard" message but no visible change in the edited text. I was expecting some prefixing ticks with classnames, and no "Copied to clipboard" message.

If I recall, the tick was to make a div and the angle quote to make a <p>... so what do the other characters do? Or maybe the fact that there is a double pipe in the dropdown is meant to separate the optional "div characters" from the optional "p characters"? If they in deed are options for the same thing, I'd suggest a selectbox instead of radio buttons. The select box is uglier but I would not think people change their chosen indicators much so there's no reason to have them permanently exposed. 

For the docs, it would make sense with a very first tiddler to read that that gives a quick overview. Currently the "Basics" tiddlers are alphabetically sorted so it is not clear if there's an order to them.

<:-)

[PMario]

V 0.3.2 is online ... More docs!!!!

On Tuesday, September 15, 2020 at 2:47:39 PM UTC+2, Mat wrote:

PMario - thanks for updates. I just tested the latest. When clicking something in the dropdown, e.g "Colorbox danger" there's a "Copied to clipboard" message but no visible change in the edited text. I was expecting some prefixing ticks with classnames, and no "Copied to clipboard" message.

The dropdown is "just" a selector. You need to click the button left. .. Same as with the "preview" button.

It copies the "config string" into the clipboard, because it's convenient to work with CTRL-V without the need to select and copy something.

 

If I recall, the tick was to make a div and the angle quote to make a <p>... so what do the other characters do?

Yes. All the others make DIVs and the "tilde" will make a P (tilde not implemented yet)

 

Or maybe the fact that there is a double pipe in the dropdown is meant to separate the optional "div characters" from the optional "p characters"?

Exactly!

 

If they in deed are options for the same thing, I'd suggest a selectbox instead of radio buttons.

Hmmm, "select" is hidden information, that I don't like. .. We'll see.

 

The select box is uglier but I would not think people change their chosen indicators much so there's no reason to have them permanently exposed. 

We'll see what others say. ... Nothing is "set in stone" atm.

 

For the docs, it would make sense with a very first tiddler to read that that gives a quick overview. Currently the "Basics" tiddlers are alphabetically sorted so it is not clear if there's an order to them.

The new order is the "how you should read it". Internal linking also gives you a hint.

-mario

[PMario]

On Tuesday, September 15, 2020 at 2:47:39 PM UTC+2, Mat wrote:

[...]

For the docs, it would make sense with a very first tiddler to read that that gives a quick overview. [...]

http://localhost:8080/#Custom%20Wikitext%20Markers is the first tiddler that gives an overview about the Plugin. The edition needs to start at the beginning.

-m

[PMario]

uups, wrong link in the last post.

Here's the right one: https://wikilabs.github.io/editions/tick-text/#Custom%20Wikitext%20Markers

-m

[TonyM]

Mario

I just started reviewing the new version, thanks for you work, and accommodating my desire to affect every line (optionally)

• Perhaps rather than "use in empty lines" you could say "all lines" or reverse and say "Lines with content only" that one turns off if then need to do what I want.
• Alternatively a toggle button "All lines" on/off and gives you a tool tip to explain.
• I think the "ID - Alone" would be better as "ID - only"
• When you do copy to clipboard it would help if there were a training space.
• If you highlight a set of lines an + angle brackets twice something interesting but incorrect happens

» How to style a Paragraph
» Misusing standard wikitext to indent a paragraph
» Custom Wikitext Markers
» Easy styling for Paragraphs
» More CSS Details
» About Colour Boxes
» Basics for advanced users

and Again

»» How to style a Paragraph
»»» Misusing standard wikitext to indent a paragraph
»»»» Custom Wikitext Markers
»»»»» Easy styling for Paragraphs
»»»»»» More CSS Details
»»»»»»» About Colour Boxes
»»»»»»»» Basics for advanced users

What If I wanted ?

»» How to style a Paragraph
»» Misusing standard wikitext to indent a paragraph
»» Custom Wikitext Markers
»» Easy styling for Paragraphs
»» More CSS Details
»» About Colour Boxes
»» Basics for advanced users

Review notes continued

• I love the - All button, cool. Refresh or reverse using these tools1
• $:/plugins/wikilabs/tick-text/EditorToolbar/toggle-tick should probably be "Toggle ID" because tick is but one
  
• $:/plugins/wikilabs/tick-text/EditorToolbar/preview-type is wrong names, has the wrong caption etc... perhaps "select ID"
  

My Review continues.

I hope this helps so far?

Tones

[TonyM]

Mario,

Continues review notes;

• Perhaps the select ID drop down could include "Sets {{toolbarIcon}}" so it is clear once set you highlight your lines and use the toolbarIcon
• The copy to clipboard is a great feature, but initially it looks like the only feature of the drop down.
• Perhaps giving both tick toolbaricon and dropdown the same color would help?
• I will start a new post because Google Groups formatting has gone mad on me

Notes:

Add new line - extra use?

What was you desire for the add new line option mario?

I was testing and I had this

´p How to style a Paragraph
´p Misusing standard wikitext to indent a paragraph
´p Custom Wikitext Markers
´p Easy styling for Paragraphs
´p More CSS Details
´p About Colour Boxes
´p Basics for advanced users

With a click to add new lines a get this;

´p How to style a Paragraph

´p Misusing standard wikitext to indent a paragraph

´p Custom Wikitext Markers

´p Easy styling for Paragraphs

´p More CSS Details

´p About Colour Boxes

´p Basics for advanced users

What is fantastic about this is it stills displays he same but one has now double lined the text, its easier to read and insert notes or additional content

Question arising. Perhaps a Button to remove all \n\n on the selected text would also be very helpful from problem text?

Interim conclusion about these tools

There will be a lot of new possibilities and techniques arise from this set of tools, many of which we cant imagine yet. As a result we may need to build a community reference for collecting tips and trickes as a result.

Continuing my review

Tones/Tony

On Tuesday, 15 September 2020 21:40:33 UTC+10, PMario wrote:

[TonyM]

Continued review of 

Version 0.3.2

• Each of the tooltips that read "...at the start of the line" should read ""...at the start of the line(s)", to suggest the multi-line select option.
• Your documentation is well written and a great start!
• The style tag in https://wikilabs.github.io/editions/tick-text/#More%20CSS%20Details bleeds onto all other uses of » on the visible page.
• Could you spell out what wltc stands for as otherwise it is hard to remember, its not Symantec! perhaps cc "custom class" or something would be better/shorter?
• I notice the below does not work UNLESS you add the extra line breaks, should this be a default behaviour?, because it looks broken.

» How to style a Paragraph
» Misusing standard wikitext to indent a paragraph
» Custom Wikitext Markers
» Easy styling for Paragraphs
» More CSS Details
» About Colour Boxes
» Basics for advanced users

• A nice side effect of adding and removing » is that every line maintains a leading space, the All - Will remove this space but not the "» -"
• This is a good side effect because it is easy for users to insert/paste/type new ID's for "Easy styling for Paragraphs" 
• But I wonder if it should be more explicit
• Perhaps there could be a None option when selecting the ID, then we can also "add your own" for any line prefix, not only the allowed ID's
• Could we provide a small text box in the drop down where one could manually select the id and type in what is to follow, rather than being forced to "add your own" ?
• eg enter .i.r with tick selected, to apply to every line rather than having to have a defined prefix?
• If people role their own classes this list may fill up very quickly without this manual method.
• It may allow prepending everyline with <<macroname>> or perhaps one day <<macroname "Line">> although this can be done in custom editor Toolbar buttons.

Key difference between I am Mario's view here?

On further reflection I think I can see where our ideas diverged at some point, to do with the \n and \n\n

• When one types, or pastes content. it is natural to use one \n for a line \n\n\ for a paragraph, to get around the issue I wanted a ' or something to treat at render each line as a <p></p> this give rise to a behaviour similar to \n\n
• However Mario you have added the option to add \n\n because if you don't tick and » will not work

eg; This only includes the » in the content

» How to style a Paragraph
» Misusing standard wikitext to indent a paragraph
» Custom Wikitext Markers
» Easy styling for Paragraphs
» More CSS Details
» About Colour Boxes
» Basics for advanced users

• To me the above is the simplest and easiest to enter without \n\n and the way a lot of pasted text comes this way
• Thus I would like the special characters to respond to \n 
• Remember wiki text is a short hand, forcing \n\n to make this work is expansive, not short hand.
• I like both methods, but feel we should reverse the default (matter of opinion) and I am not sure I still understand (your - Mario's)  view point fully.
• I hope this goes further to bridge this different perspective.

In closing;

• I would not put so much time into this solution except that is is close and of substantial value, and mario has committed a great deal of effort, in fact we all have.
• so all my review comments here have being prepared thoughtfully and carefully, to reduce the time needed.
• I hope they assist Mario by being clear and to the point where possible keeping the generated work to a minimum.

Thanks very much Mario.

Regards

Tony

On Tuesday, 8 September 2020 06:39:57 UTC+10, Mat wrote:

Last thread paginated.

Apropos what character is appropriate for PMarios construction, PMario wrote:

I'll be happy to change it, if someone has a good idea.

I think proper keyboards should be prioritized here, not "screen keyboards" because presumably most people do their full blown wiki editing on real keyboards, not on their their phones.

The generic currency symbol i.e  ¤  can be found on a few keyboards, including both Swedish and the Tastaturbelegung_E2 ;-)

<:-)

[PMario]

On Wednesday, September 16, 2020 at 3:00:58 AM UTC+2, TonyM wrote:

[...]

• Perhaps rather than "use in empty lines" you could say "all lines" or reverse and say "Lines with content only" that one turns off if then need to do what I want.

changed

• Alternatively a toggle button "All lines" on/off and gives you a tool tip to explain.

hmmm

• I think the "ID - Alone" would be better as "ID - only"

changed

ID - only  and the other dropdown elements can be created by the users. They are standard tiddlers tagged: $:/tags/TextEditor/LinePrefix

• When you do copy to clipboard it would help if there were a training space.
• If you highlight a set of lines an + angle brackets twice something interesting but incorrect happens

and Again

»» How to style a Paragraph
»»» Misusing standard wikitext to indent a paragraph

That's a bug.

 

What If I wanted ?

»» How to style a Paragraph

fixed it

Review notes continued

• I love the - All button, cool. Refresh or reverse using these tools1

I don't understand the above sentence.

• $:/plugins/wikilabs/tick-text/EditorToolbar/toggle-tick should probably be "Toggle ID" because tick is but one
  
• $:/plugins/wikilabs/tick-text/EditorToolbar/preview-type is wrong names, has the wrong caption etc... perhaps "select ID"

fixed it

My Review continues.

I hope this helps so far?

Yes!

[PMario]

On Wednesday, September 16, 2020 at 3:22:55 AM UTC+2, TonyM wrote:

[...]

• Perhaps the select ID drop down could include "Sets {{toolbarIcon}}" so it is clear once set you highlight your lines and use the toolbarIcon

Yes. It will, but I didn't have time to create all the different SVGs

• The copy to clipboard is a great feature, but initially it looks like the only feature of the drop down.

I did add a different message: ID Button prepared!<br>Content copied to clipboard! .. This should make it clearer now.

• Perhaps giving both tick toolbaricon and dropdown the same color would help?

I don't like colored buttons in the toolbar. IMO it would be more attention as it should have.

Notes:

Add new line - extra use?

What was you desire for the add new line option mario?

That's a button for my usecase. As I wrote. I use double linebreaks to create paragraphs. If I copy paste content from 3rd party sites and they only have 1 newline I can easily double them up.

So no "ID" prefix needed. I can use most of the content out of the box.

 

I was testing and I had this

´p How to style a Paragraph
´p Misusing standard wikitext to indent a paragraph

You should have tested it like this

How to style a Paragraph

Misusing standard wikitext to indent a paragraph

Ctrl-A, Ctrl-Shift-Enter .. done no further editing needed. ... Except it may have been add "*" to create a bullet list.

"Add Newline" and "angel brackets" are for me.

» is a Paragraph marker. It needs 2 \n\n to be active.

» line 1

line 2

will give you: line1 line2 .... Because that's the way I want it!!

 

What is fantastic about this is it stills displays he same but one has now double lined the text, its easier to read and insert notes or additional content

That's the intention. .. But it's meant to be used without any prefixes.

 

Question arising. Perhaps a Button to remove all \n\n on the selected text would also be very helpful from problem text?

I'm not sure about this one. ... Will need to think. ...

The "Add newline" has a flaw atm. If you use it twice, it shouldn't double empty lines. ... So will need to have a fix here

 

Interim conclusion about these tools

There will be a lot of new possibilities and techniques arise from this set of tools, many of which we cant imagine yet. As a result we may need to build a community reference for collecting tips and trickes as a result.

That's right. I did "steal" most of the colorBox settings from Mohammads Shiraz wiki. ... I think he has some very nice, and professional looking elements.

But I needed to remove some box colour settings, because they where too similar and therefore confusing. ..

I'll definitely play with the "cards" and the "image" possibilities. .. I did create some image templates years ago. It's time to revive them.

have fun!

mario

[PMario]

On Wednesday, September 16, 2020 at 4:34:09 AM UTC+2, TonyM wrote:

Continued review of 

Version 0.3.2

• Each of the tooltips that read "...at the start of the line" should read ""...at the start of the line(s)", to suggest the multi-line select option.

fixed that

• Your documentation is well written and a great start!

thx

• The style tag in https://wikilabs.github.io/editions/tick-text/#More%20CSS%20Details bleeds onto all other uses of » on the visible page.

 That's intentional. ... As the description says it's for _debugging_ and global settings.

• Could you spell out what wltc stands for as otherwise it is hard to remember, its not Symantec! perhaps cc "custom class" or something would be better/shorter?

tc-something is a marker for tiddlywiki-class-something setting in the TW core. I need similar settings, that have a global namespace in all my plugins.

wltc-something ... wikilabs tc-something ... I also use wltm- for messages ... wltv- for variables. ... That makes it easy, if something should get adopted by the core. We just need to remove the "wl" and it is TW core standard.

• I notice the below does not work UNLESS you add the extra line breaks, should this be a default behaviour?, because it looks broken.

» How to style a Paragraph
» Misusing standard wikitext to indent a paragraph
» Custom Wikitext Markers

Yes » is for me and works with default TW paragraphs.


 

• A nice side effect of adding and removing » is that every line maintains a leading space, the All - Will remove this space but not the "» -"

That's intentional.

• This is a good side effect because it is easy for users to insert/paste/type new ID's for "Easy styling for Paragraphs" 
• But I wonder if it should be more explicit

No side effect. .. I don't know what "But I wonder if it should be more explicit" means?

 

• Perhaps there could be a None option when selecting the ID, then we can also "add your own" for any line prefix, not only the allowed ID's

You can do this already. You can create a new toolbar button eg: Clone: https://wikilabs.github.io/editions/tick-text/#%24%3A%2Fplugins%2Fwikilabs%2Ftick-text%2FEditorToolbar%2Ftoggle-tick and change the "character" setting and the icon

BUT the parser will not know it. So nothing will happen.

• Could we provide a small text box in the drop down where one could manually select the id and type in what is to follow, rather than being forced to "add your own" ?
• eg enter .i.r with tick selected, to apply to every line rather than having to have a defined prefix?
• If people role their own classes this list may fill up very quickly without this manual method.
• It may allow prepending everyline with <<macroname>> or perhaps one day <<macroname "Line">> although this can be done in custom editor Toolbar buttons.

Good idea. Need to think about it.

 

Key difference between I am Mario's view here?

On further reflection I think I can see where our ideas diverged at some point, to do with the \n and \n\n

• When one types, or pastes content. it is natural to use one \n for a line \n\n\ for a paragraph, to get around the issue I wanted a ' or something to treat at render each line as a <p></p> this give rise to a behaviour similar to \n\n
• However Mario you have added the option to add \n\n because if you don't tick and » will not work

eg; This only includes the » in the content

» How to style a Paragraph
» Misusing standard wikitext to indent a paragraph
» Custom Wikitext Markers
» Easy styling for Paragraphs
» More CSS Details
» About Colour Boxes
» Basics for advanced users

• To me the above is the simplest and easiest to enter without \n\n and the way a lot of pasted text comes this way
• Thus I would like the special characters to respond to \n 

You can use ° or any other but » and may be ~ are for TW paragraphs.





I could add "angel's" little sister/brother "single angle quote"  › for single linebreaks.

I'm thinking about to remove the "comma" and "underline" option. They don't work for me. .. May be there are better options in the Unicode space

• Remember wiki text is a short hand, forcing \n\n to make this work is expansive, not short hand.

But it's the status quo and there are other reasons to like it that way. .. But we agreed to disagree here ;)

• I like both methods, but feel we should reverse the default (matter of opinion) and I am not sure I still understand (your - Mario's)  view point fully.

As I wrote: ´ ° › are all for you. They work with single linebreaks by default.

I'll make some "Add single angle" and "Remove single angle" buttons ... There will be a settings page in the plugin, that will make it easy to enable/disable buttons and drag / drop sort them.

» and ~ are for me. ... not sure yet, if tilde gets buttons. .. We'll see.

• I hope this goes further to bridge this different perspective.

I think both views are valid. I think it depends on personal preference, what to use at the end. 

In closing;

• I would not put so much time into this solution except that is is close and of substantial value, and mario has committed a great deal of effort, in fact we all have.

That's right. The docs will probably need more time than the coding. 

• so all my review comments here have being prepared thoughtfully and carefully, to reduce the time needed.

I think adding / removing / changing different markers isn't the biggest problem now. It's mainly changing the "start regexp" and some code "switch" constructions. ...

Feedback -- also from others -- very welcome!

• I hope they assist Mario by being clear and to the point where possible keeping the generated work to a minimum.

Your feedback is welcome!

-mario

[PMario]

We should continue there: Custom markup (continued 2)

-m

[TonyM]

Marion,

Clean up notes;

• I love the - All button, cool. Refresh or reverse using these tools1

I don't understand the above sentence.

The All button allows remove all ID's including attached classes etc.. this is;

• Cool
• Useful
• Great 

My Review continues.

I hope this helps so far?

Yes!

Good, I did not want to seem pushy :)

Regards

Tony

 

[PMario]

On Wednesday, September 16, 2020 at 12:35:29 PM UTC+2, TonyM wrote:

Marion,

 

I'm from Mars ♂️ ;)

Clean up notes;

• I love the - All button, cool. Refresh or reverse using these tools1

I don't understand the above sentence.

The All button allows remove all ID's including attached classes etc.. this is;

• Cool
• Useful
• Great 

Ah .. .OK. Yea I didn't want to have so many "minus" buttons. So I decided to go with one.

But I need to make the "toggle" button image adjustable. May be I can add a tooltip with the current setting to get better feedback.

We should continue discussion at: Custom markup (continued 2)

-m

[Eduardo Caio João]

Hi all!

1. Question

1. Would it be possible to have a better abstraction in the custom markup? So that we could separate the logical layer from the application, the interface/interaction layer from the data layer?

• An example of the application logic layer: includes keywords like 'if', 'else', 'for', 'while', 'true', 'false', 'ListView etc'
• An example of the interface/interaction layer: include keywords like '!!! to h3' or 'h3' or '#### h3' etc
• An example each data layer: includes only plain text

2. An example for each usage here

1. application logic layer: 

```json

{
    "time" : 1659600652950,
    "blocks" : [
        {
            "id" : "QG7d-eoSuo",
            "type" : "header",
            "data" : {
                "text" : "Editor.js",
                "level" : 2
            }
        },
        {
            "id" : "kVwdXj215H",
            "type" : "paragraph",
            "data" : {
                "text" : "Hey. Meet the new Editor. On this page you can see it in action — try to edit this text."
            }
        },
        {
            "id" : "H-e1YiUKlN",
            "type" : "header",
            "data" : {
                "text" : "Key features",
                "level" : 3
            }
        },
        {
            "id" : "T3ln9Hapf5",
            "type" : "list",
            "data" : {
                "style" : "unordered",
                "items" : [
                    "It is a block-styled editor",
                    "It returns clean data output in JSON",
                    "Designed to be extendable and pluggable with a simple API"
                ]
            }
        },
        {
            "id" : "KREAmAR5pB",
            "type" : "header",
            "data" : {
                "text" : "What does it mean «block-styled editor»",
                "level" : 3
            }
        },
        {
            "id" : "YOC9ONSAyk",
            "type" : "paragraph",
            "data" : {
                "text" : "Workspace in classic editors is made of a single contenteditable element, used to create different HTML markups. Editor.js <mark class=\"cdx-marker\">workspace consists of separate Blocks: paragraphs, headings, images, lists, quotes, etc</mark>. Each of them is an independent contenteditable element (or more complex structure) provided by Plugin and united by Editor's Core."
            }
        },
        {
            "id" : "1vu_B7xnOz",
            "type" : "paragraph",
            "data" : {
                "text" : "There are dozens of <a href=\"https://github.com/editor-js\">ready-to-use Blocks</a> and the <a href=\"https://editorjs.io/creating-a-block-tool\">simple API</a> for creation any Block you need. For example, you can implement Blocks for Tweets, Instagram posts, surveys and polls, CTA-buttons and even games."
            }
        },
        {
            "id" : "QnnsDw4lDQ",
            "type" : "header",
            "data" : {
                "text" : "What does it mean clean data output",
                "level" : 3
            }
        },
        {
            "id" : "Bz-zR4AT9U",
            "type" : "paragraph",
            "data" : {
                "text" : "Classic WYSIWYG-editors produce raw HTML-markup with both content data and content appearance. On the contrary, Editor.js outputs JSON object with data of each Block. You can see an example below"
            }
        },
        {
            "id" : "rnI2GILJ4v",
            "type" : "paragraph",
            "data" : {
                "text" : "Given data can be used as you want: render with HTML for <code class=\"inline-code\">Web clients</code>, render natively for <code class=\"inline-code\">mobile apps</code>, create markup for <code class=\"inline-code\">Facebook Instant Articles</code> or <code class=\"inline-code\">Google AMP</code>, generate an <code class=\"inline-code\">audio version</code> and so on."
            }
        },
        {
            "id" : "VXEb5d5CLm",
            "type" : "paragraph",
            "data" : {
                "text" : "Clean data is useful to sanitize, validate and process on the backend."
            }
        },
        {
            "id" : "u6VJxBO9HW",
            "type" : "delimiter",
            "data" : {}
        },
        {
            "id" : "MpYqDoF6XM",
            "type" : "paragraph",
            "data" : {
                "text" : "We have been working on this project more than three years. Several large media projects help us to test and debug the Editor, to make it's core more stable. At the same time we significantly improved the API. Now, it can be used to create any plugin for any task. Hope you enjoy. 😏"
            }
        },
        {
            "id" : "ygqt5IYr9S",
            "type" : "image",
            "data" : {
                "file" : {
                    "url" : "https://codex.so/public/app/img/external/codex2x.png"
                },
                "caption" : "",
                "withBorder" : false,
                "stretched" : false,
                "withBackground" : false
            }
        }
    ],
    "version" : "2.24.3"
}

```

or 

2. interface/interaction layer: 

```json

{ // UISchema

  "firstName": {

    "ui:autofocus": true,

    "ui:emptyValue": "",

    "ui:autocomplete": "family-name"

  },

  "lastName": {

    "ui:emptyValue": "",

    "ui:autocomplete": "given-name"

  },

  "age": {

    "ui:widget": "updown",

    "ui:title": "Age of person",

    "ui:description": "(earthian year)"

  },

  "bio": {

    "ui:widget": "textarea"

  },

  "password": {

    "ui:widget": "password",

    "ui:help": "Hint: Make it strong!"

  },

  "date": {

    "ui:widget": "alt-datetime"

  },

  "telephone": {

    "ui:options": {

      "inputType": "tel"

    }

  }

}

```

or 

3. data layer:

```json

{ // JSONSchema, data layer

  "title": "A registration form",

  "description": "A simple form example.",

  "type": "object",

  "required": [

    "firstName",

    "lastName"

  ],

  "properties": {

    "firstName": {

      "type": "string",

      "title": "First name",

      "default": "Chuck"

    },

    "lastName": {

      "type": "string",

      "title": "Last name"

    },

    "telephone": {

      "type": "string",

      "title": "Telephone",

      "minLength": 10

    }

  }

}

```

3. References

1. https://github.com/rjsf-team/react-jsonschema-form
2. https://github.com/Jermolene/TiddlyWiki5/discussions
   
3. https://wikilabs.github.io/
   
4. https://editorjs.io/getting-started

[Eduardo Caio João]

1. Why use Json in TiddlyWiki by standard?

1. "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language."
2. "JSON is a widely used format that allows for semi-structured data, because it does not require a schema. This offers you added flexibility to store and query data that doesn't always adhere to fixed schemas and data types.
3. "Json, XML, other markup languages (markdown, wikitext, commonmark, html etc), email and EDI are all forms of semi-structured data." But... "for embedded Markup" is good if it has Json for standard in TiddlyWiki
4. "Json is non-linear, tiddlyWiki" too.
   

2. Concept

```json

{
  "app": {
    "config": "./settings.json",
    "cwd": "./",
    "src": "example/content/",
    "filePattern": "**/*.md",
    "dist": "example/output.json",
    "name": "markdown-json",
    "version": "0.0.1"
  },
  "data": [
    {
      "section": "Elements",
      "title": "buttons",
      "device": [
        "desktop",
        "mobile"
      ],
      "styles": [
        "https://lalao.com/styles/structure.min.css",
        "https://lalao.com/styles/app.min.css"
      ],
      "contents": "<p>Follow some application examples of buttons</p>\n<h1 id=\"types\">Types</h1>\n<h3 id=\"base\">Base</h3>\n<p>Base button layout sample:</p>\n<button type=\"button\" class=\"buy-button btn btn-success\">\n  <span class=\"icon\"></span>\n  <span class=\"text\">Button</span>\n</button>\n\n<pre><code class=\"lang-scss\">.btn-primary {\n  @include states(#1A75CE, #086B9C);\n}\n</code></pre>\n<pre><code class=\"lang-html\">&lt;button type=&quot;button&quot; class=&quot;buy-button btn btn-success&quot;&gt;\n  &lt;span class=&quot;icon&quot;&gt;&lt;/span&gt;\n  &lt;span class=&quot;text&quot;&gt;Button&lt;/span&gt;\n&lt;/button&gt;\n</code></pre>\n",
      "excerpt": "<p>Follow some application examples of buttons</p>",
      "id": "buttons",
      "meta": {
        "relativePath": "content/buttons.html",
        "createdAt": "2020-10-08T16:05:30.415Z",
        "lastModified": "2020-10-08T16:05:14.452Z",
        "size": 2095,
        "formattedSize": "2.0 KB"
      }
    },
    {
      "section": "Elements",
      "title": "icons",
      "tags": [
        "icons",
        "base"
      ],
      "contents": "<h1 id=\"icons\">Icons</h1>\n<p>Our icons list still is empty :(</p>\n",
      "excerpt": "<p>Our icons list still is empty :(</p>",
      "id": "icons",
      "meta": {
        "relativePath": "content/globals/js-utils.html",
        "createdAt": "2019-08-27T18:01:33.747Z",
        "lastModified": "2019-08-27T18:01:33.747Z",
        "size": 331,
        "formattedSize": "331 Bytes"
      }
    }
  ]
}

```

3. References

1. https://www.w3schools.com/whatis/whatis_json.asp
2. https://en.wikipedia.org/wiki/JSON
3. https://www.json.org/json-en.html
4. https://en.wikipedia.org/wiki/Semi-structured_data
5. https://en.wikipedia.org/wiki/Unstructured_data
6. https://www.integrate.io/glossary/what-is-unstructured-data/
7. https://www.xml.com/pub/a/w3j/s3.nelson.html
   
8. https://www.xml.com/pub/a/2004/10/06/deviant.html
   
9. http://essaysfromexodus.scripting.com/tedNelsonWebHypertext
   
10. https://cloud.google.com/blog/products/data-analytics/bigquery-now-natively-supports-semi-structured-data
    
11. https://wikilabs.github.io/
    
12. https://www.vertopal.com/en/convert/markdown-to-json
    
13. https://www.npmjs.com/package/markdown-json
    
14. https://www.integrate.io/glossary/what-is-unstructured-data/