Custom markup (continued 4)

[PMario]

Hi folks,

This is the continuation of 

 - Custom markup [1]

 - Custom markup (continued)

 - Custom markup (continued 2) [2]

 - Custom markup (continued 3) [3]

 

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

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

starting with  https://wikilabs.github.io/editions/custom-markup/ !

have fun!

mario

[PMario]

Hi,

V 0.7.0 - 2020-10-23

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

NO \customize inline functions yet.

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

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

a)

 - start: 2 underscores: __

 - end: 3 underscores or 1 underscore slash : ___ or _/

b)

 - start: /°

 - end: °/

c)

 - start: ⠒

 - end: ⠶

d)

 - start: ﹙

 - end: ﹚

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

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

-mario

    switch (this.match[1]) {

        case "__":

            reEnd = /___|_\//g

        break;

        case "/°":

            reEnd = /°\//g

        break;

        case "⠒":

            reEnd = /⠶/g

        break;

        case "﹙":

            reEnd = /﹚/g

        break;

    }

[TonyM]

Mario

Thanks for the update today. I will review in the next few hours.

In responce to your last reply, to me the small brackets,

do not look like they are surrounded by spaces in  tiddlywiki.

I will look at the 4 possibilities above, my current personal preference is d, b, a, c;

but I want to look at the outcome with customise inactive.

I am not sure why you say new inline functions then you say no inline customise functions.

Do you mean inline works with underscore, you just can not customise it?

regards

Tony

[PMario]

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

I am not sure why you say new inline functions then you say no inline customise functions.

Do you mean inline works with underscore, you just can not customise it?

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

At the moment the plans are:

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

_endString will be _not_ configurable.

_mode has to be fixed to inline

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

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

-m

[TonyM]

Mario,

A few observations.

Again please don't be overwhelmed just consider these ideas please. Nor do these ideas imply it demands your work, although in some cases that is most likely.

The key issue I am grappling with is the systemisation of glyphs, symbols and the scope of customises wiki text. To make this easy to use and remember. Presently I always need to lookup the reference material and slowly construct wikitext, if its slow and hard for me (involved in this project from the start) it may appear impossible to future new users. There are differences in the way Mario, TT and myself envision this, until this is cleared up even testing will be clumsy apart from helping future users.

Observed - In a tiddlywiki without custom mark-up

This is some Text __.test Inline text ___ with more

fails gracefully

;This is some Text __.test Inline text _/ with more

Fails ungracefully. Disrupts future wiki text.

Question Example the details in https://wikilabs.github.io/editions/custom-markup/#Customize%20the%20Details%20Element

In this example I use a custom endString basically /symbol 

\customize tick="d" _element="details" _classes=".notop.cbox.cbox-primary.hard-linebreaks" _endString="/d" _mode=block
\customize tick="s" _element="summary" _classes=".margin-init"  _endString="/s"

´d ´s Details - Summary
/s
line 1
line 2
/d

´d

´s Details - Summary

/s

line 1

line 2

/d

Is there any reason why we could not make this a default end string, ie the "/symbol" automatically. unless specified for such blocks.

Then allow the end string to be set to a logical "\n" or "\n\n" for the automatic closure at end of line or end of double line break/paragraph.

Also can you explain or document a little "the use of this nesting" ?

´d ´s

as I understand it ´s follows ´d and a <space> so it looks inline, but I assume it is not, 

can we say "customise blocks can be nested by following one with another on the same line, but only at the beginning of the line or at the beginning of subsequent lines" 

Just to get a more general statement?

I love the demo

wow ﹙symbol.class:param some text﹚ nice

There is also a superscript and subscript form of these (Not the same as each other ﹙﹚₍₎⁽⁾

⁽this is some text⁾
₍this is more text₎

To me these are two use full pairs to use glyphs for inline content. 

• Obvious but subtle
• Open and close are single characters
• Would just look like a textural mark up without custom wiki text plugin.
• Provides two/tree pairs for different applications

The use of the Greek delta to represent change may be useful at some point as a glyph.

Question - See diacritical markers

• Could we have any clashes with these?

Question - customised Glyphs, a glyph too far?

• As you can see the wide range of glyphs available that have meaning or structure makes me wish to ask if we could allow the user to nominate glyphs either single (line/para/blocks) or pairs for inline or block. ie customise the customise glyphs.
• This would mean we only choose a few and let the user define extended glyphs (only if they want to take the red pill), this could reduce some missuses if people must add more to get more complex
• The EditorToolbar buttons would then apply a currently selected glyph or can be cloned to create a new set of buttons for another glyph/or pair.
• Using either the actual glyphs for the button or an svg version (below)
• I realise this level of customisation may be problematic but it will solve other problems like forcing us to choose glyphs. I only ask because of its desirability, but have know Idea if coding wizardry permits, even if a reload is necessary.

<svg height="26px" width="24px">
  <text x="0" y="24">⁽ ⁾</text>
</svg>

<svg height="26px" width="24px">
  <text x="0" y="22">₍ ₎</text>
</svg>

Note 'y="22"' here, lest it be "trimmed" at the bottom.

So to my thinking about glyphs 

This is done without a detailed response to existing uses and I stand to be corrected, they are suggestions only, more to share the organising principal than the specific glyphs.

In this case the glyphs differ by their default scope ie where they terminate

Pre-prevision two inline braces glyphs

• ⁽ ⁾ superscript additional braces open and close defined
  
• ₍ ₎ subscript additional braces
  

Pre-provision beginning of line glyphs

• › suggests, one end of line (eol) which is terminated with "\n" by default - A single line glyph like * and #
  
• » suggests, two eol, which is terminated with "\n\n" by default - A paragraph responsive Glyph
  
• An alternative or additional paragraph responsive glyph "¶  pilcrow sign" is still in my view  a valuable one and could be used with ⁋ REVERSED PILCROW SIGN to wrap a block and force a paragraph element.
• ´ tick like "›" but ´ suggests special mark-up follows, which is terminated with "\n" by default, or /symbol if symbol is used (an no alternative given) ie if symbol is used can be used as a block, only terminating on /symbol
  
• Useful with html and widget matching symbols eg ´div.classname some text or lines /div (if necessary we could use ⁄ instead of /
• ° which is terminated with "\n" by default - but can be terminated prematurely with /° (or °/ allowing one to just use the content before /° as the src in the custom, leaving the rest of the line to be wikified as normal. Main glyph used for parameter passing
• The use of °  then °/ implies the use of  /° content °/ where the ° operates inline, perhaps to support this we allow / to proceed a glyph without altering it 
• eg

°trans:p1 tiddlertotransclude °/ Futher wiki text

/° the / is ignored here but does allow a glyph to proceed it to be used as it it was the first character on the line °/
But given this then
/´ may imply ´/ may be used to prematurely close tick. (suggested as \n by default as a line based glyph)

Pre-provision block focused glyphs

• ≈ Suggests multiple lines, and expects closure, perhaps /≈ by default? ie /glyph, rather than /symbol
  
• ≋ Or similar could be used to represent larger blocks, and expects closure, perhaps /≋ by default? ie /glyph, rather than /symbol
  

On entering the glyphs in wikitext

• Perhaps a special toolbar button with short cut eg: alt-insert N (then a OL list) N were hitting a number key will insert that glyph (in a fixed order) 
• no other special handling like your current solution. 
• No space or otherwise, this is the users responsibility, including closure.
• At least the glyphs will always be at hand with a simple set of keys
• An additional button and short cue eg ctrl-insert for a user selected list of "symbols" could be provided that could be used to access any symbol for customise and other applications.
• The current solution could be changed to be used only for "canned" and prepared customise strings.

Fullwidth characters

• There is a set of uni-code characters called fullwidth
• Tilde curly braces, square and parentheses and bar, including broken bar, punctuation and alpha-numerics that are all unique and separate characters. 
• I am confidence tiddlywiki supports this, but the worst case is customise comes with a raw tiddler loading an appropriate font.
• "ｌ" list is an example lowercase l
  

A random Idea

• I used to use a character combination to annotate lines on personal hand written notes, I have found unicode versions, they always live at the end of a line
• ? a question (A question) Special forms of these also exist.
• ! an answer (asserted / definitive answer)
• ⁇ Question this, it is unlikely to be true 
• ⁈ You must question this, question - asserted 
• ⁉ Believe it to be true - asserted but could question
• So I wonder like your prior work on <space><spaces>\n if we could introduce a end of line type of custom pragma. ie it has no beginning of line, or inline or block characteristics (by default)
• In a sense inline but only end of line (\n). Used inside ⁉ means nothing.
• This also means it would typically not have any input (other than symbol, class or :p) unless it detected \n vs \n\n

Perhaps another random and radical idea?

• As you may know there are special spaces such as 

  U+FEFF

  ZERO WIDTH NO-BREAK SPACE

• These is used as glyphs will be invisible both in the editor and rendered output with or without the customise plugin. 
• Suggests interesting possibilities and if not using "customise plugin". symbols or .classname or :parameter will be invisible anywhere. Makes for highly transferable text. Ie no impact when copied and exported elsewhere.
• Arguably we could do something to make them appear visible only in the tiddlywiki editor. eg a font character remap.

In closing;

• In truth once again I am straying into further extensions of possibilities in these notes. 
• However it seems to me this is a valuable "look ahead" in an attempt to inform the current project to achieve the best outcome.
• If we are using Extended Unicode as our glyphs, and possibly symbols, this does suggest we need to be well informed in Unicode, hence my explorations here.
• Extended Unicode do need a font that will represent them, however it seems most are covered already with default fonts, and if it were necessary adding a full back font is trivial, to include with customise.
• I do declare as per posts elsewhere, what I am learning from this exploration of Unicode has very interesting design implications as raised here. The use of additional character sets within tiddlywiki as it stands, without customise or special fonts provides a whole set of namespaces. This has implications for the designer especially if they limit the use of these characters to their own code and tiddler titles. and example is the word description is an existing field but the word description in another character set could be the name of a tiddler that defines the description field and how to view or edit it.
• In many ways these lessons make sense to raise within this project because it is all about  glyphs and symbols, which are critical to the success of the customise wiki text solution.
• My experiments so far suggest making use of extended Unicode is already effective and operational in tiddlywiki by virtue of its standards based implementation. 

Regards

Tony

[TonyM]

To clarify,

The following is about the use of underscore or another glyph to handle "inline custom wiki text."

I am not sure why you say new inline functions then you say no inline customise functions.

Do you mean inline works with underscore, you just can not customise it?

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

That is fine, thanks for clarifying

 

At the moment the plans are:

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

Great, do we need to suggest only to use inline html elements within this? This is a good reference for html block vs inline https://www.w3schools.com/html/html_blocks.asp

• I plan to make extensive use of the difference in future with customised wikitext.

 

_endString will be _not_ configurable.

Makes sense if we pre-configure the closure, and define a glyph or set of glyphs of the "inline type"

As in my previous email perhaps some glyphs should also have a default block type pre-set, and a few with neither set.

 

_mode has to be fixed to inline

Again makes sense. that is what it is. See my last post for an attempt to rationalise this and my objections to underscore, which I may add has already cause problems be cause it is hard to see the difference between _, __ and ___ if they are separated by any distance or in different fonts.

 

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

Not sure what you mean here, but is it like my objection to undersore?

 

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

Exciting.

Tony

[PMario]

On Wednesday, October 28, 2020 at 1:14:30 AM UTC+1, TonyM wrote:

A few observations.

Again please don't be overwhelmed just consider these ideas please. Nor do these ideas imply it demands your work, although in some cases that is most likely.

The key issue I am grappling with is the systemisation of glyphs, symbols and the scope of customises wiki text. To make this easy to use and remember. Presently I always need to lookup the reference material and slowly construct wikitext, if its slow and hard for me (involved in this project from the start) it may appear impossible to future new users. There are differences in the way Mario, TT and myself envision this, until this is cleared up even testing will be clumsy apart from helping future users.

Observed - In a tiddlywiki without custom mark-up

This is some Text __.test Inline text ___ with more

fails gracefully

;This is some Text __.test Inline text _/ with more

Fails ungracefully. Disrupts future wiki text.

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

-m

[TonyM]

Mario,

_endString will be _not_ configurable. 

I agree with this but ask if if it makes sense to be auto-terminated with \n or \n\n  

am I wrong to think Typically inline does end at a line or paragraph break?

So if we use the glyphs I suggested ⁽ this is inline⁾ this inline ⁽.coda at the end will be honoured

• "coda" is a term used as in the finishing notes in music that end the piece gracefully.
• In this case it would be an end of line sequence
• Arguable we may use 

´something ⁽ rest of line using inline
or
⁽ just reusing the inline to the end of line (from the beginning)

• I suggest this only because there may be a lot of cases where inline is used to highlight text
• Not demanding closure may reduce incidental errors when closure omitted.
• This same highlight may be reused in lines as well
• No need to define another all but identical line of paragraph terminated custom wikitext just to use the same formatting as an inline definition.

This is a sentence ⁽.mark.yellow this text singled out⁾ but this text just sentence. Note no space proceeding close.

´something ⁽.mark.yellow rest of line using inline
or
⁽.mark.yellow just reusing the inline custom for a whole line.


*⁽.mark.yellow Item 1 highlighted
*⁽.mark.green Item 2 differently highlighted.

I think inline puts us on the "home run".

Tony

[TonyM]

Minor additional note

A random Idea

• I used to use a character combination to annotate lines on personal hand written notes, I have found unicode versions, they always live at the end of a line
• ? a question (A question) Special forms of these also exist.
• ! an answer (asserted / definitive answer)
• ⁇ Question this, it is unlikely to be true 
• ⁈ You must question this, question - asserted 
• ⁉ Believe it to be true - asserted but could question
• So I wonder like your prior work on <space><spaces>\n if we could introduce a end of line type of custom pragma. ie it has no beginning of line, or inline or block characteristics (by default)
• In a sense inline but only end of line (\n). Used inside ⁉ means nothing.
• This also means it would typically not have any input (other than symbol, class or :p) unless it detected \n vs \n\n

End of line only mark up, with selectable glyphs, Would allow someone like me to define a glyph  "¶" as "<br>br>" so insertion of ¶<space> would render as a new paragraph "break". This provide the complement to beginning of line and inline mark-up.

Regards

Tony

[PMario]

On Wednesday, October 28, 2020 at 1:50:19 AM UTC+1, TonyM wrote:

Mario,

_endString will be _not_ configurable. 

I agree with this but ask if if it makes sense to be auto-terminated with \n or \n\n  

am I wrong to think Typically inline does end at a line or paragraph break?

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

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

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

-m

[PMario]

Hi Tony,

Very good questions. ... all of them.

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

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

With strict rules it would need to look like this:

´d

´s some text

some text

----   <-- _endString

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

-mario

[TonyM]

It must be late for you - good night

Tony

[@TiddlyTweeter]

Regarding Using UNDERSCORE - Don't

PMario wrote:

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

Quick observation. 

I think it is a mistake to consider underscore in any Custom Markup. For several reasons ...

1 - IMO, if we have to switch off the EXISTING underline method (__text bits__) in WikiText it would be confusing & and could break users existing markup in Tiddlers. 

2 - AND having both the existing method for the U element and the Custom Markup SPAN element just adds complexity that will make small errors much harder to pin down.

3 - Nesting if we go with ...

reEnd = /___|_\//g

... will produce WikiText that gets difficult to read and is over verbose. For instance ...

We built a ___.h house ___.o on a hill_ _ with a long fence.

... and IF we retain existing underline method it gets even worse ...

We built a ___.h house ___.o __on__ a hill_ _ with a long fence.

Basically, I think its a mistake to use underscore anywhere in Custom Markup!

Custom Markup should use it's own, never used before, glyphs. 

An opinion

Best wishes

TT

 

[@TiddlyTweeter]

Number Of Inline Custom Span Markers? - Two is Enough!

PMario wrote:

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

I think TWO  is good. It's got particular usefulness for easier reading of nested WikiText ... for example ...

/°.b4 He opined on the ⠒.za general remit⠶ of the Higgin's bomb°/ lest it be...

I also assume that existing WikiText span pair (@@ ... @@) will continue to work, so, in effect, you have THREE in total ... (2 x self-nestable; 1 x not-self-nestable) for example ...

/°.b4 He opined on the ⠒.za general remit⠶ of the @@.aa Higgin's bomb@@ °/ lest it be...

So more than two Inline Custom Markup glyph pairs looks redundant.

Best wishes

TT

[@TiddlyTweeter]

Point on Nesting "﹙﹚". Don't have them if they don't nest the same way as the others!

PMario 

d)

 - start: ﹙

 - end: ﹚

...

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

The nesting behaviour of Inline Custom Markup pairs should be fully consistent! 

If the behavior of  "﹙﹚" pair differs it will likely create confusion!

Best wishes

TT

[@TiddlyTweeter]

What Are UNambigous Markup Pairs? -- where the open & close characters are each SINGLE different characters.

Ciao PMario & TonyM

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

c)

 - start: ⠒

 - end: ⠶

d)

 - start: ﹙

 - end: ﹚

Purely logically these pairs of SINGLE characters are far preferable to multi-character pairs!

Multi-character pairs will be prone to typing errors ... For instance  ...

This /°.n6 looks nice enough°/ for reading

But could very easily get yourself in a knot.

This /°.n6 looks nice enough°/ for reading till you make a /°small/° error.

Having multi-character pairs should be avoided. Especially for inline markup where typos and other errors are harder to spot.

Using a pair of SINGLE unique characters is by far better as their use is immediately determinate and less verbose.

Best wishes

TT

[@TiddlyTweeter]

On Why ﹙ ﹚ is a BAD idea. Far too like (  ).

Ciao TonyM & PMario

Whilst I understand TonyM's push for this it has POOR READABILTY.

It is far too like conventional parenthesis (round brackets). For instance ...

He stood upon the ground (terra firma) v. he stood upon the ground﹙terra firma﹚.

Which is which? It is NOT immediately obvious.

In addition, conventional brackets in normal writing can have semantic importance that this construct muddies up.

Lets look for an alternative please!

Best wishes

TT 

PMario wrote:

d)

 - start: ﹙

 - end: ﹚

[@TiddlyTweeter]

Note On EndString & Mode -- Agreed & More

PMario wrote

_endString will be _not_ configurable.

_mode has to be fixed to inline

Makes much sense.

INLINE, much more than BLOCK, is about fluidity of writing. 

A simple approach looks appropriate.

Inline that I'm most concerned that markup is as COMPACT AS POSSIBLE (i.e. single character open & close strings). The MAIN innovations in your approach are ...

1 - enabling the use of HTML INLINE ELEMENTS (eventually).

 and

2 - NESTING. 

IMO this combo will do more to AID WRITERS than any other aspect of Custom Markup.

It is a far superior to current Inline WikiText which is an over verbose and a somewhat blunt instrument.

Best wishes

TT

[@TiddlyTweeter]

Block & Inline are Different Things. Having separate definition spaces remains a good idea. 

Ciao PMaio & TonyM

PMario wrote:

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

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

With strict rules it would need to look like this:

´d

´s some text

some text

----   <-- _endString

I think the distinction between INLINE & BLOCK remains valid. Of course you can argue one can glide one into the other. But I'd need convincing that the basic distinction should be messed with. Customize each separately. You could still use \customize to change behaviors for any element.

Best wishes

TT

[@TiddlyTweeter]

Regarding User Possibility To Set Markup Glyphs?

TonyM wrote:

Question - customised Glyphs, a glyph too far?

• As you can see the wide range of glyphs available that have meaning or structure makes me wish to ask if we could allow the user to nominate glyphs either single (line/para/blocks) or pairs for inline or block. ie customise the customise glyphs.

 Ciao TonyM & PMario

IF this were possible I WOULD use it.

Why? Because the kinds of Markup I do would benefit from me being able to choose glyphs VISUALLY SUITED to the purpose.

For instance, for simple paragraphs ...

¶ Start of a paragraph,
more of the same pargraph endedon the next line.
⁋ <--- End String

I understand if its not possible. 

I assume the current approach is hard-coded JS?

Just a thought to say TonyM & I on this idea concur.

Very best wishes

Josiah

[PMario]

On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:

Regarding User Possibility To Set Markup Glyphs?

TonyM wrote:

Question - customised Glyphs, a glyph too far?

• As you can see the wide range of glyphs available that have meaning or structure makes me wish to ask if we could allow the user to nominate glyphs either single (line/para/blocks) or pairs for inline or block. ie customise the customise glyphs.

 Ciao TonyM & PMario

IF this were possible I WOULD use it.

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

 

Why? Because the kinds of Markup I do would benefit from me being able to choose glyphs VISUALLY SUITED to the purpose.

For instance, for simple paragraphs ...

¶ Start of a paragraph,
more of the same pargraph endedon the next line.
⁋ <--- End String

I understand if its not possible. 

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

TW Pargraphs end with \n\n by default

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


I could implement:

¶ some text \n\n





Since it would be the right thing to do. see: Wikipedia Pilcrow. It would be easy to explain, with the link to Wikipedia. It will create a HTML P tag by default.





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


-mario

[TonyM]

Mario,Josiah

¶

I would not bother with the use of pilcrow unless it was part of an end of line form of glyph only. Its key use would be to place a pilcrow in a large slab of text to force a pagarapgh break. if other glyphs depended on \n\n, it would be best to resolve these first if possible. There is a implied new paragraph that follows the ¶ that is sufficient in my view (as for this paragraph). If one was to have a start and end the appropriate method is a revers-pilcrow and pilcrow pair.

End of line only mark up, with selectable glyphs, Would allow someone like me to define a glyph  "¶" as "<br>br>" so insertion of ¶<space> would render as a new paragraph "break". This provide the complement to beginning of line and inline mark-up.

 

Arguably the ¶ could be given a definition that highlights the first word of the next (generated paragraph).

 

Josiah, I don't mind decent, however I disagree with the lack of visibility with "the" parenthesis, and value how the look. First with Custom wiki text present they disappear in the output. Secondly we can use the slightly different examples given. My point here is if something is not good enough ⸨rather than exclude it⸩ find if there is a way to 〖 address 〗 it, such as ⁽ Here ⁾ or ₍ there ₎ remember as a rule already text contains ' " ` and other characters even less readable. The fact that a reader may not be able to tell the difference may actually be an advantage when no customisation is occurring.

If we have two (or more) open and close braces there is an opportunity to define one as non-operative in text that contains one of the other pairs. The point being the only reason they will be in use is because the writer chooses to.

I am actually keen to use such Unicode braces simply to delimit a piece of text, I would write separate macros to extract those ﹤keywords and phrases﹥ so delimited, independent of the current text even without the use of customise. However if such pairs are available to "custom wikitext" further automation or formatting can be done to automate this feature.

Tony

[TonyM]

Mario,

Just a thought, if the customise definition was to accept both glyph and symbol as parameters this may be an easier approach.

\customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight _classes=".highlight" _mode=inline

even an new \customise-def that accepts _glyphs and _glyphNames and \customise does not.

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

Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent use such as

\customise openenc _classes=".highlight-green"

In effect a redefinition, like the current customise.

In the worst case there will need to be a start-up process that puts glyph definitions in a specific tiddler into a table, ie reload to add new glyphs.

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

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

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

Regards

Tony

On Thursday, 29 October 2020 01:53:12 UTC+11, PMario wrote:

[TonyM]

Gentlemen,

The attached local view template demonstrates the use of additional code in a specific tiddler. 

• In this case of you add the field local-viewtemplate to any tiddler in the edit view and a new editable field appears. This will be applied through the view template.
• Please try it, it is immensely useful for research and experimentation on view Template code.

I can see using this or something similar for the application of various customise definitions only on the local tiddler.

• Keep in mind a local-customise field could contain also a transclusion such as {{extended-markup}} to include a custom mark-up template, or \importcustom [[pragma-details]]
• I am still to make this work for customize, but Mario would know how to of the top of his head.
• Note the customised wiki would not apply if the text field were transcluded elsewhere but we could have a template that does include the local-template or local-customise in a Transclude (if it exists) eg {{tiddlername||$:/template/render-with-custom-wikitext}} 

Regards

Tony

Regards

Tony

[PMario]

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

Just a thought, if the customise definition was to accept both glyph and symbol as parameters this may be an easier approach.

\customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight _classes=".highlight" _mode=inline

even an new \customise-def that accepts _glyphs and _glyphNames and \customise does not.

Those definitions will need to be done at startup time.

 

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

That's right.

Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent use such as

\customise openenc _classes=".highlight-green"

In effect a redefinition, like the current customise.

In the worst case there will need to be a start-up process that puts glyph definitions in a specific tiddler into a table, ie reload to add new glyphs.

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

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

 

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

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

 

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

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

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

 

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

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

-mario

[PMario]

On Thursday, October 29, 2020 at 1:17:11 AM UTC+1, TonyM wrote:

Gentlemen,

The attached local view template demonstrates the use of additional code in a specific tiddler. 

• In this case of you add the field local-viewtemplate to any tiddler in the edit view and a new editable field appears. This will be applied through the view template.
• Please try it, it is immensely useful for research and experimentation on view Template code.

Hi Tony,

I got it working, but I think I'm the wrong person here. The problem I have with that approach is: I don't understand it.

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

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

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

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

As soon as I need a multiline field I think it is much easier to go the multi-tiddler / multi-story way as shown in the video from 9:30 to 10:30 

TW 5.1.23 will contain some elements, that will make this approach easier. ... BUT there is still more work to do. There are some open PRs and discussions at GitHub.

-mario

[PMario]

Hi,

V 0.8.0 - 2020-10-29

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

and it's crazy!

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

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

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

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

Shortcut buttons and docs is missing.

I didn't test all the possible combinations, since that's really a lot. ...

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

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

have fun!

mario

[PMario]

Hi,

Inline nesting seems to have a problem.

-m

[PMario]

Hi Folks,

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

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

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

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

-m

[TonyM]

Mario,

An Idea, to avoid us returning to a solution which has no additional glyphs config, could be solved by providing a packaging solution, not unlike the bundler plugin. We can just select tiddlers with customise and bundle the definitions and custom definitions to ensure transferability.

Of importance here though, I am suggesting giving the vast majority of users, an appropriate set of pre-defined glyphs, they may never know you can define more. Being able to customise them, apply parameters and classes, use symbols etc... "is more than enough rope". But we know and we can innovate via this new Glyph mechaisium. If we can define a way to distribute a new glyph definition, perhaps in a separate file or plugin then a level of modularisation occurs, even allowing us to build the default glyphs in the same way. There is no harm if it demands a reload, we can force it in a glyph definition plugin, with customise wiki text as a dependency.

This customised wikitext solution is so powerful I think providing such an extencibility feature is wise, otherwise there will be too much pressure to update the core solution, and I do not want this to become a maintenance issue for you. 

As long as we can see what glyphs have being defined, it is possible to search for all tiddlers making use of that glyph, and advantage of using Unicode characters rarely found in content. If I go to export a tiddler with customised pragma, if I identify which defined pragma are in use in the current tiddler, and include their definitions, perhaps not the default (definitions), but also optionally the plugin as well. Then transfer becomes easy.

Now, I must declare knowing what customise can achieve so far, and the wealth of shiny Unicode characters, I am taken by the possibilities for writing my own content with any custom wikitext I desire. I really don't care if its transferable, people can read the rendered results, I can capture static HTML or deliver customisations in any Wiki I want. I am already thinking about a glyph for footnotes or extreme semantics like 

∴ This is the conclusion or therefore statement in my text
;This is another conclusion
:This will be helpful ∴ review and extend these ideas.

That my knowledge base can extract and I can globally reformat in one place. All by customising a meaningful glyph.

Single line mark-ups for questions, answers, therefore, to do, details, references, errors, .... all triggered by glyph<space> With customise wikitext these can be used to trigger tasks, tiddlers, workflows and more all from insertion of a single glyph.

By being able to choose the glyph we can customise meaningful single character mark ups in a highly semantic way, rather that having to remember a glyph/symbol pair.

This is after all offering a personal productivity solution, sufficient to be wiki specific, as much as, a feature for tiddlywiki for lots of wikis.

Regards

Tone=y

[TonyM]

Mario,

Sorry about the overwhelming. I will try and simplify

The attached local view template demonstrates the use of additional code in a specific tiddler. 

• In this case of you add the field local-viewtemplate to any tiddler in the edit view and a new editable field appears. This will be applied through the view template.
• Please try it, it is immensely useful for research and experimentation on view Template code.

Hi Tony,

I got it working, but I think I'm the wrong person here. The problem I have with that approach is: I don't understand it.

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

The use case is an instant view template, that impacts on the current tiddler for ViewTemplate development and testing. Once tested you would move the code to a global viewTemplate and delete the local one, unless perhaps you had a bespoke view template for one tiddler.

The reason I suggest it, is we could have a bespoke \customise wikitext pragma field, for the same development purpose, for later globalisation if desired.

I can build it already I believe, If I can do it with a reference somehow to !!custom-pragma

\importcustom [[pragma-details]]

Regards

Tony 

[TonyM]

Mario,

What you have done is fantastic. I will focus on V 0.8.0 - 2020-10-29 From a testing and features arising point of view. 

I am Happy to stabilise with the current solution as a first release if you want.

My only urgency to raise the custom Glyphs is that your are aware of it as a possibility and desirable. However you have done more than enough to accommodate I, your own and TT's questions and imagination. Its a pleasure working with you.

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

Love your work as usual, and yes the combinatorial complexity is massive. 

We do need to draw the line somewhere. All we need to do is ensure the line does not compromise the future and I think you have that in control.

Regards

Tony

[PMario]

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

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

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

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

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

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

-m

[TonyM]

Mario,

Go how you want, but my understanding comes from the more "modern use" noted later in the Wikipedia entry, truthfully a leading one may confuse me ans many others given this;

The pilcrow is used in desktop publishing software such as desktop word processors and page layout programs to mark the presence of a carriage return control character at the end of a paragraph. It is also used as the icon on a toolbar button that shows or hides the pilcrow and similar hidden characters, including tabs, whitespace, and page breaks. In typing programs, it marks a return that one must type.

I have being keen to make a preview that acts as the aforementioned toolbar button would.

You are right to "produce html output that is well formed", I will return to reviewing the html my tests generate. I not you have many of my prior examples in test tiddlers, thanks its a helpful reference. 

Tony

[PMario]

Hi folks,

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

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

\customize tick=! _element=th

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

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

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

»| 12 text «  and  »

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

»| 22 text

»| 23 text

---
/endTable

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

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

tick-cells are use for single line cells terminated by \n

angle-cells are used for multi, block like cells terminated by \n\n

»===row

   ends with


---


-mario

[TonyM]

Mario,

I think it would be useful to include such "compound customisations" with the plugin or at lest on the plugins website. Although perhaps it could be an optional item that requires tagging.

Having used html tables within wikitext for so long, I find it easier to follow a html table format, and simple closures, as follows;

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

\customize tick=th _element=th

\customize tick=td _element=td _classes=".hl"  _mode=block

\customize tick="tr" _element=tr _mode=block _endString="/tr"

´table ´caption Some caption text

´tr
´th header 1
´th header 2
´th header 3
/tr


´tr
´td 1 text
´td 12 text «  and  »
´td

* cell 13 text
* line 2
* line 3

/tr


´tr
´td 2 text
´td 22 text
´td 23 text
/tr
/table

However if we are considering distributing or documenting "compound customisations" I would be tempted to extend my table to to include a lot more such and head/foot/body, a list widget for both rows and columns, as I would do this for myself anyway.

Perhaps your table responding to classic tiddlywiki tables AND one responding to html tables included would make sense?

Tony

[TonyM]

Mario,

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

It is available on most keyboards.

Regards

Tony

On Saturday, 31 October 2020 00:55:25 UTC+11, PMario wrote:

[TonyM]

Question,

If other glyphs and characters could be selected could we actually redefine existing mark-up with customise?

\customise glyph="*" parameters

*This would then take on the new definition here?

I raise this because this us what the current double underscore is effectively doing.

An example I may use if this was possible is to add underline or bold to H1/H2

This would allow redefinition of mark-up already in a text perhaps even making it behave like another mark-up language.

and additions like

\customise glyph="-" _element="li"

- to accept bullets pasted from GitHub

Tones

[TonyM]

Mario,

I would be keen to see these additional inline glyphs made available. They look like a fusion of [ ] and ( )

It would be ideal for mark-up that involves links or buttons and where the content is considered a title.

*A line with〖 This inline 〗and more

• They also look good when no customisation plugin is in use but does communicate, if it were, this would be treated differently. 
• I would for example use it like [[ ]] but to trigger a button to create the tiddler from a template
• Or 〖task This inline 〗to create from the task template
• Its the more visible version TT is asking for.

However I do want you to retain ﹙ little﹚ for the same reason TT does not want them, they are similar but different to ( ) and less visible. 

• TT can just "not use them" if he does not like them (I say with all due respect).

Tony

[TonyM]

Do note I found these alternate small braces that may be better.

﹙₍ ₎﹚

Regards

Tony

[@TiddlyTweeter]

Ciao TonyM

Quick query. 

When you suggest glyphs can you please also give the Unicode NUMBER!

In that way we can check where they have a chance of working (being in fonts) across platforms & setups.

Best wishes

TT

[PMario]

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

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

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

 

It is available on most keyboards.

yes 

-m

[PMario]

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

This would allow redefinition of mark-up already in a text perhaps even making it behave like another mark-up language.

and additions like

\customise glyph="-" _element="li"

- to accept bullets pasted from GitHub

I was thinking about that too. BUT the github bullet points work in a different  way. eg:

 - aaaa

    - bbbb

and so on. I think I'll create a new plugin for them.

-m

[@TiddlyTweeter]

PMario wrote:

Inline nesting seems to have a problem. 

Right. I noticed that. Hope its solvable!

Best wishes

TT 

[@TiddlyTweeter]

Markup Glyphs Should Be Visually Unique & Not Confused With Normal Writing

TonyM wrote:

*A line with〖 This inline 〗and more

The use of glyphs CLEARLY DIFFERENT from normal text is not just TT's issue!

It's important not to have any default glyphs that look like any common, conventional single glyph. ANY character that renders in font like "(  ... )" is particularly bad and should be avoided.

Looking at your suggestion, the Unicode glyphs from Basic Multilingual Plane: CJK Symbols & Punctuation look workable. ("CJK" means they are Chinese, Japanese & Korean glyphs).

【】〘〙〚〛〖〗

Their HTML entity numbers are ...

&#x3010;&#x3011;&#x3018;&#x3019;&#x301A;&#x301B;&#x3016;&#x3017;

They have default font support on my Windows 10 tablet. But this is via "font substitution" using shipped Asian fonts.

None of the usual fonts European Language speakers would explicitly set in TW settings have any of them except Cambria Maths.

That is not a problem for us on Windows. I'm not sure if its a problem for some Asian TW users. 

ADDED: And I haven't confirmed if it works on Android yet.

Best wishes

TT

[@TiddlyTweeter]

PMario & TonyM

Can you please clarify what you mean here!

Do you mean that are TWO different Unicode glyphs for Underscore being used?

Best wishes

TT

[@TiddlyTweeter]

Ciao PMario

It would be possible to use pilcrows as "start" and "end" of a paragraph, but I don't understand why. 
TW Pargraphs end with \n\n by default

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


The use case I am thinking of is allow me to simplyfy & share with others an approach to correct manuscripts. 

I work often using specialist software to proof edit articles & books for publishers.

This uses a specific method and its own system of glyphs (based on "printers' corrections").

The software involved is very complex and expensive.

I believe there is a way I could do this work in TW using your Custom Markup if I had a few special glyphs.

I could explain it in detail if you wanted---but I don't want to overload you more than we have already :-)

P.S.: By the way the Pilcrow was originally used inline (often coloured red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the flow of a text. 

Vellum / parchment was very expensive so text is as condensed as possible. Paragraphs separated by lines evolved much later and was more to do with the development of printing and cheaper paper.

Best wishes

TT

[PMario]

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

Can you please clarify what you mean here!

Do you mean that are TWO different Unicode glyphs for Underscore being used?

The default behaviour, should do the exact same thing as the existing __underline__ does. ... But it can be customized, if users want.

At the moment, there is a little problem, since custom-markup needs __<space>some text__ ... I'll need to fix that.

-m

[PMario]

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

The use case I am thinking of is allow me to simplyfy & share with others an approach to correct manuscripts. 

I work often using specialist software to proof edit articles & books for publishers.

This uses a specific method and its own system of glyphs (based on "printers' corrections").

The software involved is very complex and expensive.

I believe there is a way I could do this work in TW using your Custom Markup if I had a few special glyphs.

I could explain it in detail if you wanted---but I don't want to overload you more than we have already :-)

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

-mario

[PMario]

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

P.S.: By the way the Pilcrow was originally used inline (often coloured red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the flow of a text. 

Vellum / parchment was very expensive so text is as condensed as possible. Paragraphs separated by lines evolved much later and was more to do with the development of printing and cheaper paper.

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

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

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

-m

[PMario]

On Saturday, October 31, 2020 at 9:19:43 AM UTC+1, @TiddlyTweeter wrote:

PMario wrote:

Inline nesting seems to have a problem. 

Right. I noticed that. Hope its solvable!

V0.8.1 should have fixed it. If not please report!

-m

[@TiddlyTweeter]

TBH my background has helped me a lot in writing for the net. 

I see the content/structure issue totally differently than most people.

That is what happens when you are fluent in Middle English :-).

When you stand back and look at it---"blocks" in HTML/CSS have innovated brilliantly over print media. 

BUT "inline" HTML/CSS seems badly scared to loosen the hold of print! 

Most websites read like newspaper columns.

We are barely using our available freedoms in writing for the net.

Sure this is part OT. But not totally. 

I have to test more, but I'm getting clearer your Custom Markup method will let me PLAY with writing forms viably in the way I want to really.

Best wishes

TT

[@TiddlyTweeter]

Ciao PMario

 

@TiddlyTweeter wrote:

The use case I am thinking of is allow me to simplyfy & share with others an approach to correct manuscripts. 

I work often using specialist software to proof edit articles & books for publishers.

This uses a specific method and its own system of glyphs (based on "printers' corrections").

The software involved is very complex and expensive.

I believe there is a way I could do this work in TW using your Custom Markup if I had a few special glyphs.

I could explain it in detail if you wanted---but I don't want to overload you more than we have already :-)

PMario ... 

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

Okay. Good. 

Actually your pilcrow example is FINE!

My issue is its hard to explain if I can't code it to make examples, but I can't code examples it until its done enough to code them. 

It's a "chicken-and-egg" problem. 

So let's leave that aside for now?

Right now, I reviewed my thoughts on this and I suspect it  is very few "base block glyphs" I'd like to be able to set. 

They are ALL "block" elements. "Inline" I can foresee about a dozen ;-). But they can be handled well IF in inline we can do ELEMENTS as we do for blocks already.

Best wishes

TT

[@TiddlyTweeter]

TonyM

Minor footnote clarifying an issue that comes up often in understanding Unicode font implementations.

There is masses to understand about Unicode!

My post mentioned that ...

None of the usual fonts European Language speakers would explicitly set in TW settings have any of them (the doubled brackets) except Cambria Maths.

Why?

Because Asian languages use the same style of brackets NOT for Maths in normal writing. SO the WELL DESIGNED MATHS FONT includes, helpfully, duplicate signs that are for direct non-math use by Asian writers.

Best wishes

TT

[@TiddlyTweeter]

TonyM wrote:

¶

I would not bother with the use of pilcrow unless it was part of an end of line form of glyph only. 

Pilcrow has a complex history before printing, in printing & on the net. They all diverge & overlap.

Essentially the paragraph "mark" is a signal for a "longer pause" in thought in all incarnations.

I mention a bit of its history in some comments to PMario above.

Best wishes

TT

  

[TonyM]

TT,

I did read your history, it's Quite interesting. And to some extent I defer to you, but in my return quote I pointed out the "modern" use of Pilcrow.

It is interesting to know where the indented 1st line of a paragraph comes from, something I have never liked the aesthetics of, to be honest. You may be interested in this https://unicode.org/L2/L2016/16235-two-medieval-chars.pdf

What I do hope is in the end we can accommodate different mark-up needs, and in fact that is the value of this project. That is one reason I speculated if it were possible to have an end of line only mark-up symbol, not only because that is the way I would be inclined to use pilcrows, but to support other end of line annotations. I believe this may already be achieved with inline mark-up placed at the end of line. One persons end of line is another's beginning of line anyway, for example I can imagine ﹙¶﹚.

I could see someone with the interest providing both the plugin and custom for anyone of these different systems. Not unlike they way a mathematician may extend tiddlywiki to their own mark-up language to represent complex maths, perhaps people may do this for old English, newspapers, PageMaker (One of the first professional printing applications and the use of postscript). The key being people can make tiddlywiki their own, in new ways, through the value of mark-up. Or as an example people preparing medieval style texts or writing about them.

One example I am aware of is using custom mark-up to write HTML via shortcuts. Combined with tiddlywiki's automation I have always seen the potential for tiddlywiki to be configured to be a site designer and generator as well, this is where using html elements are helpful. One thing that excites me a lot is using an "arbitrary html tag" inside a custom mark-up. Basically it allows the writer to contain custom css and other "semantically appropriate" sections in the document. Add to this transclusion and macros an one could potentially generate a website by filling in some content settings and export (via zip) a whole multi-page site. Could this be a SquareSpace Wix killer? I have experimented with connecting to html and external javascript and there is a lot of potential there for more host interaction, I just do not have the skills yet.

Yet another thought of late, is in response to filters, logical operators and the fact that filters handle sets. It seems to me the introduction of annotation for basic set manipulations would also be helpful. See in the pre-release https://tiddlywiki.com/prerelease/#Filter%20Expression Equivalent named prefix

Regards

Tony

[TonyM]

Idea,

It would be quite simple to find all uses of glyphname=symbolname throughout a wiki to provide a Editor toolbar drop down list of existing glyph/symbol definitions and on click insert them at the current location <glyph><symbol><space> so the custom definitions are easier to lookup and select. Self documenting if the symbols are chosen well.

Tony

[@TiddlyTweeter]

Ciao PMario

Looking at the SYNTAX for your Table Markup looks good!

I'd need to actually be able to use it to say more than that.

For instance, does it preserve the ALIGNMENT and CELL-MERGING tricks that current Wiki-Text has?

I personally think that Jeremy's WikiText for Tables is pretty amazing :-) 

So if you can go better--well--so much the better! :-)

Best wishes

TT

[@TiddlyTweeter]

Ciao TonyM

At some point I think we should go through the whole of Unicode Basic Plane and give a chart of USEFUL GLYPHS FOR MARKUP.

There are a lot of them, but they aren't infinite.

IMO understanding what is in Unicode AND supported in fonts on users machines by default is a primary issue.

Thoughts

TT

[@TiddlyTweeter]

Ciao PMario & TonyM

I'm pretty sure that when Unicode started in 1991 there was no idea that the characters would often get later "hi-jacked" for purposes never intended!

What we have in Unicode is a very vigorous standard that is then partially trashed FROM LACK OF ATTENTION TO THE NET AS AN EMERGENT SYMBOLIC LANGUAGE. Meaning, the origin of Unicode completely neglected that the Web was itself a language, deserving a dedicated plane. 

Its still like that.

IMO "we" basically, I mean ALL of us, are using it in a "bent" way a lot of the time.

Its got quite like the "Net" before the content/structure ideas emerged into "Web Standards" that cleaned things up.

Side thoughts

TT

[TonyM]

Gentlemen,

I just discovered on Windows 10, Win+; opens a character dialogue in which I can find »° and others.

This means there is a simple though not too quick way to access many of the glyphs we use.

However I have being building tools in tiddlywiki for access to other Unicode character sets. 

Regards

Tony

[TonyM]

Replacing the old nested sliders plugin from TWC

In this Discussion a request mat be satisfied with custom wikitext.

Remember
+++
content
+++
content2
===

===

Tony

[PMario]

Hi,

I did a bit more docs for table formatting. So there are the same formatting options as available with standard wikitext.

The only problem is, to find good "start" and "end" symbols, to make the wikitext readable.

-m

[TonyM]

Mario,

That's why I favour customised 'tr and /tr  but then you have to be familiar with html tables. 

Regards

Tony

[@TiddlyTweeter]

Ciao PMario

Sorry. I am getting lost in the wiki!

What Tiddlers do I need to look at to understand the additions/docs?

I'll comment then.

Best wishes

TT

[TonyM]

Mario,

I think I raised this previously, that perhaps one glyph should resort to the element being equal to the symbol.

Why?

Because a large set of possibilities are opened up even without using the customise pragma just some defaults.

Eg;

'tr 

would expect /tr and wrap the content in 

<tr></tr>

Without any further customisation.

ie; the symbol is automatically adopted as the _element 

Sure this can be customised however there are many cases where this, and perhaps a .classname is more than enough

Of course another glyph that does the same automatically terminates on /n would also help eg;

'tr
°td contents of table detail
/tr

°li contents of list item
°li.bold bold contents of list item

This is another way to help html/css savy users to make use of this solution right out of the box with no customising.

I could look from some appropriate glyphs rather than the above ' and °

Regards

Tones

[TonyM]

Further to this generic element solution;

Eg;

⮰td terminates end of line

⭭tr terminates with /tr

Only valid at the beginning of line it should be rare that a clash would occur.

Tony

[@TiddlyTweeter]

Tony & PMario

This illustrates issues in Font Support I mentoned earlier & in the main group.

In choosing Unicode solutions we do need to ensure they have font support across OS.

On Windows 10 I see (correct) ...

... On my Android 8 the lead Unicode characters don't have font support  ...

This is why I refer to the "black art of Unicode". For reliable working there needs to be quite a lot of checking.

Best wishes

TT

[TonyM]

TT,

I do understand your warnings on this, but I also know with the selection of an appropriate font, even pointing to one in a raw tiddler this should not be an issue, it is determining one freely available that can ensure the lions share of Unicode is available, this is what we must do. Ideally we find a font available and eventually ensure the empty version has it named.

I had not tested Android, although a big user.  Thanks for the feedback, not lets find the solution? I read how Microsoft has a few Unicode aware "default fonts".

Tony

[@TiddlyTweeter]

TonyM wrote:

determining one freely available that can ensure the lions share of Unicode is available, this is what we must do.

Right!

I been looking at various methods for doing that.

I use BabelMap Portable, which is pretty good, to examine the font substitution process.

It is highly UNLIKELY with more esoteric glyphs that common fonts will hold them. 

Though many ARE available on local machines through substitution.

What we really need, IMO, is a TW that can be designed so that it itself presents selected Glyphs in various fonts (and ONLY those fonts).

The online tools I looked at for this (i.e. seeing precisely which Unicode characters render in which font) are not really adequate to our needs.

I'm trying to find a consistent & quick way to answer the issues of font support for TW in TW. 

Best wishes

TT

[@TiddlyTweeter]

Ciao Tony & PMario

TonyM wrote:

I had not tested Android, although a big user. 

I think Android matters. Though personally I never use it for heavy edit, its clear that lots of people do.

It DOES raise an interesting issue of relevance to PMario too.

I think it got clear through the 4 threads in this discussion that UNIVERSAL support for ...

-- Default Keyboards is likely IMPOSSIBLE

-- Direct insertion via Keyboard ShortsCuts, and The Stamp Tool, is NOT TOO DIFFICULT

-- Unicode FONT SUPPORT requires research into CROSS-PLATFORM conditions.

For the DEFAULT plugin markup IDs it is BEST to have UNIVERSAL FONT SUPPORT.  

Otherwise we will create a huge "support problem".

Therefore: in examining Candidate Glyphs the single most important issue is good FONT support.

I'm stating the obvious. But answering it is not trivial.

Best wishes

TT 

[TonyM]

TT,

I was thinking on this matter of unicode support, which could have consequences both for and in the use of custom wikitext. In many ways tiddlywiki "supports" Unicode, however for example no Unicode is usable in fieldnames, yet it is in titles, text and field values etc... However there is no reason we should not have a plugin and or a configuration option that supports Unicode. Not withstanding the need for local fonts, for example, windows covers most Unicode. 

Now Unicode is a broad set and the large range of languages supported do not necessarily need to be part of a standard distribution, somehow we need to be both selective and try to be exhaustive or at least provide guidance. If I were a speaker of another language I may already be using fonts in my language and keyboards that support it. 

To Support Unicode it would be good if we had the tools to;

• Detect if extended Unicode is in use in content during import
• Determine if Unicode is present in a given wiki (higher Unicode character search?)
• Provide information on what people will see when there is a missing font and how to remedy it
• Perhaps a plugin that once active provides a subset of Unicode support, and if not so does not. basically designers or users will need to opt in to the more extensive Unicode, and on visiting a tiddlywiki we can see if the author has chosen to support extended Unicode.

In may ways these activities are future issues being given strategic consideration today, along with the conscious decision to use "special characters" in the customise text solution.

Why do I care?

• As a designer or author access to extended character sets offers substantial potential.
• TiddlyWiki is a master in knowledge and information storage and will benefit from robust support.
• As Unicode use grows TiddlyWiki can be a leader in its use.
• There are some nice innovations and self documentation features that can come from extended characters, in effect namespaces and more.

So perhaps we now need to ask

• How do we go about a degree of rationalisation
• code pages English + Extended Symbols and utilities eg mathematical alphanumeric's
  
• font recommendations
  
• Multi-Platform support
  

TT What do you perceive should be included?. 

Regards

TonyM

[@TiddlyTweeter]

Ciao TonyM

• Determine if Unicode is present in a given wiki (higher Unicode character search?)

Tech point.

To use regular expressions for higher Unicode (it would go through JS) in TW is simplest if one uses single Unicode code points in RANGES.

JS regex ranges for Unicode are recognised easily BUT there are TWO different methods which makes it confusing at first.

As far as I am aware only Tiddler Commander directly currently supports the consistently effective method (every character point is represented by only ONE hex number). This behavior is initiated via a regex flag (/u). 

Best wishes

TT

[PMario]

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

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

...

So perhaps we now need to ask

• How do we go about a degree of rationalisation
• code pages English + Extended Symbols and utilities eg mathematical alphanumeric's
  
• font recommendations
  
• Multi-Platform support
  

TT What do you perceive should be included?. 

Hi folks,

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

At the moment we have:

• There are 4 "inline" elements
  • __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
• There are 6 "block" elements
  • pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›

I did play around with "braille" a little bit and for me it is _not_ visible enough in plain text. ... So I'm inclined to remove it for the initial (beta) release. ...

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

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

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

-----------

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

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

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

just some thoughts.

-mario

[TonyM]

Mario,

I understand your concern in relationship to Unicode. But given TiddlyWiki has the content type;

<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

And most systems have fonts for symbols, beyond the old ASCII sets I am sure we can find safe Unicode characters. TT may be the best to provide guidance here.

• The dream would be keyboard enterable "glyphs" or mark-up. Way back when this started I actually expected custom mark-up to be only triggered by a leading period "." (first non blank character is "."), in effect an escape character approach.
  • Of course now we have gone a long way past that and uncovered many more possibilities.
• A Unicode character is less likely to be found in imported text in the exact way we use it as an "escape" character. 
• As long as we can turn off and alter the escape character used, we can adapt if the text contains our escape character
  • And since we need to rule in customised wiki text we are somewhat safe here.

I am happy with the block approach first, it is already very powerful. Thus you could use the same principal, only if the escape character or glyph is the first non-space character (perhaps permit tabs etc..)

A quick look for "safe Unicode characters" gave me this https://qntm.org/safe 

I don't pretend to understand it fully but perhaps TT does.

Regards

Tony

[@TiddlyTweeter]

PMario wrote:

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

Right. In any case the DEFAULT glyphs in the standard plugin I hope are finite in number and (pretty sure to be) in fonts on ALL machines.

Otherwise, as you say, it could become a support nightmare of missing fonts.

With at least some of them on KEYBOARD, so much the better too.

My interest in exploring Unicode is ...

-- IF you ever allowed a method to allow advanced users to define IDs. :-)

-- I think it could be VERY useful to be able to do so.

But note I also agree with TonyM that there is more font support than we perhaps realise.

The PROBLEM is to have a robust method to precisely determine what Unicode characters are UNIVERSALLY SUPPORTED.

My thoughts

TT

[@TiddlyTweeter]

The Problem With _Underscore_

PMario...

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

Hi Mario. In previous posts I have tried to show, with examples, why I think underscore is NOT a good idea.

Basically, IF it were not already used in TW for markup, I'd say it was brilliant. But is IS used already.

I think using it in Custom Markup will be confusing.

My two cents

TT

 

[@TiddlyTweeter]

TonyM wrote:

A quick look for "safe Unicode characters" gave me this https://qntm.org/safe 

I don't pretend to understand it fully but perhaps TT does.

Ciao TonyM. It is interesting and matches my understanding. Its actually reads more "scary" that we need. Most of the mentioned caveats would not arise in TW usage,

The reason it sounds somewhat complex is it is about Unicode in general (in any app). But WE only need be concerned with how it works in HTML & JS.

One big point he makes is about "Diacritical Marks" ("Combining Characters"). Actually the way they are used in HTML means you can use them NON-combining in a way you can't in most word processors. So that part of it take with a pinch of salt. Especially as those glyphs are common in European language fonts and could be useful.

Best wishes

TT

 

[@TiddlyTweeter]

PMario wrote

The advanced usecase of the plugin is difficult enough to explain.

Right. And the ordinary usecase needs time too.

FWIW, after a week away from Custom Markup I had to relearn it.

We really need a "crib sheet"--a one tiddler complete overview--I think, eventually.

I would be very happy to help on that if you agree on the need for it.

Best wishes

TT

[@TiddlyTweeter]

Goodbye ﹙ little﹚, Hello Font Supported Unicode

PMario ...

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

I agree. (1) because of Unicode support; (2) because it is visually ambiguous.

However , worth noting,Tony's push for it can be addressed by other types of bracket IF the end user could define ID glyphs.

But for base release I think it is both not determined to be fully font supported and potentially confusing visually.

Best wishes

TT

[@TiddlyTweeter]

"Braille" Has Advantage It is SINGLE Characters With Wide Font Support 

PMario

⠒ braille⠶ ... 

I did play around with "braille" a little bit and for me it is _not_ visible enough in plain text. ... So I'm inclined to remove it for the initial (beta) release. ...

The INLINE "⠒ braille⠶ " pair retains merit (let us find a similar alternative that is more "visible").

WHY?

Because for inline it is far better to have single characters than doubled. "X text Y" is much better than "XY text YX" for readability and typing.

For these reasons I hope you will keep it for now!

Best wishes

TT

[TonyM]

Gentlemen,

Sometimes one can fall into a Unicode rabbit hole.

Here however I present a few desirable forms, for which we should consider if their font support is robust.

Using this link one can see a set of brackets. https://keyboard.cool/db/search?q=bracket

To me some share a likeness to existing markup symbols such as 

• ⦃ tiddler title and transclusion ⦄
• Space〖tiddler title and parenthesis〗with space
  
• Perhaps even a block form 
  ︗
  Inside block
  ︘

What I did discover is the following includes the letter symbols 🄐 - 🄩 and other sets. Some of which will show a color icon with the right fonts

My thought is what if the glyphs available are from a set that an (optional) web font presents in an enhanced color form. Something one could toggle on/off? between plain and coloured.

In edit these would be bright and easy to see, but after wikification and when acting as customise symbols they are invisible. Of course unless you have misused them, like not used inline and not as the first non blank character, then they will be displayed and clear in the output. Thewy will also be visible as clear mark-up in the editor, again with the use of correct fonts.

Perhaps using such a range the customise feature can detect the range of characters, rather than only specified ones, at least for the leading line base glyphs. Ie a programmatic way for a larger number of glyphs to be made available.

Regards

Tones

[@TiddlyTweeter]

Font-ish Thoughts ... 

Ciao TonyM & PMario

TonyM wrote:

What I did discover is the following includes the letter symbols 🄐 - 🄩 and other sets. Some of which will show a color icon with the right fonts

My thought is what if the glyphs available are from a set that an (optional) web font presents in an enhanced color form. Something one could toggle on/off? between plain and coloured.

In edit these would be bright and easy to see, but after wikification and when acting as customise symbols they are invisible. 

Right. Interesting ideas. If you look back you will see brief discussion between me and PMario concerning ways round the 'local machine' font problem.

I think its worth commenting on some of the options ---

1 - Use Web Fonts From Web. I think PMario would not be too keen on this as you'd need to online connect your wiki to a distant server and all that involves. 

2 - Use Web Fonts Once Downloaded. Many free web fonts can be downloaded. DOWNSIDE: adds a lot of complexity to set-up.

3 - Embed Glyphs in a Custom Font that comes with the plugin. This might be good. ISSUES: What size would it be? Who would have knowledge how to make it? And have the time? 

Best wishes

TT

[TonyM]

TT,

It would be interesting to look at a selective font, as a last resort, that we could embed in tiddlywiki with only the symbols we need. I have seen font builders around but it remains a bit of a dark art to me. Most users such as myself have most of the Unicode covered (as I use Windows 10) so a local font is likely to satisfy the requirements. I would be surprised if any would have to revert to the last resort font if we choose the fonts correctly (or check the existing ones)

However I am not sure this is needed.

Font Family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"
Code Font Family: "SFMono-Regular",Consolas,"Liberation Mono",Menlo,Courier,monospace

• Then inside $:/themes/tiddlywiki/vanilla/base we see different font family provided to different html elements. So in the development process some recommendations have being followed or some serious analysis of fonts generally available have being selected.
  • Perhaps we can find some updated recommendations that include the additional character sets we need for all platforms.
  • In the above we may need to extend the Code Font Family.
• If necessary we can just add via an additional stylesheet.
• As I understand this we are listing fonts to use "if they exist locally" and if they do not it reverts to the next best (using some details of the fonts available)
• When using customise we need to see our glyphs, and they do not appear in the output, So a Tiddlywiki delivered to an audience that is not reading the code it would not matter if no font exists for those Unicodes, the customise should still work even without font glyphs available.

The thing I find frustrating is fonts seem not to document the "code pages" they include.  There must be Unicode rich ones available for linux and apple and other devices as there is for Windows. 

Tones

[@TiddlyTweeter]

TonyM wrote:

It would be interesting to look at a selective font, as a last resort, that we could embed in tiddlywiki with only the symbols we need. I have seen font builders around but it remains a bit of a dark art to me. Most users such as myself have most of the Unicode covered (as I use Windows 10) so a local font is likely to satisfy the requirements. I would be surprised if any would have to revert to the last resort font if we choose the fonts correctly (or check the existing ones)

Right. Last resort in an internal TW cascade. Lot of work BUT would be a reliable way round Cross-Platform UN-certainty.

Whilst I agree that Windows 10 "font stack" (i.e. substitution order by OS for fonts lacking in a TW defined CSS cascade) is very rich, it is still needing clarity on what is going on.

Why? Because different regional installs can make available different fonts in different W10 regions (Asian v. European probably being the largest mass issue). Frankly, I do NOT know, with certainty, how much of an issue this is in practice. The MS documentation is not that easy to understand. And the font substitution process is sophisticated.

Best wishes

TT

[@TiddlyTweeter]

Ciao TonyM

TonyM wrote:

The thing I find frustrating is fonts seem not to document the "code pages" they include.  There must be Unicode rich ones available for linux and apple and other devices as there is for Windows. 

I agree. Frustrating is the word. It is one of those areas of OS process that is simultaneously BRILLIANT and CONFUSING.

It is brilliant in that modern glyph end-usage got so much easier. Thanks to Unicode + improved Font File Architecture + Substitution metadata. 

It is confusing in that the OS+software mediated process of substitution actually now makes it difficult to answer simple questions about which fonts to use where---because the substitution process transparently does it automatically. Unraveling that is really for an expert in that specific field now.

I did some tests in TW to see if I could get it to use a special Test Font that Adobe provide which indexes ALL Unicode code points to a "blank." Doing that you can, in theory, set a CSS cascade such that you effectively switch-off substitution (i.e. cascade: Font, BlankFont). that make it quick and easy to know which fonts truly hold a glyph.

Unfortunately Windows 10 doesn't directly support the indexing method the AdobeBlankVF font file uses. 

I'm still playing around with the idea though.

Best wishes

TT

[TonyM]

TT,

This article lists glyphs supported by an intersection of a set of fonts. Perhaps we could take this list and present it in a tiddler, in a large font size and put it out to the user forum for people to test and report if all the glyphs are visible. Perhaps also in an empty.html at a URL people can just open an review on their various devices?

Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 

 

So far up looking at  to 65000 on Windows 10 (Chrome, FireFox and Edge) most are honoured however I have various local fonts that may be doing this.

Android also works mostly.

Regards

Tony

[@TiddlyTweeter]

TonyM wrote:

This article lists glyphs supported by an intersection of a set of fonts. Perhaps we could take this list and present it in a tiddler, in a large font size and put it out to the user forum for people to test and report if all the glyphs are visible. Perhaps also in an empty.html at a URL people can just open an review on their various devices?

 The problem with that "intersection" (nice idea) is it does NOT really work to illuminate what is going on.

All that entering those glyphs would show is that somewhere in the "global font hierarchy" a character in a font (a character in some registered font somewhere) those glyphs exist.

It is unfortunate that there is little explicitness in most documentation that CHARACTER substitution is ADDITIVE to FONT CASCADE.

In CSS cascade you can MATCH on font but FAIL on CHARACTER. At that point another method of substitution arises that, as far as I can see, CSS doesn't fully control. The substitution "pretends" that the glyph exists in a font when actually it doesn't. It is an invisible process.

In reality, the "full substitution-stack", roughly speaking is: (1) CSS Font Cascade  > (2) Browser Cascade/Stack > (3) OS Font Stack. Not all OS, or browsers, handle this substitution logic the same way.

FYI (OS) Substitution rules read header data in Fonts to determine match to the nearest consanguineous font character in another similar looking font first. Etc. etc

This is a short way of saying: What that would show is Machine Support, Not Specific CSS font support. 

That is good! But it isn't really providing the full clarity needed to pin down UNambigous reliability for markup glyphs.

Best wishes

TT

[@TiddlyTweeter]

Ciao TonyM

TonyM wrote ...

Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 

 Very good! Hots off. Definite step in the right direction.

Comments: Load time is slow. Is it GZipped? On Desktop its fine. On Android smartphone is just never finished loading for me.

For MARKUP glyph purposes it might be interesting to do a version more delimited to "Text Markup Friendly" Unicode blocks?? A thought.

Best wishes

TT

[coda coder]

  Wow - I mean just WOW! I just spent I-don't-know-how-long reading all this stuff - yes, ALL four threads (I managed to resist hunting down any off shoots to the main forum but if there's anything over there I SHOULD read, please let me know!)

Joshua - your guidance and background on unicode codepoints and the potential disconnect with font support is second to none. Excellent diligence!

Tony - your meticulous testing and support of Mario is outstanding!

Mario. What can I say? Your parser knowledge and practical application is clearly well-grounded in TW code culture (a programming genre in its own right). HUGE congratulations for getting even this far.

Okay, praises over, now some questions - apologies in advance if I ask something you think clearly explained somewhere in the tome ("threads" seems like an understatement, so "tome" it is)...

Scoping rules

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

Pragma definitions

(@PMario) Like me, you were probably thankful when JavaScript started to support arrow functions - the brevity alone lent itself to a boost in productivity. Therefore I'm wondering why \customize can't be reduced:

Here is the code for your table example above:

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

Would/could something like this work?

\->table _mode=block

\->caption 

´table ´caption Some caption text

 ... stuff ...

´/table

I'm inferring that tick=table can be treated as redundant.

And, depending on your answer to my question about scope, use this for "local tiddler only" scope:

\->*table _mode=block

Thanks again for a fabulous read guys!

[coda coder]

On Saturday, November 28, 2020 at 11:44:01 AM UTC-6 coda coder wrote:

Joshua - your guidance and background on unicode codepoints and the potential disconnect with font support is second to none. Excellent diligence!

Face-palm - JOSIAH. Blame post-thanksgiving brainfog and a new son-in-law called Joshua. :/

[TonyM]

CodaCode

Nice to see someone else buying into the vision.

Scoping rules

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

Both local and global definition now exists, with local via either in wikitext or by import pragma

Pragma definitions

(@PMario) Like me, you were probably thankful when JavaScript started to support arrow functions - the brevity alone lent itself to a boost in productivity. Therefore I'm wondering why \customize can't be reduced:

It could be perhaps, Mario will consider your suggestions; however the definitions or customise pragma support such a broad and powerful range of uses that brevity in the definition may be unwise. The whole function of the new glyps and symbols it to create brevity by definitions. So perhaps brevity in the definition, is a abstraction too far. 

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

You have swallowed the "red pill". More the discovery of infinite scope than unpleasant truths.

TonyM

[@TiddlyTweeter]

Ciao. Nice to read you!

The "Joshua" v. "Josiah" conflate is an easy one to make since the "shortform" for both is "Jos."

Best wishes

Josiah

[@TiddlyTweeter]

codacoder...@outlook.com wrote:

  Wow - I mean just WOW! I just spent I-don't-know-how-long reading all this stuff - yes, ALL four threads 

My own sense is that what PMario initiated is very significant in potentiating/expanding WikiText to become a proper full-html/css methodology that is lightweight and powerful. By loosing the (often largely self-imposed) limits of Gruber (MarkDown inspired) styling we open up to actually using the power of CSS/HTML to make end-user writing much, much easier.

In particular, it will become much, much easier to quickly design efficient markup systemS without needing to hack Javascript parsers. Ones which just up-and-work. 

That is why I'm keen on doing what I can.

My 2 cents

TT 

[@TiddlyTweeter]

TonyM

I looked more closely at the macro that constructs the Unicode charts you made from: https://anthonymuscio.github.io/PreReleaseGlyphs.html#New%20Tiddler

Man, that is brilliant!

Beyond its immediate use for our explore, it could be used well to illustrate in some docs how to solve a problem in TW elegantly for Intermediate level users. 

TT

[PMario]

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

BUG? v.0.8.1 -- Block Nesting Broken?

Try:

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


»POEM

  ›P-H JABBERWOCKY

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

/POEM

See _mode=block !!

[PMario]

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

CodaCode

Nice to see someone else buying into the vision.

 

+1

 

Scoping rules

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

Both local and global definition now exists, with local via either in wikitext or by import pragma

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

Pragma definitions

(@PMario) Like me, you were probably thankful when JavaScript started to support arrow functions - the brevity alone lent itself to a boost in productivity. Therefore I'm wondering why \customize can't be reduced:

It could be perhaps, Mario will consider your suggestions; however the definitions or customise pragma support such a broad and powerful range of uses that brevity in the definition may be unwise. The whole function of the new glyps and symbols it to create brevity by definitions. So perhaps brevity in the definition, is a abstraction too far. 

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

 

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

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

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

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

-mario

[PMario]

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

Scoping rules

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

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

AND

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

-m

[coda coder]

https://wikilabs.github.io/editions/custom-markup/#Global%20Pragma%20Definitions

Perfect. Thanks, Mario.