Custom markup (continued 3)

[PMario]

Hi folks,

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

Let's start a new one before [2] starts to use pagination.

Have a closer look at link [1] it's possible to show all the topics in 1 page

starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ the above link won't work anymore!

have fun!

mario

[@TiddlyTweeter]

@TiddlyTweeter wrote: 

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

 

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

SINCE Gruber a lot has changed. What is readable for him, then was likely NOT this ...

°X.fred-opens-angel Fred opens the Guillemet with a degree.

Is THAT "readable"? I would say it IS readable for the AUTHOR.

I am using your tool for inserting text via CSS like this (each class uses "::before" to insert the text)...

°A.a-lonyb
°P.p-3
°A.o-ls-l

I can read that. It is MY shorthand. Very compact. I fully understand it. But it is NOT Gruber's concept of Markdown "readability".

The POINT? "Readability" is actually CONTEXT dependent.

I'll give a bigger example later. 

Your tool actually allows shorthand easily. 

It gets over some of the practical (& ideological, circa 2004) limitations of existing wiki markup methods.

Best wishes

TT

 

[TonyM]

TT, [Minor edits online]

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

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

More ideas

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

Regards

Tony who is well past his bedtime.

[TonyM]

Folks,

I continue researching the possibilities for these reasons

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

Some notes; See matching code samples

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

Questions

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

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

Code samples

1. Transclude this tiddlername in a tiddler {{||tiddlername}}

\customize tick=wikify _element="$wikify" _srcName=text name=result
\customize tick=text _element="$text" _srcName=text

´text {{{ [all[current]] }}}
<br>

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

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

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

2. Setting and using evaluated variables

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

´ghost <<ghost>><br>

And <<ghost>> the value is here

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

My <<new-var>>

</$set>

I did not use the end string here! Is that a problem?

Are they "self closing"?

Tony

[@TiddlyTweeter]

TonyM (& PMario)

TonyM wrote:

Readability in programming languages has often simply come from a body of work. You can write code in short or long ways. I imagin you choose depending on the audience. For example your own shortcuts where at most others view the results can be as brief as you want.

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

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

°.x-4x
°A.standard-back

etc ...

My point in my OP was to open-up what "readable" means. My "shorthand" is totally readable to me. It produces (in render) ...

On all fours. First attend your back. Can you form a mental image of where it is in space?

I don't think that approach is like Gruber Markdown at all. But the concepts Gruber initiated have had enormous shaping influence on how we think about markup. Especially in wikis.

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

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

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

The easiest way I could describe it is "Private Shorthand Supporting Public Messaging".

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

Best wishes

TT

[@TiddlyTweeter]

PMario & Friends

The implications of The Tool are freeing, whilst also complex and diverse.

IN PARTICULAR the easier use of CSS could lead to what PMario identified as a potential TOWER OF BABEL.

In my own case I recognize the need for a decent way of thinking CSS class naming through (there will be about 300 classes for my use case I think).

I will likely implement a crude framework using Telmiger's Bricks tool to do so.

My point? The IMPLICATIONS of The Tool are large. There will arise need, I think, to clarify how deal with that ENLARGED FREEDOM effectively.

Best wishes

TT

[PMario]

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

2. Setting and using evaluated variables

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

´ghost <<ghost>><br>

And <<ghost>> the value is here

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

My <<new-var>>

</$set>

I did not use the end string here! Is that a problem?

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

 

Are they "self closing"?

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

.... shortened above

/ghost

<<new-var>>

<<ghost>>

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

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

-mario

mario

[PMario]

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

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

°.x-4x
°A.standard-back

etc ...

OK. ... That's interesting.

 

My point in my OP was to open-up what "readable" means. My "shorthand" is totally readable to me. It produces (in render) ...

On all fours. First attend your back. Can you form a mental image of where it is in space?

I don't think that approach is like Gruber Markdown at all. But the concepts Gruber initiated have had enormous shaping influence on how we think about markup. Especially in wikis.

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

For me it's important that both variants work.

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

That's right, as written above.

 

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

Yes. That's the intention.

 

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

 

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

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

 

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

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

-mario

[@TiddlyTweeter]

PMario and all

I been thinking about all this. Especially markup symbols.

Looking back at Gruber 2004. At that time you were stuck visually on glyphs between a rock & a hard place.

We are no longer so constrained. 

MY POINT? Let us ensure we are VISUALLY free on markup symbols, not get stuck in 2004 code pages :-).

A thought

TT

On Saturday, 26 September 2020 13:57:05 UTC+2, PMario wrote:

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

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

°.x-4x
°A.standard-back

etc ...

[TonyM]

TT et al,

Word of the day? "Nomenclature"

The easiest way I could describe it is "Private Shorthand Supporting Public Messaging".

One advantage we have both by design and by circumstance is TiddlyWiki produces its results via final rendition in html. As a result whatever you use to generate content is a universally applicable, even copy and paste.

The tiddlywiki core plugin 

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

 

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

An author solution in tiddlywiki has three key audience groups, tiddlywiki enthusiasts/designers, the author and those that read the authors work. All however can have audiences made up of different individuals or groups with different end objectives. 

As many authors insist, know your audience. 

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

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

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

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

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

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

Let the conversation begin (in another thread?)

Regards

Tony

Other notes:

Guidelines for writing taxonomy for the web

• Mutually exclusive categories can be beneficial. If categories appear several places, it's called cross-listing or polyhierarchical. The hierarchy will lose its value if cross-listing appears too often. Cross-listing often appears when working with ambiguous categories that fits more than one place.^[19]

• Having a balance between breadth and depth in the taxonomy is beneficial. Too many options (breadth), will overload the users by giving them too many choices. At the same time having a too narrow structure, with more than two or three levels to click-through, will make users frustrated and might give up

 

Knowledge representation and reasoning

Ontology (information science)

Lexicon

 

[PMario]

Hi folks,

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

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

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

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

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

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

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

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

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

°☐:a:noSpacesAllowed This is a test

Since this

°☐:a:noSpacesAllowed This is a test

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

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

°☐ This is a test

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

See: Examples in GG

Have fun!

mario

[PMario]

Hi,

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

-m

[PMario]

I did add a bit more colour to the examples, to visualize the data-flow a bit better.

-m

[TonyM]

Mario,

Yes Very interesting.

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

• The Checkbox and map solutions are great.

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

Just now, the features of which could be leveraged by custom wiki-text especially when looking for state and unique tiddlers;

Eg; Rather than qualify use [<tsn>prefix[$:/checkboxes/]suffix[a]]... perhaps checkboxes against children. 

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

This will help!

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

I will continue with the evaluation of your new releases. 

Question(s)?

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

Review discovery;

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

FYI

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

Regards

Tony

[PMario]

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

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

Just now, the features of which could be leveraged by custom wiki-text especially when looking for state and unique tiddlers;

Eg; Rather than qualify use [<tsn>prefix[$:/checkboxes/]suffix[a]]... perhaps checkboxes against children. 

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

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

if the <very-long-public-key> is hashed and stored with the tiddler, it can be used to identify tiddlers with the same name.

Question(s)?

• Given "_params = class definitions" perhaps it could become _classes and _map becomes _params?
• It would be easy/clearer to say the syntax is .class(s):param1:param2

Yea, I did think about this myself. At first I wanted to use _params like: =".a.b:a:b", but it gets really messy with longer names.

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

 

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

As I wrote earlier. I couldn't find a way to have global parser pragmas. .. The problem is: Internally TW core creates a new Parser() for every tiddler, similar to:

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

\define test()

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

test

\end

some text

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

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

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

 

Review discovery;

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

Yea, the new tiddlers have 2 lists: Global stat tiddlers, which is the default now and "local state" tiddlers, which are responsible for 1 tiddler.

 

FYI

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

I'm looking forward to see the tests.

-mario

[@TiddlyTweeter]

Ciao PMario & all

I been doing a lot of testing of using Custom Markup for layouts and precision CSS application. It is VERY good. 

A number of issues came up. I will post about each separately. First I comment about Editor Look & Keys, then Fonts & Unicode.

I did testing on English Win7 (DT), Italian Win10 (tablet) & Android6 (standard phone) computers.

1 - EDITOR LOOK & SETUP

Key Availability - It became clear quickly that whilst all three system tested on have Font Support they all differ in native Keyboard Support. 

None has all 6 IDs available easily on keys.

This just confirms what we said before: the tool requires buttons, keyboard shortcuts and likely (for boilerplate WikiText) stamp tool use.

The approach PMario took to deal with this via buttons & key shortcuts works well... 

but ...

Too Many Buttons? - I think there may be too many buttons :-). For instance are the buttons that just remove an ID needed at all?

What is primary is to be able to insert IDs, which it does. 

But I don't see added value (myself) to remove them where a single "delete" stroke does it anyway!

Button Pictures - This is ONLY an aesthetics comment; but why not just have a picture of the single ID on a button and no more?

Visually I think they are over-noisy. 

2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed this. 

Its not an issue on the 6 IDs, at least not for European languages. 

But it is an issue if you want to use Unicode characters in \customize pragma.

I tried to pin down some RELIABLE (typographic) characters available through Unicode (i.e. that have "universal" font support).

This is not an easy thing to do. Font substitution behavior of OS' systems (a pretty amazing process BTW) that create "composite" fonts on the fly, using available fonts on the computer can make it near impossible to predict (1) glyphs that will appear in other people's TW; (2) what they will look like (e.g. sometimes coloured, sometimes not, sometimes visually very different).

This is obviously NOT directly a TW issue. But it made me wonder whether in fact we (the whole internet) are seriously under-using Unicode that would make life much easier---and not just to better support Custom Markup.

My point for TW? I'm wondering IF, we could assemble a custom font of say 100 Unicode typographic signs (e.g. punctuation marks, markup symbols, reference signs etc)  and EMBED this in a TW? I don't know how you'd embed it or access the font. But I know how to make such a font set.

Q: Is it possible? Your thoughts?

Best wishes

TT

[@TiddlyTweeter]

Ciao PMario

A CONFESSION - Using Custom Markup at first was very confusing for me!

As soon as I started to do anything other than simple the layout would break.

This is because of Custom Markup's richness. Because it can do a lot a lot of different ways.

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

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

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

\customize Flow Setting of two types

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

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

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

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

Best wishes

TT

[@TiddlyTweeter]

Ciao PMario

Is Six ID's Enough? YES.

In practical use I think its a good number.

- Good balance between strict TECHNICAL NEED to make it work (i.e. 2) and ..

- ... VISUAL VARIANCE to make typing variant markup a good experience.

In my tests I used all 6. 2 extensively. 2 moderately. 2 for special cases.

That number is well supporting of even complex markup.

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

Best wishes

TT

[@TiddlyTweeter]

Ciao PMario

Comments on INLINE markup.

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

 »§

  ›¶ `›¶` Example single line for SA phrase groups. Won't fully work till custom-inline is finished. ([[TT Notes]])

  »¶

   °O `»¶ ... ⁋` Example mutli-line block for SA phrase groups. 

   °O Good morning. Welcome to another 

   ›ABsa 

   °O ... So, let's start ... 

  ⁋

  »¶

   °P.p-b-v 

   °O Observe how your body lays on the ground. What touches clearly. What doesn't. 

  ⁋

  »¶

   °A.p-b-v

   °O Observe how your body lays on the ground etc ...

   °O

  ⁋

 §«

each ° inserts a <span> into a paragraph (»¶ ... ⁋). I'm doing it this way because at the moment to do it inline would make it (1) FAR LESS READABLE .... see below ...

and I also want to insert (2) NON-SPAN inline elements easily like  ›ABsa and (3) sometimes NEST elements.

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

You mentioned before that the current inline parser need uses matched pairs. 

But the pairs are identical so inline NESTING becomes impossible.

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

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

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

... Now you gonna say that would ONLY match words ... so for anything other than a word (string of chars that are not spaces) you use a closure.

Let's pretend ... its /°

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

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

I have two other simpler suggestions ...

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

2 - ADD a second ID, maybe aimed at paired use by default?

Very best wishes.

TT

[PMario]

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

Comments on INLINE markup.

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

 »§

  ›¶ `›¶` Example single line for SA phrase groups. Won't fully work till custom-inline is finished. ([[TT Notes]])

  »¶

   °O `»¶ ... ⁋` Example mutli-line block for SA phrase groups. 

   °O Good morning. Welcome to another 

   ›ABsa 

   °O ... So, let's start ... 

  ⁋

  »¶

   °P.p-b-v 

   °O Observe how your body lays on the ground. What touches clearly. What doesn't. 

  ⁋

  »¶

   °A.p-b-v

   °O Observe how your body lays on the ground etc ...

   °O

  ⁋

 §«

Interesting, but without the actual configuration it's really hard for me to see, what it should do. .. Can you export your setting and attach a tiddlers.json, so I can see it?

 

each ° inserts a <span> into a paragraph (»¶ ... ⁋). I'm doing it this way because at the moment to do it inline would make it (1) FAR LESS READABLE .... see below ...

and I also want to insert (2) NON-SPAN inline elements easily like  ›ABsa and (3) sometimes NEST elements.

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

You mentioned before that the current inline parser need uses matched pairs. 

But the pairs are identical so inline NESTING becomes impossible.

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

 

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

 

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

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

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

 

... Now you gonna say that would ONLY match words ... so for anything other than a word (string of chars that are not spaces) you use a closure.

Let's pretend ... its /°

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

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

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

 

I have two other simpler suggestions ...

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

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

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

°C will clash with the existing parser

 

2 - ADD a second ID, maybe aimed at paired use by default?

 

Not sure, what you mean here.

-mario

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

[@TiddlyTweeter]

PMario wrote:

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

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

Its actually very complex so I've made a simplified single tiddler example containing the \customize, markup example and style block for you to see.

I hope that will help.The example attached is for using the markup in BLOCK mode I already have working well. 

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

Many thanks for your patience!

TT 

[@TiddlyTweeter]

PMario ...

 

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

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

TT

[PMario]

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

Its actually very complex so I've made a simplified single tiddler example containing the \customize, markup example and style block for you to see.

I hope that will help.The example attached is for using the markup in BLOCK mode I already have working well. 

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

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

 

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

OK

-mario

[PMario]

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

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

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

-m

[PMario]

On Saturday, October 3, 2020 at 10:56:44 AM UTC+2, @TiddlyTweeter wrote:

Ciao PMario

A CONFESSION - Using Custom Markup at first was very confusing for me!

As soon as I started to do anything other than simple the layout would break.

This is because of Custom Markup's richness. Because it can do a lot a lot of different ways.

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

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

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

Yes. The _endString basically makes them the same!

 

\customize Flow Setting of two types

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

That's the same behaviour, like the TW core parser.

 

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

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

 

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

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

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

 

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

What do you mean by "interactivity"

-mario

[PMario]

On Saturday, October 3, 2020 at 10:18:14 AM UTC+2, @TiddlyTweeter wrote:

Ciao PMario & all

I been doing a lot of testing of using Custom Markup for layouts and precision CSS application. It is VERY good. 

A number of issues came up. I will post about each separately. First I comment about Editor Look & Keys, then Fonts & Unicode.

I did testing on English Win7 (DT), Italian Win10 (tablet) & Android6 (standard phone) computers.

1 - EDITOR LOOK & SETUP

Key Availability - It became clear quickly that whilst all three system tested on have Font Support they all differ in native Keyboard Support. 

None has all 6 IDs available easily on keys.

This just confirms what we said before: the tool requires buttons, keyboard shortcuts and likely (for boilerplate WikiText) stamp tool use.

The approach PMario took to deal with this via buttons & key shortcuts works well... 

but ...

OK

Too Many Buttons? - I think there may be too many buttons :-). For instance are the buttons that just remove an ID needed at all?

What is primary is to be able to insert IDs, which it does. 

But I don't see added value (myself) to remove them where a single "delete" stroke does it anyway!

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

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

 

Button Pictures - This is ONLY an aesthetics comment; but why not just have a picture of the single ID on a button and no more?

Visually I think they are over-noisy. 

right!

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

I'll have a closer look.

 

2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed this. 

Its not an issue on the 6 IDs, at least not for European languages. 

But it is an issue if you want to use Unicode characters in \customize pragma.

 

I tried to pin down some RELIABLE (typographic) characters available through Unicode (i.e. that have "universal" font support).

This is not an easy thing to do. Font substitution behavior of OS' systems (a pretty amazing process BTW) that create "composite" fonts on the fly, using available fonts on the computer can make it near impossible to predict (1) glyphs that will appear in other people's TW; (2) what they will look like (e.g. sometimes coloured, sometimes not, sometimes visually very different).

This is obviously NOT directly a TW issue. But it made me wonder whether in fact we (the whole internet) are seriously under-using Unicode that would make life much easier---and not just to better support Custom Markup.

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

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

 

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

I personally would install the font.

 

Q: Is it possible? Your thoughts?

I would even consider to create a browser AddOn, that will make the font available for TWs, if users don't want to install new system fonts.

I'm not sure if this is possible, but it would be worth a test.

-mario

 

[PMario]

Hi foks,

I did just upload V0.6.0 which has some INCOMPATIBLE changes.

• New Functionality
  • $:/config/custom-markup/pragma/PageTemplate tagged: $:/tags/Macro
    • content: \importcustom [tag[$:/tags/pragma]]
  • contains global pragma definitions .. and macro definitions
• Incompatible changes
  • _params renamed to -> _classes
  • _maps renamed to -> _params !!
  • Adjusted the docs accordingly
• Improved debug modes
  • \debugcustomize new parameters: no, list, global, global list, global ID
  • _debug new parameter: no,
• angel renamed to: angle + docs

-mario

[TonyM]

Mario,

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

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

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

• Helpful with a number of customise shortcuts

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

{{||$:/core/ui/Buttons/new-journal-here}}

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

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

´toptoc {{||(link)}} {{||(new-here)}}<br>

Gives

Some I am building

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

Regards

Tony

[@TiddlyTweeter]

PMario wrote:

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

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

<p><article></article></p>

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

<article class="wltc-l1 wltc"></article>

Just a comment.

TT

[@TiddlyTweeter]

Regarding fonts ...

 @TiddlyTweeter wrote:

 

2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed this. 

Its not an issue on the 6 IDs, at least not for European languages. 

But it is an issue if you want to use Unicode characters in \customize pragma.

 <snip>

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

PMario ... 

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

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

<snip>

I personally would install the font. 

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

 

 

Q: Is it possible? Your thoughts?

 

I would even consider to create a browser AddOn, that will make the font available for TWs, if users don't want to install new system fonts.

I'm not sure if this is possible, but it would be worth a test. 

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

Best wishes

TT

[@TiddlyTweeter]

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

I'll update first. A dopo.

TT

[@TiddlyTweeter]

Regarding a use case using "shorthand"

PMario wrote:

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

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

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

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

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

Lay down on your back. Observe how you lay on the ground <a lot more like this ... then ...> bend your knees. Cross your right leg over your left ... etc

A whole lesson is written on ONE A6 card. 

Transcribed a lesson would be 4-6 pages of A4.

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

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

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

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

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

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

I may actually use it! :-)

Best wishes

TT

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

[@TiddlyTweeter]

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

[@TiddlyTweeter]

Regarding examples & WikiText "interactivity"

TT wrote:

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

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

 

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

PMario 

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

Hopefully I can give you one or two in time.

 

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

What do you mean by "interactivity"

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

I think the bigger point I was trying to get at is that Custom Markup makes much, much easier vastly more sophisticated use of HTML & CSS using a neat compact method.

Along with that comes, I think, much higher chances users will trigger cases where the layout seems to go all wrong :-). 

So greater clarity of how parsing works is likely going to be needed if a user wants to do more advanced work.

TT

[@TiddlyTweeter]

For readers on email in my last post prefaced Regarding examples & WikiText "interactivity" I deleted the last paragraph as it was misleading.

TT

[@TiddlyTweeter]

Discussing putative inline IDs 

@TiddlyTweeter wrote:

 

2 - ADD a second ID, maybe aimed at paired use by default?

 

PMario .. 

Not sure, what you mean here.

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

degree "°" (entity = &deg;)

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

middle dot "·" (entity = &middot;)

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

Best wishes

TT

[PMario]

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

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

degree "°" (entity = &deg;)

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

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

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

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

 

middle dot "·" (entity = &middot;)

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

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

Just some thoughts.

mario

[@TiddlyTweeter]

--- Largely OT ----

 

PMario ...

 

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

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

TT 

[@TiddlyTweeter]

TT .. 

I have two other simpler suggestions ...

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

PMario ... 

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

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

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

°C will clash with the existing parser

Right. My concern here is a broader issue. 

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

Would it not be better they were totally different? That should prevent problems that you mention.

Thoughts

TT

[@TiddlyTweeter]

PMario

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

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

I would like to keep °° some text °°

Well you are the developer :-).

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

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

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

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

renders as ...

This is an <span class="eg">example</span> of usage. Just an example.

You add ONE character. Well good.

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

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

renders as ...

This is an <span class="eg2"> example of usage</span>.Just an example.

You add TWO characters.

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

And the second case should permit nesting?

Best wishes

TT

[TonyM]

Mario,

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

As a starter I am reviewing first simple elements only 

eg;

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

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

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

eg

'aside Content is an aside

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

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

\customise tick=question _element=question
\customise tick=answer _element=answer
<style>
question { display: initial }
answer { display: none }
</style>

´question What do you think?

´answer Really cool eh?

By the way I do nor think we shopuld say 

<ID>=<userSymbol>

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

To me 

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

Regards

Tony

On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:

Hi folks,

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

Let's start a new one before [2] starts to use pagination.

Have a closer look at link [1] it's possible to show all the topics in 1 page

starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ the above link won't work anymore!

have fun!

mario

[TonyM]

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

You may use answers to display all answers at once;

Otherwise

'q1 Question 1

'a1 answer 1

etc...

Tony

[PMario]

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

By the way I do nor think we shopuld say 

<ID>=<userSymbol>

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

This will be some docs changes only. I would be OK with this.

 

To me 

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

-m

[PMario]

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

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

eg

'aside Content is an aside

• That is nominate one of the special character to just automatically treat what follows as this does \customise tick=aside _element=aside

This would be possible if we would check against an HTML list of "names". which is already done, eg: _element="article" will have a look at: https://github.com/Jermolene/TiddlyWiki5/blob/9716c326952c16f63345a135e73cf36670dca0d8/core/modules/config.js#L37

But we would probably need to update this list, since "Details" isn't listed there.

 

• So in fact we do not need to define any \customise tick=elementname _element=elementname

We do for "names" that are not html tags.

 

• This should be achievable programaticaly so any element name can be used including arbitrary html elements.

including "arbitrary" tags is not possible, since this would limit the names to html elements only. .. That's not what we want. 

-mario

[PMario]

Hi

´aside test asdf

is already possible

[PMario]

On Monday, October 5, 2020 at 10:03:40 AM UTC+2, @TiddlyTweeter wrote:

Regarding a use case using "shorthand"

PMario wrote:

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

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

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

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

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

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

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

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

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

-m

 

[PMario]

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

For readers on email in my last post prefaced Regarding examples & WikiText "interactivity" I deleted the last paragraph as it was misleading.

TT

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

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

-------- slightly OT ;)

I was also thinking about a plugin that uses:

 - list

   - list

to produce this:

• list
• list

I'm not really happy with

* list

** list

Especially if there are 3 of them.

-m

[TonyM]

Mario,

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

• Perhaps I can state it in different words?

Consider this

\customise sym=elementname _element=elementname

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

¤elementname.classname and allowing class names

You can see the customise is repetitive, but currently it must be explicit

What I am suggesting is there is so much value in using customise just to take a named element name and allow a classname(s) to be applied and close it.

<elementname> line or content </elementname>

So I am asking if it would be possible to to convert any line beginning with a fixed special character to result in a open and close element of the immediate text. Arguably auto close on \n\n

Why;

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

<abstract>This tiddler is about ....</abstract>

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

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

Regards

Tony

[TonyM]

Folks,

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

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

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

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

Regards

Tony

[@TiddlyTweeter]

Revision Suggestions For "exports.htmlBlockElements"

Ciao PMario & TonyM

TonyM wrote:

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

eg

'aside Content is an aside

 

This would be possible if we would check against an HTML list of "names". which is already done, eg: _element="article" will have a look at: https://github.com/Jermolene/TiddlyWiki5/blob/9716c326952c16f63345a135e73cf36670dca0d8/core/modules/config.js#L37

But we would probably need to update this list, since "Details" isn't listed there.

Right! And thanks, Mario, for posting that link!

IMO in addition to  Details that list should include the "semantic HTML" tag for Nav.

It also lacks Main. But I don't think it needs adding as you'd only ever use it ONCE, so no need for Custom Markup activation on that one.

Yes?

Best wishes

TT

 

[@TiddlyTweeter]

TonyM wrote:

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

RIGHT! And Right! But with power comes responsibility. That is a cliche. 

But documenting the new approach I think we need to help PMario. Especially with examples.

TonyM previously wrote: 

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

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

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

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

My tuppence

TT

[@TiddlyTweeter]

Should "Space, Space, Enter = <br>" be in Custom Markup too?

 

@TiddlyTweeter wrote:

For readers on email in my last post prefaced Regarding examples & WikiText "interactivity" I deleted the last paragraph as it was misleading.

TT

PMario wrote: 

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

AH! Got it!

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

Or do you think it would be confusing? 

Best wishes

TT

[@TiddlyTweeter]

Ciao TonyM

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

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

´aside test

already produces in render ...

<aside class="wltc-l1 wltc">test</aside>

and

´aside.my-style test

produces in render

<aside class="my-style wltc-l1 wltc">test</aside>

Likely I am missing your point!

Best wishes

TT

[@TiddlyTweeter]

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

1. Unicode aims to support ALL written characters

2. Fonts aim to support SOME written characters

3. Documents support Fonts.

∴ (therefore) ...

SOME documents support SOME Unicode.

[@TiddlyTweeter]

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

 

TT wrote ...

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

PMario wrote ... 

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

I DO :-).

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

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

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

TT

[@TiddlyTweeter]

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

PMario

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

I would go a slightly different route. Have eg: about a miniute readable and for the rest you have to be logged in. ...

Interesting queries!

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

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

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

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

TT

 

[TonyM]

Bump,

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

Please advise if there is something I can do.

Tony

[@TiddlyTweeter]

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

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

1 - INLINE markup, I commented on before, that IMO we should AVOID doubling. Having to type @@text    bits@@ just to get a span is very uneconomic.

     IMO inline markup needs to be (a) the least obtrusive; (b) with the least keystrokes.

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

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

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

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

We need glyphs SPECIFIC for inline to ensure minimalism in design.

Those two characters are visually excellent for that job.

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

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

Best wishes

TT

[@TiddlyTweeter]

Tony

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

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

I don't mean simply tagging/untagging  a stylesheet tiddler.

I mean a macro that changes the values of CSS declarations dynamically and pass new values simply (like how the Palette system works). 

THAT would, I think, be a superb way to show the power of Custom Markup.

Best, TT

On Thursday, 22 October 2020 11:51:11 UTC+2, TonyM wrote:

[TonyM]

TT,

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

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

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

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

One reason I want this for is also consistency. If we can use elements such as html $widget the <macroname is just a logical extension anyway.

But as you can see even just making use of existing macros can add great value, but even more our own for purpose ones. However remember we can use customise against the macrocall widget as well.

 

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

Can you give an example?

 

I don't mean simply tagging/untagging  a stylesheet tiddler.

I mean a macro that changes the values of CSS declarations dynamically and pass new values simply (like how the Palette system works). 

THAT would, I think, be a superb way to show the power of Custom Markup.

On inline there is already the comment standard /* */ it seems to me /glyph inline content glyph/ is quite intuitive, its easy to see if it is opening or close in once you are familiar with it, It seems to say 

Open an inline with this glyph and close with this glyph it has the advantage as reading like a form of "markup" in the old fashioned form "with a pen", if the text is not in a wiki with the customise feature.

This may permit nesting as well.

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

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

Regards

Tony

[@TiddlyTweeter]

Ciao Tony

Me ... 

A SERIOUS use case would be HOW to invoke dynamic style change via inline buttons.

 

TonyM ...

 Can you give an example?

A simple one would be to able to dynamically change "block style" for paragraphs. I'm interested in archaic forms of writing where there is NO gap between paragraphs. They form one flow.

Being able to do this simply by changing <state> ...

p.archaic {

  display: <state>

}

... from "block" to "inline" in a stylesheet that is otherwise unchanged would be ace.

Hope that is clearer on my aim!

TT

[TonyM]

TT,

This requirement is a fundamental aspect of the customise solution, which started with an idea called dot paragraphs. 

This idea had a leading . on any line causes subsequent lines to be treated as a single paragraph unit a \n is reached.

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

\customise tick=div _element=div

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

In short it is I believe already possible.

Tones

[PMario]

On Thursday, October 22, 2020 at 1:53:41 PM UTC+2, @TiddlyTweeter wrote:

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

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

 

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

1 - INLINE markup, I commented on before, that IMO we should AVOID doubling. Having to type @@text    bits@@ just to get a span is very uneconomic.

     IMO inline markup needs to be (a) the least obtrusive; (b) with the least keystrokes.

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

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

But I personally think, that's confusing.

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

The pragma will be:

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

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

It my be used like this:

°°symbol.class:param some text/°

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

 

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

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

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

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

 

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

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

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

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

 

We need glyphs SPECIFIC for inline to ensure minimalism in design.

Those two characters are visually excellent for that job.

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

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

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

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

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

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

 

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

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

 

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

That's right.

-mario

[PMario]

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

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

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

IF:

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

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

Pragma Comment

Could be

\\ comment comes here till the end of the line

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

\\\define test()

\\ your code comes here, but this definition is commented out

\\\end

-mario

[PMario]

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

Pragma Comment

Could be

\\ comment comes here till the end of the line

We are lucky :)

 

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

 

\\define test()   <- this is a comment now
\\ this comment is as slow as
\\<!-- html comment: since it produces a parse tree element. -->

\\end  <- this is a comment now

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

-m

[PMario]

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

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

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

hmmm.

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

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

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

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

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

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

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

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

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

 - And Braille 2345, which is letter: t

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

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

eg:

⠒.x some text.⠒.y.z:a1:a2 some nested text⠶⠶

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

mario

[TonyM]

Mario,

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

I understand open and close needs to be asymmetric to see which is which. But the solution such as 

/glyph content glyph/  - inline
or
glyph content /glyphline  - para or block

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

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

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

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

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

Perhaps even this could work

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

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

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

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

This of course should still work!

glyph.classname

Something /glyph.classname content /glyph more

A word of warning;

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

Another restatement of desire or intent on my part.

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

The first thing I really need is

° one
° two
° three

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

Now consider 

one
two


three

four

Say this is found text, on the internet, from a copy and paste

This currently renders as 

one two

three

four

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

° one
° two
°
°
° three
°
° four

Then depending on my custom wiki text definition;

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

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

° one
two

 
° three

four

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

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

There seems to me to be a gap between these two cases above, I have not learned to do, and it appears impossible;

I am not even sure I can illustrate the problem (Which is bugging me)

Lets see if I can in a future post

Tony

[PMario]

On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote:

Mario,

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

I understand open and close needs to be asymmetric to see which is which. But the solution such as 

/glyph content glyph/  - inline
or
glyph content /glyphline  - para or block

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

Inline syntax defaults to a SPAN. The inline  wikitext syntax doesn't care about linebreaks.

So it can /° start in the middle of the line,

and end at the start of the line

°/ it  will create a span and show all the text in 1 line by default.

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

-m

[TonyM]

My Response [edited]

On Saturday, 24 October 2020 13:46:22 UTC+11, PMario wrote:

On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote:

Mario,

Inline syntax defaults to a SPAN. The inline  wikitext syntax doesn't care about linebreaks. 

So it can /° start in the middle of the line,

and end at the start of the line

°/ it  will create a span and show all the text in 1 line by default.

Agreed, In fact sometimes that what we want to do. Take an inline slab and treat it differently even if it contains line breaks eg a Quote however more often and not we choose either;

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

Perhaps we can call these 4 "customised pragma forms". 

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

I don't know yet, but one glyph should be unencumbered with any defaults. And perhaps others may be used for html/buttons/macros by default. I just do not know enough about all the possibilities, and a way to categorise them yet, perhaps only with usage will we determine which glyph is best at representing which kind of customise (intuitively). When we know this we would find it easy to determine how many glyphs we need to provision, what general usage categories they fit in, and appropriate glyphs to represent each category. This is a bit of a "putting the cart before the horse problem".

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

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

One that comes to mind is a simple way to mark text as a comment and toggle its visibility, through either customising or some other state. Comments may be of the  4 "customised pragma forms". above.

Regards

Tony

[TonyM]

Edited in Forum

[@TiddlyTweeter]

Ciao PMario

On Underscore

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

A few points.

1 - I AGREE that underscore is BETTER for INLINE than BLOCK. 

      Visually "_" initiates an implying that "sequestered" text (i.e. contained _text bits__)  will be styled. 

      It really is better for inline, but never blocks.

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

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

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

Best wishes

TT

[@TiddlyTweeter]

On Pairing Syntax -- Visual v. Conceptual Problems 

PMario wrote:

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

I AGREE.

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

The problem is both visual and conceptual.

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

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

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

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

My thoughts

TT

[@TiddlyTweeter]

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

PMario wrote:

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

That is a shame :-(.

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

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

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

_S.in _S.in _S.in _S.in _S.in _S.in _S.in _S.in _S.in _S.in

... versus ...

_S.in__ _S.in__ _S.in__ _S.in__ _S.in__ _S.in__ _S.in__ _S.in__ _S.in__ _S.in__

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

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

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

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

Best wishes

TT

[@TiddlyTweeter]

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

PMario wrote:

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

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

 - And Braille 2345, which is letter: t

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

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

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

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

I think that pair is an EXCELLENT choice.

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

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

Thoughts

TT

 

[@TiddlyTweeter]

On Being Able To Comment Custom Markup Pragma

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

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

Best wishes

TT

[@TiddlyTweeter]

Final Plea for TWO Inline markers

PMario wrote:

Yes. There will be only 1 inline maker ...

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

Why?

1 - Let's take the Braille possibility. It is EXCELLENT visually as we already discussed. But what if you are blind?  You need Braille.

     Giving a SECOND markup syntax you can let braille writers/readers use Custom Markup without them having to use Braille symbols.

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

This _encloses _an enclosure____

... or this? ...

This _encloses ⠒an enclosure⠶__

The last version is much easier to read.

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

Best wishes

TT

[@TiddlyTweeter]

Ciao Tony

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

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

The issue is NOT Custom Markup per se. Assume that is DONE already. And well.

Rather, the issue is DYNAMIC modification of CSS style values for styles already applied.

The Palette macro instantiates an economical stable approach that illustrates a solution.

IF you have time to explore this it could be useful. For ...

1 - MY needs;

2 - WIDER demonstration of the utility of macros UNDER Custom Markup.

I think it is point (2) that has most gravitas.

Best wishes

TT

[TonyM]

TT,

Perhaps this quick answer demonstrates what you are after?

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

´q this is a question
´a This is an answer
´q this is another question
´a This is another answer

answers will only be displayed if the field display-answers on the current tiddler = block or inline (not none)?

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

Regards

Tony

[TonyM]

Folks,

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

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

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

´sig

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

Tony

 

On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:

Hi folks,

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

Let's start a new one before [2] starts to use pagination.

Have a closer look at link [1] it's possible to show all the topics in 1 page

starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ the above link won't work anymore!

have fun!

mario

[TonyM]

Mario,

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

Internal JavaScript Error

Well, this is embarrassing. It is recommended that you restart TiddlyWiki by refreshing your browser

Uncaught TypeError: Cannot read property 'configTickText' of undefined

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

Regards

[PMario]

On Saturday, October 24, 2020 at 1:35:47 PM UTC+2, @TiddlyTweeter wrote:

Final Plea for TWO Inline markers

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

-m

[PMario]

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

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

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

mario

[PMario]

On Sunday, October 25, 2020 at 12:59:38 AM UTC+2, TonyM wrote:

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

´sig

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

IMO it should be done "the old way" with:

\define sig() Mario Pietsch

<<sig>>

But inline This is some text written by <<sig>> the author

Which imo is much simpler code and clear for everyone, which is familiar with TW

-mario

[TonyM]

Mario,

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

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

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

Regards

Tony

[TonyM]

Folks,

Just sharing some Unicode exploration

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

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

3010 【 LEFT BLACK LENTICULAR BRACKET 3011 】 RIGHT BLACK LENTICULAR BRACKET

You can also turn them into SVG icons

<svg height="22pt" width="22pt" style="font-size: 200%; fill: green;">
  <text x="0" y="22">𝝣</text>
</svg>

Of note all the standard characters have a mathematical equivalent.

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

Also I found a set of small punctuation symbols, that look the same only small, but they are separate characters

https://www.unicode.org/charts/PDF/UFE50.pdf

so we could use ﹙ to mark inline ﹚ then continue

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

[TonyM]

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

Tony

[@TiddlyTweeter]

Ciao TonyM

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

In your case here you likely on safe(ish) ground.

But it would be worth checking the individual listed TW fonts to establish that end users can SEE them always.

BabelMap is a free Unicode/font tool to do that.

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

We not there yet.

Best wishes

TT

[@TiddlyTweeter]

Ciao Tony

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

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

I DO think taking Unicode more seriously in TW is definitely a good idea. 

Frees us up from the standards of 1986 that are no longer needed. 

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

Best wishes

TT

On Monday, 26 October 2020 02:21:44 UTC+1, TonyM wrote:

[@TiddlyTweeter]

How Can Unicode Help?

I, for myself, did a UNICODE exploration of PAIRED MARKUP characters. 

By "markup" I actually mean LITERAL markup characters used by workers in the PRINT industry. 

No Maths was added.

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

Let me know IF you want me to post these!

Best wishes

TT

[PMario]

On Monday, October 26, 2020 at 2:21:44 AM UTC+1, TonyM wrote:

so we could use ﹙ to mark inline ﹚ then continue

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

Looks interesting. But you have to test like so:

(﹙symbol.class:param some text﹚)  or  (﹙symbol.class:param some text﹚) ... there is no visual connection between the glyph and the symbol name. eg: /°symbol.class:param. It looks as if there is a space already, which will lead to problems.

-mario

[PMario]

On Monday, October 26, 2020 at 2:21:44 AM UTC+1, TonyM wrote:

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

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

-m

[@TiddlyTweeter]

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

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

TT

[TonyM]

Mario,

I am not sure what you mean here. I was thinking more of

﹙symbol.class:param some text﹚

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

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

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

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

Regards

Tony

 

-mario

[PMario]

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

...

﹙symbol.class:param some text﹚

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

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

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

It: "﹙" looks like <space>char<space> ... ...

Did you find a "smaller version"?

-m

[PMario]

Hi folks,

Please continue discussions here: Custom markup (continued 4)

-m

[TonyM]

Mario,

This is a nice resource.

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

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

Tones

[@TiddlyTweeter]

Using Unicode

Hi TonyM

In the spirit of learning about using Unicode ...

You can also turn them into SVG icons

<svg height="22pt" width="22pt" style="font-size: 200%; fill: green;">
  <text x="0" y="22">𝝣</text>
</svg>

Right. And not so right.

The issue is that Unicode is NOT a font. Its simply a  code for a character.

The actual font representation you see will DIFFER with the font that is rendered.

That will differ according to fonts available and their substitution cascade on target systems.

To try make this clearer for you look up Unicode 25B6, that's HTML &#x25B6;

Its in Unicode called: BLACK RIGHT-POINTING TRIANGLE.

In much net use its the "Play Button" ...

And look here to see examples of the result on different systems ... https://emojipedia.org/play-button/

Point is in design for on-line usage often you need to explore the fonts that will exist on target users systems for consistency.

Best wishes

TT

[@TiddlyTweeter]

TonyM wrote ...

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

Right. That is a chart of Unicode "Supplementary Plane: Mathematical Alphanumeric Symbols". Unicode 1D400 to 1D7FF (996 characters).

Something you may not yet be aware of (it would be useful for you to know, I think!) is that the characters can't always be represented using a single character directly (applies to characters above FFFF). 

At the end-user level this is not an issue if you dealing visually. But it CAN be an issue in search & coding. All Unicode can be represented BUT there is more than one method! One for the  Unicode Basic Multilingual Plane characters (up to FFFF) and other ways above that retrofit to webpage address space by "combining characters".

FYI I looked up the font substitution cascade on my local computer (Win 10 default fonts) for  "Mathematical Alphanumeric Symbols" and the only main font that supported them is Cambria Maths.

IMO, on the whole its worth looking though the Basic Multilingual Plane first for characters before additional planes (which have some caveats I mentioned). The Basic Plane is itself massive!

Best wishes

TT