# Custom markup (continued 3)

344 views

### PMario

Sep 25, 2020, 7:46:32 AM9/25/20
to TiddlyWikiDev
Hi folks,

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

Let's start a new one before [2] starts to use pagination.
Have a closer look at link [1] it's possible to show all the topics in 1 page

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

### @TiddlyTweeter

Sep 25, 2020, 9:15:03 AM9/25/20
to TiddlyWikiDev
@TiddlyTweeter wrote:
1 - does the end user need to see what the author used? My guess is that they don't.
I mean we are doing this to make WRITING easier. But most READERS won't be writers so will never need to see the markup glyphs.

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

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

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

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

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

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

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

The POINT? "Readability" is actually CONTEXT dependent.

I'll give a bigger example later.

Your tool actually allows shorthand easily.

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

Best wishes
TT

### TonyM

Sep 25, 2020, 11:28:47 AM9/25/20
TT, [Minor edits online]

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

• For example your own shortcuts where at most others view the results can be as brief as you want.
• If however you construct something for people to learn from or customise, its a whole new game.
• And when you do, you will need to document and teach so you are driven to be as meaningful as possible
• If you in fact build a library of mark-up and shortcuts for people to also use then much more time is needed in the development
• This is why at the end of the last topic my brainstorm for the use of different symbols was around the major areas a TiddlyWiki User/Designer becomes familiar with.
• We already have a language of concepts and terms we share, so this is as good a place to start from.
More ideas
• Thinking about these custom pragmas and "languages" I think many of the graphical, and chart solutions in tiddlywiki may benefit greatly from this customisation. a set of symbols and words can be used to capture appropriate primitives for writing, perhaps even the humble Railroad Diagrams and flowcharting graphics.
• I look forward to trying this for recursive and nested solutions, because this is where you can codify a concept in a word, then build the response to that word. eg walk a tree, scan a list...
Regards
Tony who is well past his bedtime.

### TonyM

Sep 25, 2020, 9:28:40 PM9/25/20
to TiddlyWikiDev
Folks,

I continue researching the possibilities for these reasons
• It is seriously exciting
• To work with Mario and others (What a pleasure)
• To discover the possibilities
• To test the limits, and perhaps uncover minor tweaks that add great value
• Lastly to solve long held problems I experience with tiddlywiki
Some notes; See matching code samples
1. customise definitions as a rule need to be at the top of the tiddler
1. However they can also be at the top of a tiddler you transclude
2. This effectively is a way of applying a pragma anywhere within your tiddler without defining it at the top
3. Scope is with in that only?
2. Using set and its filter parameter and an end string, can be used to gain access to an evaluated variable anywhere in the tiddler.
1. But how would one do this for other customised items?
Questions

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

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

Code samples

1. Transclude this tiddlername in a tiddler {{||tiddlername}}
\customize tick=wikify _element="$wikify" _srcName=text name=result\customize tick=text _element="$text" _srcName=text´text {{{ [all[current]] }}}<br>´wikify {{{ [all[current]] }}}´wikify {{{ [all[current]] }}}

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

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

Tony

### @TiddlyTweeter

Sep 26, 2020, 7:33:40 AM9/26/20
TonyM (& PMario)

TonyM wrote:
Readability in programming languages has often simply come from a body of work. You can write code in short or long ways. I imagin you choose depending on the audience. For example your own shortcuts where at most others view the results can be as brief as you want.
• If however you construct something for people to learn from or customise, its a whole new game.
• And when you do, you will need to document and teach so you are driven to be as meaningful as possible
• If you in fact build a library of mark-up and shortcuts for people to also use then much more time is needed in the development
• This is why at the end of the last topic my brainstorm for the use of different symbols was around the major areas a TiddlyWiki User/Designer becomes familiar with.
• We already have a language of concepts and terms we share, so this is as good a place to start from.
Quick point. In my USE CASE I'm interested in using CSS classes AS the "code" / shorthand (actual end-user text is inserted via CSS ::before ) . The user would see NO comprehensible text at all if they opened a Tiddler in edit mode ... They would see stuff like this ...

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

etc ...

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

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

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

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

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

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

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

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

Best wishes
TT

### @TiddlyTweeter

Sep 26, 2020, 7:47:10 AM9/26/20
to TiddlyWikiDev
PMario & Friends

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

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

In my own case I recognize the need for a decent way of thinking CSS class naming through (there will be about 300 classes for my use case I think).
I will likely implement a crude framework using Telmiger's Bricks tool to do so.

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

Best wishes
TT

### PMario

Sep 26, 2020, 7:47:41 AM9/26/20
to TiddlyWikiDev
On Saturday, September 26, 2020 at 3:28:40 AM UTC+2, TonyM wrote:

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

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

Are they "self closing"?

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

.... shortened above

/ghost

<<new-var>>

<<ghost>>

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

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

-mario

mario

### PMario

Sep 26, 2020, 7:57:05 AM9/26/20
to TiddlyWikiDev
On Saturday, September 26, 2020 at 1:33:40 PM UTC+2, @TiddlyTweeter wrote:

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

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

etc ...

OK. ... That's interesting.

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

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

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

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

For me it's important that both variants work.

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

That's right, as written above.

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

Yes. That's the intention.

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

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

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

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

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

-mario

### @TiddlyTweeter

Sep 26, 2020, 12:30:54 PM9/26/20
to TiddlyWikiDev
PMario and all

I been thinking about all this. Especially markup symbols.

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

We are no longer so constrained.

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

A thought
TT

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

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

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

etc ...

### TonyM

Sep 26, 2020, 10:13:53 PM9/26/20
to TiddlyWikiDev
TT et al,

Word of the day? "Nomenclature"

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

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

The tiddlywiki core plugin

## $:/plugins/tiddlywiki/internals lets us preview the output in html and copy and paste it. To me html is the public manifestation. How one generates this content is always up to the author. Tiddlywiki can provision a world of options to assist in generating it, from a database backend to easy to implement semi-automatic outputs. To me this returns us to tiddlywiki as a platform. Rather than messaging, although it is one way to think of it, it is publishing content. It is provision of an efficient method for supporting AUTHOR writing methods. Full stop. An author solution in tiddlywiki has three key audience groups, tiddlywiki enthusiasts/designers, the author and those that read the authors work. All however can have audiences made up of different individuals or groups with different end objectives. As many authors insist, know your audience. 1. If writing something for yourself, the features are all you need and you can build your own Nomenclature 2. if writing for authors, giving them the tools to write, is another audience for which a flexible but structured solution is needed and must be documented. This is where the shortcuts must be curated and a readable Nomenclature is essential to assist in take up or adoption. 3. We may be smart and use 2 to do 1 4. The final readers (on the whole) do not care how we achieved the result, only that it is readable. However readability and quality will be related to the tools the author makes use of. If my audience is ultimately for me 1 or 2 above I plan to analyse the elements of content of published material and provide high quality short cuts / html and wiki elements to generate content the final audience. The way I plan to go about this is to look for formal standards for writing to identify the elements I need to provision. Normal text only such as novels etc... is trivial, as a result I believe if I look at text books, documentation, report writing and instruction manuals I should be able to find an established set of elements for which to build a library of authors shortcuts. We may then alter the defaults to present the result according to different styles but using the same elements. I would appreciate community support to help identify good style and element guides (Especially yourself TT), perhaps even an international standard from which to identify and codify the elements. I hope what we learn may eventually be packaged and one or more options for authors. That is style guides backed up by shortcuts. Another important feature of this current project it the reformatting of material obtained elsewhere, a key example is quoting references and online content. But a key source that will only grow is tiddlywiki content. • Which reminds me some work has being done by academics and scientist previously to build such tools already in tiddlywiki. • Also on books and quote collections including but not limited to our Christian friends and the bible. Let the conversation begin (in another thread?) Regards Tony Other notes: #### Guidelines for writing taxonomy for the web • Mutually exclusive categories can be beneficial. If categories appear several places, it's called cross-listing or polyhierarchical. The hierarchy will lose its value if cross-listing appears too often. Cross-listing often appears when working with ambiguous categories that fits more than one place.[19] • Having a balance between breadth and depth in the taxonomy is beneficial. Too many options (breadth), will overload the users by giving them too many choices. At the same time having a too narrow structure, with more than two or three levels to click-through, will make users frustrated and might give up # Knowledge representation and reasoning # Ontology (information science) # Lexicon ### PMario unread, Sep 29, 2020, 9:48:38 AM9/29/20 to tiddly...@googlegroups.com Hi folks, I did just upload V 0.5.3 that contains 3 more very powerful parameters. It lets us do the following: \customize degree=☐ _element="$macrocall" $name="check" _1=tid \define check(src, tid) <$checkbox tiddler=<<qualify "$:/state/cb/$tid$">> tag=done class="db"> <<__src__>></$checkbox>
\end

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

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

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

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

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

\define check(src, tid, test)
<$checkbox tiddler=<<qualify "$:/state/cb/$tid$">> tag=done class="db"> <<__src__>> - $test$</$checkbox> \end °☐:a:noSpacesAllowed This is a test Since this °☐:a:noSpacesAllowed This is a test may be too much clutter it is possible to define a new _maps parameter eg: \customize degree=☐ _element="$macrocall" $name="check" _1=tid _2=test _maps=":a:noSpacesAllowed" °☐ This is a test More info can be found in the examples. .. The _maps parameter can do some cool stuff. Have fun! mario ### PMario unread, Sep 29, 2020, 9:52:46 AM9/29/20 to TiddlyWikiDev Hi, I'm not 100% sure about the parameter names. So they may change. -m ### PMario unread, Sep 29, 2020, 9:55:39 AM9/29/20 to TiddlyWikiDev I did add a bit more colour to the examples, to visualize the data-flow a bit better. -m ### TonyM unread, Sep 29, 2020, 11:10:49 PM9/29/20 to TiddlyWikiDev Mario, Yes Very interesting. Please keep this possibility alive, I agree the checklist plugin is great, and its very low complexity in wikitext one of its key advantages however I do like the ability to have a minimalist output or read only view of those we can build in custom wiki text • The Checkbox and map solutions are great. Just now, the features of which could be leveraged by custom wiki-text especially when looking for state and unique tiddlers; Eg; Rather than qualify use [<tsn>prefix[$:/checkboxes/]suffix[a]]... perhaps checkboxes against children.
• Which can be renamed and have additional content. ie a checkbox item can become a tiddler.
This will help!
• Especially if I get help building widget(s) that can be used within custom wiki text
• Of course if you can find the time, I would like to collaborate with you (and others) on this as well.
I will continue with the evaluation of your new releases.

Question(s)?
• Given "_params = class definitions" perhaps it could become _classes and _map becomes _params?
• It would be easy/clearer to say the syntax is .class(s):param1:param2
• I have experimented to see If I can introduce custom definitions in the story list or view templates as I am keen to get at least a conditional global customise pragma.
• I am not concerned, too much, how we achieve this, only that we document at least one method to do it, that does not demand \customise or something similar in the text field.
• Transcludeing a tiddler of definitions should work, but if this could relate to a tag not unlike $:/tags/macro • For example if a tiddler has object-type[book-page] bring in a set of custom wiki-text and styles can be handled separately. • One day I hope to toggle custom-wiki text definitions such that one can render for a screen, newsletter or PDF print layouts using the same content and wikitext but alternate customise pragma. Review discovery; • If I clone test-checkbox-widget-maps-transclusion and change the text in one of the checkboxes, I seem to get the same state tiddler as in the original (only on refresh), that state tiddler is listed by not honoured. • I was wondering about checkboxes that are internal vs global, one checklist could prefill another using different text marked elsewhere. FYI • I have discovered a number of powerful techniques on top of custom Wikitext I have not had the time to share yet. Regards Tony ### PMario unread, Sep 30, 2020, 7:01:07 AM9/30/20 to TiddlyWikiDev On Wednesday, September 30, 2020 at 5:10:49 AM UTC+2, TonyM wrote: I have published [RFC] Request for Comment and collaboration - Unique renamable Tiddlers and children with any name, a total Database? Just now, the features of which could be leveraged by custom wiki-text especially when looking for state and unique tiddlers; Eg; Rather than qualify use [<tsn>prefix[$:/checkboxes/]suffix[a]]... perhaps checkboxes against children.

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

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

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

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

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

• I have experimented to see If I can introduce custom definitions in the story list or view templates as I am keen to get at least a conditional global customise pragma.
• I am not concerned, too much, how we achieve this, only that we document at least one method to do it, that does not demand \customise or something similar in the text field.
• Transcludeing a tiddler of definitions should work, but if this could relate to a tag not unlike $:/tags/macro • For example if a tiddler has object-type[book-page] bring in a set of custom wiki-text and styles can be handled separately. • One day I hope to toggle custom-wiki text definitions such that one can render for a screen, newsletter or PDF print layouts using the same content and wikitext but alternate customise pragma. As I wrote earlier. I couldn't find a way to have global parser pragmas. .. The problem is: Internally TW core creates a new Parser() for every tiddler, similar to: tiddler-parser = new Parser(type,text,options), which parses the tiddler text. eg: \define test() test-parser=new Parser(type,text,options) test \end some text As you can see, there will be a new parser for the tiddler and a different completely independent parser for the macro content. ... So as soon as a template uses a macro, the settings from the "outer" parser are invisible to the "inner" parser, because they use completely different memory. The same is true for many widgets, that create several temporary parsers ... That's the reason why the \whitespace pragma has to be used per macro. ... I do have the same problem. I couldn't find a way, to "climb up the memory ladder", to store parser info persistently. Parsers are created and thrown away on demand. I'll have a second look. Review discovery; • If I clone test-checkbox-widget-maps-transclusion and change the text in one of the checkboxes, I seem to get the same state tiddler as in the original (only on refresh), that state tiddler is listed by not honoured. • I was wondering about checkboxes that are internal vs global, one checklist could prefill another using different text marked elsewhere. Yea, the new tiddlers have 2 lists: Global stat tiddlers, which is the default now and "local state" tiddlers, which are responsible for 1 tiddler. FYI • I have discovered a number of powerful techniques on top of custom Wikitext I have not had the time to share yet. I'm looking forward to see the tests. -mario ### @TiddlyTweeter unread, Oct 3, 2020, 4:18:14 AM10/3/20 to TiddlyWikiDev Ciao PMario & all I been doing a lot of testing of using Custom Markup for layouts and precision CSS application. It is VERY good. A number of issues came up. I will post about each separately. First I comment about Editor Look & Keys, then Fonts & Unicode. I did testing on English Win7 (DT), Italian Win10 (tablet) & Android6 (standard phone) computers. 1 - EDITOR LOOK & SETUP Key Availability - It became clear quickly that whilst all three system tested on have Font Support they all differ in native Keyboard Support. None has all 6 IDs available easily on keys. This just confirms what we said before: the tool requires buttons, keyboard shortcuts and likely (for boilerplate WikiText) stamp tool use. The approach PMario took to deal with this via buttons & key shortcuts works well... but ... Too Many Buttons? - I think there may be too many buttons :-). For instance are the buttons that just remove an ID needed at all? What is primary is to be able to insert IDs, which it does. But I don't see added value (myself) to remove them where a single "delete" stroke does it anyway! Button Pictures - This is ONLY an aesthetics comment; but why not just have a picture of the single ID on a button and no more? Visually I think they are over-noisy. 2 - SOME NOTES ON FONT SUPPORT PMario & I already briefly discussed this. Its not an issue on the 6 IDs, at least not for European languages. But it is an issue if you want to use Unicode characters in \customize pragma. I tried to pin down some RELIABLE (typographic) characters available through Unicode (i.e. that have "universal" font support). This is not an easy thing to do. Font substitution behavior of OS' systems (a pretty amazing process BTW) that create "composite" fonts on the fly, using available fonts on the computer can make it near impossible to predict (1) glyphs that will appear in other people's TW; (2) what they will look like (e.g. sometimes coloured, sometimes not, sometimes visually very different). This is obviously NOT directly a TW issue. But it made me wonder whether in fact we (the whole internet) are seriously under-using Unicode that would make life much easier---and not just to better support Custom Markup. My point for TW? I'm wondering IF, we could assemble a custom font of say 100 Unicode typographic signs (e.g. punctuation marks, markup symbols, reference signs etc) and EMBED this in a TW? I don't know how you'd embed it or access the font. But I know how to make such a font set. Q: Is it possible? Your thoughts? Best wishes TT ### @TiddlyTweeter unread, Oct 3, 2020, 4:56:44 AM10/3/20 to TiddlyWikiDev Ciao PMario A CONFESSION - Using Custom Markup at first was very confusing for me! As soon as I started to do anything other than simple the layout would break. This is because of Custom Markup's richness. Because it can do a lot a lot of different ways. There are several dimensions which behave differently according to ID or \customize settings ... In my own way of thinking you have ... Scope Match of three types (expressed in pseudo-regex) ... 1. ^ID ... \n (for 4 IDs) 2. ^ID ... \n\n (for 2 IDs) 3. ^_endString (overrides default scope 1 & 2 in \customize) \customize Flow Setting of two types 1. _mode="inline" (default) 2. _mode="block" These can variously interact under nesting. They can also change existing WikiText behaviors on line-spacing (when its nested inside some custom constructs) in a way that can be confusing at first. Now I understand it much better. When you understand how it works its ROBUST and you can do pretty amazing things very elegantly & efficiently. My point? I think we need to try help PMario document it. In particular we currently lack a brief summary that indicates the "interactivity" that totally confused me at first. Best wishes TT ### @TiddlyTweeter unread, Oct 3, 2020, 5:56:54 AM10/3/20 to TiddlyWikiDev Ciao PMario Is Six ID's Enough? YES. In practical use I think its a good number. - Good balance between strict TECHNICAL NEED to make it work (i.e. 2) and .. - ... VISUAL VARIANCE to make typing variant markup a good experience. In my tests I used all 6. 2 extensively. 2 moderately. 2 for special cases. That number is well supporting of even complex markup. I would cap it at 6. More, I think, would be visually redundant. Best wishes TT ### @TiddlyTweeter unread, Oct 3, 2020, 6:57:31 AM10/3/20 to TiddlyWikiDev Ciao PMario Comments on INLINE markup. At the moment I'm writing markup like this ...  »§ ›¶ ›¶ Example single line for SA phrase groups. Won't fully work till custom-inline is finished. ([[TT Notes]]) »¶ °O »¶ ... ⁋ Example mutli-line block for SA phrase groups. °O Good morning. Welcome to another ›ABsa °O ... So, let's start ... ⁋ »¶ °P.p-b-v °O Observe how your body lays on the ground. What touches clearly. What doesn't. ⁋ »¶ °A.p-b-v °O Observe how your body lays on the ground etc ... °O ⁋ §« each ° inserts a <span> into a paragraph (»¶ ... ). I'm doing it this way because at the moment to do it inline would make it (1) FAR LESS READABLE .... see below ... and I also want to insert (2) NON-SPAN inline elements easily like ›ABsa and (3) sometimes NEST elements.  »¶ °°.p-b-v°° °°.o-ktl°° Now, observe how your body lays on the ground, particularly °°.p-d.g-l°° In this °°AB.sa°° movements are based on "°°REF.r-jen.v°°143-9".  You mentioned before that the current inline parser need uses matched pairs. But the pairs are identical so inline NESTING becomes impossible. I had a thought (horror!) :-) In block parser for Custom Markup you basically leverage off LINE SPACING. I'm wondering IF the use of SPACE INLINE use could work give the leverage needed (regex °\S* ). IF so MY case above would become ...  »¶ °.p-b-v °.o-ktl Now, observe how your body lays on the ground, particularly °.p-d.g-l In this °AB.sa movements are based on "°REF.r-jen.v 143-9".  ... Now you gonna say that would ONLY match words ... so for anything other than a word (string of chars that are not spaces) you use a closure. Let's pretend ... its  »¶ °.p-b-v °.o-ktl Now, observe how your °.o-h body lays on the ground/°, particularly °.p-d.g-l In this °AB.sa movements are based on "°REF.r-jen.v 143-9/°".  Hope this is clear! I'm wondering if this approach is possible?? I have two other simpler suggestions ... 1 - only have ONE character not two ... using @@ or °° is nowhere near as readable as @ ° alone. Markup in-line should be the most readable and the most minimal because that is where reading happens most. 2 - ADD a second ID, maybe aimed at paired use by default? Very best wishes. TT ### PMario unread, Oct 3, 2020, 8:17:56 PM10/3/20 to TiddlyWikiDev On Saturday, October 3, 2020 at 12:57:31 PM UTC+2, @TiddlyTweeter wrote: Comments on INLINE markup. At the moment I'm writing markup like this ...  »§ ›¶ ›¶ Example single line for SA phrase groups. Won't fully work till custom-inline is finished. ([[TT Notes]]) »¶ °O »¶ ... ⁋ Example mutli-line block for SA phrase groups. °O Good morning. Welcome to another ›ABsa °O ... So, let's start ... ⁋ »¶ °P.p-b-v °O Observe how your body lays on the ground. What touches clearly. What doesn't. ⁋ »¶ °A.p-b-v °O Observe how your body lays on the ground etc ... °O ⁋ §« Interesting, but without the actual configuration it's really hard for me to see, what it should do. .. Can you export your setting and attach a tiddlers.json, so I can see it? each ° inserts a <span> into a paragraph (»¶ ... ). I'm doing it this way because at the moment to do it inline would make it (1) FAR LESS READABLE .... see below ... and I also want to insert (2) NON-SPAN inline elements easily like ›ABsa and (3) sometimes NEST elements.  »¶ °°.p-b-v°° °°.o-ktl°° Now, observe how your body lays on the ground, particularly °°.p-d.g-l°° In this °°AB.sa°° movements are based on "°°REF.r-jen.v°°143-9".  You mentioned before that the current inline parser need uses matched pairs. But the pairs are identical so inline NESTING becomes impossible. That's right. I didn't do work on the inline settings yet. ... But it should be possible to define the _endInline string similar to the existing configs. I had a thought (horror!) :-) In block parser for Custom Markup you basically leverage off LINE SPACING I'm wondering IF the use of SPACE INLINE use could work give the leverage needed (regex °\S* ). IF so MY case above would become ...  »¶ °.p-b-v °.o-ktl Now, observe how your body lays on the ground, particularly °.p-d.g-l In this °AB.sa movements are based on "°REF.r-jen.v 143-9".  Interesting idea, but "spaces" are really hard to see ;) .. or to judge, how many of them are actually used. ... It needs some experimenting with the parser and the regexp's. ... ... Now you gonna say that would ONLY match words ... so for anything other than a word (string of chars that are not spaces) you use a closure. Let's pretend ... its  »¶ °.p-b-v °.o-ktl Now, observe how your °.o-h body lays on the ground/°, particularly °.p-d.g-l In this °AB.sa movements are based on "°REF.r-jen.v 143-9/°".  Hope this is clear! I'm wondering if this approach is possible?? Not really sure what you want to get. I'd need the html + the text, that should be produced. So I can see, where your _endInline should be in the text. I have two other simpler suggestions ... 1 - only have ONE character not two ... using @@ or °° is nowhere near as readable as @ ° alone. Markup in-line should be the most readable and the most minimal because that is where reading happens most. That's right. If we find the right "start" and "end" markers we could do 1 character as a marker. ... But 1 ° char seems to be valid plain text for me. eg: 20°C ... should not start something special. ... 20 °C ... the ID would be ° (degree) and the symbol would be "C". .. But that's probably not intended. .. Wher as °°C.class.class:param is a possible marker, that the parser can identify. Especially if the inline mode starts a the beginning of the line. °C will clash with the existing parser 2 - ADD a second ID, maybe aimed at paired use by default? Not sure, what you mean here. -mario PS: I'll publish V0.6.0 with some incompatible changes on Sunday. ... We will get global pragma rules, _parms -> _classes, _maps -> _params ... angel -> angle ;) ### @TiddlyTweeter unread, Oct 4, 2020, 2:42:31 AM10/4/20 to TiddlyWikiDev PMario wrote: Interesting, but without the actual configuration it's really hard for me to see, what it should do. .. Can you export your setting and attach a tiddlers.json, so I can see it? Its actually very complex so I've made a simplified single tiddler example containing the \customize, markup example and style block for you to see. I hope that will help.The example attached is for using the markup in BLOCK mode I already have working well. In a post later today I'll try to make clearer the issues in INLINE mode I was trying to explain. Many thanks for your patience! TT TT-block-version-test.json ### @TiddlyTweeter unread, Oct 4, 2020, 3:20:59 AM10/4/20 to TiddlyWikiDev PMario ... I'll publish V0.6.0 with some incompatible changes on Sunday. ... We will get global pragma rules, _parms -> _classes, _maps -> _params ... angel -> angle ;) Noted! Global pragma rules will be brilliant for my use case. Thanks angel for the angle :-). TT Message has been deleted ### PMario unread, Oct 4, 2020, 7:30:20 AM10/4/20 to TiddlyWikiDev On Sunday, October 4, 2020 at 8:42:31 AM UTC+2, @TiddlyTweeter wrote: Its actually very complex so I've made a simplified single tiddler example containing the \customize, markup example and style block for you to see. I hope that will help.The example attached is for using the markup in BLOCK mode I already have working well. I did fall in my own trap. I had to rename _params to _classes, to see the style definitions :) The point is, I'm completely clueless, why you write "content" with CSS? What is the purpose? Or is it just testing out the possibilities? In a post later today I'll try to make clearer the issues in INLINE mode I was trying to explain. OK -mario ### PMario unread, Oct 4, 2020, 7:34:53 AM10/4/20 to TiddlyWikiDev Yea, .. I do think so too. ... In reality with 1 ID you also have the <symbol> character / name. So the possibilities are almost endless. I also wanted to use IDs, that should be available with different keyboard layouts. So depending on the keyboard layout there should be at least 1 or 2 IDs available, that are easy to type. BUT we will see, once I introduce the plugin in the main group. -m ### PMario unread, Oct 4, 2020, 7:41:00 AM10/4/20 to TiddlyWikiDev On Saturday, October 3, 2020 at 10:56:44 AM UTC+2, @TiddlyTweeter wrote: Ciao PMario A CONFESSION - Using Custom Markup at first was very confusing for me! As soon as I started to do anything other than simple the layout would break. This is because of Custom Markup's richness. Because it can do a lot a lot of different ways. There are several dimensions which behave differently according to ID or \customize settings ... In my own way of thinking you have ... Scope Match of three types (expressed in pseudo-regex) ... 1. ^ID ... \n (for 4 IDs) 2. ^ID ... \n\n (for 2 IDs) 3. ^_endString (overrides default scope 1 & 2 in \customize) Yes. The _endString basically makes them the same! \customize Flow Setting of two types 1. _mode="inline" (default) 2. _mode="block" That's the same behaviour, like the TW core parser. These can variously interact under nesting. They can also change existing WikiText behaviors on line-spacing (when its nested inside some custom constructs) in a way that can be confusing at first. Now I understand it much better. When you understand how it works its ROBUST and you can do pretty amazing things very elegantly & efficiently. Yea, there is still some problems, with the TW core parser, that introduces P tags, where they shouldn't be. .. I think there is no real way to work around this. :/ My point? I think we need to try help PMario document it. That's a good idea. Especially documented examples will be helpful. ... I did improve the _debug and \debugcustomize commands quite a bit. ... The can be also used for documentation now. ... In particular we currently lack a brief summary that indicates the "interactivity" that totally confused me at first. What do you mean by "interactivity" -mario ### PMario unread, Oct 4, 2020, 7:52:11 AM10/4/20 to TiddlyWikiDev On Saturday, October 3, 2020 at 10:18:14 AM UTC+2, @TiddlyTweeter wrote: Ciao PMario & all I been doing a lot of testing of using Custom Markup for layouts and precision CSS application. It is VERY good. A number of issues came up. I will post about each separately. First I comment about Editor Look & Keys, then Fonts & Unicode. I did testing on English Win7 (DT), Italian Win10 (tablet) & Android6 (standard phone) computers. 1 - EDITOR LOOK & SETUP Key Availability - It became clear quickly that whilst all three system tested on have Font Support they all differ in native Keyboard Support. None has all 6 IDs available easily on keys. This just confirms what we said before: the tool requires buttons, keyboard shortcuts and likely (for boilerplate WikiText) stamp tool use. The approach PMario took to deal with this via buttons & key shortcuts works well... but ... OK Too Many Buttons? - I think there may be too many buttons :-). For instance are the buttons that just remove an ID needed at all? What is primary is to be able to insert IDs, which it does. But I don't see added value (myself) to remove them where a single "delete" stroke does it anyway! With the default configuration, there will only be 2 buttons. Remove "angle" and Add "angle" ... To deal with paragraphs. The rest will be activated by the users, if they want them. Button Pictures - This is ONLY an aesthetics comment; but why not just have a picture of the single ID on a button and no more? Visually I think they are over-noisy. right! At the beginning, they where very similar to the "Apply bulleted list" buttons, but the icons where to small, to be seen, so I reduced them to 2 lines instead of 3. .. BUT you are right. Now they are already different, so we can simplify them. I'll have a closer look. 2 - SOME NOTES ON FONT SUPPORT PMario & I already briefly discussed this. Its not an issue on the 6 IDs, at least not for European languages. But it is an issue if you want to use Unicode characters in \customize pragma. I tried to pin down some RELIABLE (typographic) characters available through Unicode (i.e. that have "universal" font support). This is not an easy thing to do. Font substitution behavior of OS' systems (a pretty amazing process BTW) that create "composite" fonts on the fly, using available fonts on the computer can make it near impossible to predict (1) glyphs that will appear in other people's TW; (2) what they will look like (e.g. sometimes coloured, sometimes not, sometimes visually very different). This is obviously NOT directly a TW issue. But it made me wonder whether in fact we (the whole internet) are seriously under-using Unicode that would make life much easier---and not just to better support Custom Markup. My point for TW? I'm wondering IF, we could assemble a custom font of say 100 Unicode typographic signs (e.g. punctuation marks, markup symbols, reference signs etc) and EMBED this in a TW? I'm not the biggest fan of embedded fonts, because of size. ... BUT it will be possible with a second plugin, so users can decide. I don't know how you'd embed it or access the font. But I know how to make such a font set. I personally would install the font. Q: Is it possible? Your thoughts? I would even consider to create a browser AddOn, that will make the font available for TWs, if users don't want to install new system fonts. I'm not sure if this is possible, but it would be worth a test. -mario ### PMario unread, Oct 4, 2020, 8:23:33 AM10/4/20 to TiddlyWikiDev Hi foks, I did just upload V0.6.0 which has some INCOMPATIBLE changes. • New Functionality • Incompatible changes • _params renamed to -> _classes • _maps renamed to -> _params !! • Adjusted the docs accordingly • Improved debug modes • \debugcustomize new parameters: no, list, global, global list, global ID • _debug new parameter: no, • angel renamed to: angle + docs -mario ### TonyM unread, Oct 4, 2020, 8:01:26 PM10/4/20 to TiddlyWikiDev Mario, Thanks for the progress and listening. Today is a public holiday and I am spending time with my partner, so may not feedback today. This project certainly has "energised me" both for its outcomes and what I perceive to be other key improvements we need in TiddlyWiki. It has also led to some new insights. One project is "canned templates", basically a set of templates in tiddlers with practical names. • Helpful with a number of customise shortcuts For example "(new-journal-here)" is a tiddler, {{||(new-journal-here)}} will present a new journal here button for the current Tiddler. Basically a pseudonym for {{||$:/core/ui/Buttons/new-journal-here}}

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

\customise tick=toptoc _element="\$list" filter="[tag[toc]]"´toptoc {{||(link)}} {{||(new-here)}}<br>

Gives

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

Regards
Tony

### @TiddlyTweeter

Oct 5, 2020, 2:50:27 AM10/5/20
to TiddlyWikiDev
PMario wrote:

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

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

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

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

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

Just a comment.

TT

### @TiddlyTweeter

Oct 5, 2020, 3:08:51 AM10/5/20
to TiddlyWikiDev
Regarding fonts ...

@TiddlyTweeter wrote:

2 - SOME NOTES ON FONT SUPPORT PMario & I already briefly discussed this.
Its not an issue on the 6 IDs, at least not for European languages.

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

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

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

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

<snip>

I personally would install the font.

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

Q: Is it possible? Your thoughts?

I would even consider to create a browser AddOn, that will make the font available for TWs, if users don't want to install new system fonts.
I'm not sure if this is possible, but it would be worth a test.

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

Best wishes
TT

### @TiddlyTweeter

Oct 5, 2020, 3:14:03 AM10/5/20
to TiddlyWikiDev
I was about to post a note on in-lining :-)

I'll update first. A dopo.

TT

### @TiddlyTweeter

Oct 5, 2020, 4:03:40 AM10/5/20
Regarding a use case using "shorthand"

PMario wrote:

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

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

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

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

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

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

A whole lesson is written on ONE A6 card.
Transcribed a lesson would be 4-6 pages of A4.

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

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

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

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

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

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

I may actually use it! :-)

Best wishes
TT

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

### @TiddlyTweeter

Oct 5, 2020, 4:24:17 AM10/5/20
to TiddlyWikiDev
Users on email please note that in my last post prefaced Regarding a use case using "shorthand" I added a PS at the end reading ...

### @TiddlyTweeter

Oct 5, 2020, 4:58:26 AM10/5/20
Regarding examples & WikiText "interactivity"

TT wrote:

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

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

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

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

Hopefully I can give you one or two in time.

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

What do you mean by "interactivity"

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

I think the bigger point I was trying to get at is that Custom Markup makes much, much easier vastly more sophisticated use of HTML & CSS using a neat compact method.
Along with that comes, I think, much higher chances users will trigger cases where the layout seems to go all wrong :-).
So greater clarity of how parsing works is likely going to be needed if a user wants to do more advanced work.

TT

### @TiddlyTweeter

Oct 5, 2020, 5:05:20 AM10/5/20
to TiddlyWikiDev
For readers on email in my last post prefaced Regarding examples & WikiText "interactivity" I deleted the last paragraph as it was misleading.
TT

### @TiddlyTweeter

Oct 5, 2020, 5:34:48 AM10/5/20
to TiddlyWikiDev
Discussing putative inline IDs

@TiddlyTweeter wrote:

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

PMario ..
Not sure, what you mean here.

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

degree "°" (entity = &deg;)

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

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

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

Best wishes
TT

### PMario

Oct 5, 2020, 6:40:11 AM10/5/20
to TiddlyWikiDev
On Monday, October 5, 2020 at 11:34:48 AM UTC+2, @TiddlyTweeter wrote:

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

degree "°" (entity = &deg;)

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

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

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

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

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

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

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

Just some thoughts.

mario

### @TiddlyTweeter

Oct 5, 2020, 7:26:39 AM10/5/20
to TiddlyWikiDev
--- Largely OT ----

PMario ...

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

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

TT

### @TiddlyTweeter

Oct 5, 2020, 7:39:51 AM10/5/20
TT ..
I have two other simpler suggestions ...

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

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

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

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

°C will clash with the existing parser

Right. My concern here is a broader issue.

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

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

Thoughts
TT

### @TiddlyTweeter

Oct 5, 2020, 8:27:13 AM10/5/20
PMario
I was thinking about °/ some text and /°  ... Since start and end are different, it should be possible to identify nesting. So
›/ and /› .. may be a second option and ´/ and /´  a 3rd one.

I would like to keep °° some text °°

Well you are the developer :-).

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

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

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

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

renders as ...

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

You add ONE character. Well good.

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

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

renders as ...

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

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

And the second case should permit nesting?

Best wishes
TT

### TonyM

Oct 5, 2020, 8:54:08 AM10/5/20
to TiddlyWikiDev
Mario,

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

As a starter I am reviewing first simple elements only

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

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

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

eg
'aside Content is an aside

• That is nominate one of the special character to just automatically treat what follows as this does \customise tick=aside _element=aside
• So in fact we do not need to define any \customise tick=elementname _element=elementname
• This should be achievable programaticaly so any element name can be used including arbitrary html elements.
So if we did this it would work like below but with no need to use the \customise pragma for a nominated tic.
\customise tick=question _element=question\customise tick=answer _element=answer<style>question { display: initial }answer { display: none }</style>´question What do you think?´answer Really cool eh?

By the way I do nor think we shopuld say
<ID>=<userSymbol>
Since to me the tick degree etc.. is a symbol

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

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

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

Let's start a new one before [2] starts to use pagination.
Have a closer look at link [1] it's possible to show all the topics in 1 page

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

### TonyM

Oct 5, 2020, 8:59:15 AM10/5/20
to TiddlyWikiDev
Sorry, To be a little clearer on my previous question answer

Otherwise
'q1 Question 1

etc...
Tony

### PMario

Oct 5, 2020, 11:49:59 AM10/5/20
to TiddlyWikiDev
On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote:

By the way I do nor think we shopuld say
<ID>=<userSymbol>
Since to me the tick degree etc.. is a symbol

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

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

-m

### PMario

Oct 5, 2020, 11:58:47 AM10/5/20
to TiddlyWikiDev
On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote:

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

eg
'aside Content is an aside

• That is nominate one of the special character to just automatically treat what follows as this does \customise tick=aside _element=aside
This would be possible if we would check against an HTML list of "names". which is already done, eg: _element="article" will have a look at: https://github.com/Jermolene/TiddlyWiki5/blob/9716c326952c16f63345a135e73cf36670dca0d8/core/modules/config.js#L37

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

• So in fact we do not need to define any \customise tick=elementname _element=elementname
We do for "names" that are not html tags.

• This should be achievable programaticaly so any element name can be used including arbitrary html elements.
including "arbitrary" tags is not possible, since this would limit the names to html elements only. .. That's not what we want.

-mario

### PMario

Oct 5, 2020, 12:02:06 PM10/5/20
to TiddlyWikiDev
Hi

´aside test asdf

### PMario

Oct 5, 2020, 12:15:40 PM10/5/20
to TiddlyWikiDev
On Monday, October 5, 2020 at 10:03:40 AM UTC+2, @TiddlyTweeter wrote:
Regarding a use case using "shorthand"

PMario wrote:

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

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

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

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

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

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

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

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

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

-m

### PMario

Oct 5, 2020, 12:48:11 PM10/5/20

On Monday, October 5, 2020 at 11:05:20 AM UTC+2, @TiddlyTweeter wrote:
For readers on email in my last post prefaced Regarding examples & WikiText "interactivity" I deleted the last paragraph as it was misleading.
TT

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

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

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

I was also thinking about a plugin that uses:

- list
- list

to produce this:
• list
• list
I'm not really happy with

* list
** list

Especially if there are 3 of them.

-m

### TonyM

Oct 5, 2020, 6:49:16 PM10/5/20
to TiddlyWikiDev
Mario,

Perhaps there is something I do not understand but I am suggesting a specific symbol lets say ¤ as a working symbol
• Perhaps I can state it in different words?

Consider this
\customise sym=elementname _element=elementname¤elementname that will internally parse this as if there existed a ¤elementname.classname and allowing class names
You can see the customise is repetitive, but currently it must be explicit

What I am suggesting is there is so much value in using customise just to take a named element name and allow a classname(s) to be applied and close it.
<elementname> line or content </elementname>
So I am asking if it would be possible to to convert any line beginning with a fixed special character to result in a open and close element of the immediate text. Arguably auto close on \n\n

Why;
• HTML elements, open and closed arbitrary or not, could be collapsed to ¤elementname.classname
• Arbitrary html sections allow the author to mark-up their content according to logical names
<abstract>This tiddler is about ....</abstract>
• Then with a small set of css or macros and view templates we can alter the display, or search all tiddlers for such content
• This works well already but I was wondering if we can replace this with ¤elementname.classname ?
• Macros can either interrogate the rendered html or between ¤elementname  and \n\n to extract the contents.
For many users this would be a compelling use of the customise pragma but they would not need to define such customise parameters at all.

Regards
Tony

### TonyM

Oct 5, 2020, 9:12:55 PM10/5/20
to TiddlyWikiDev
Folks,

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

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

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

Regards
Tony

### @TiddlyTweeter

Oct 6, 2020, 3:59:13 AM10/6/20
to TiddlyWikiDev
Revision Suggestions For "exports.htmlBlockElements"

Ciao PMario & TonyM

TonyM wrote:

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

eg
'aside Content is an aside

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

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

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

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

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

Yes?

Best wishes
TT

### @TiddlyTweeter

Oct 6, 2020, 4:13:52 AM10/6/20
to TiddlyWikiDev
TonyM wrote:

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

RIGHT! And Right! But with power comes responsibility. That is a cliche.
But documenting the new approach I think we need to help PMario. Especially with examples.

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

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

My tuppence
TT

### @TiddlyTweeter

Oct 6, 2020, 4:27:17 AM10/6/20
Should "Space, Space, Enter = <br>" be in Custom Markup too?

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

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

AH! Got it!

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

Or do you think it would be confusing?

Best wishes
TT
Message has been deleted

### @TiddlyTweeter

Oct 6, 2020, 4:49:59 AM10/6/20
to TiddlyWikiDev
Ciao TonyM

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

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

´aside test

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

and

´aside.my-style test

produces in render

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

Likely I am missing your point!

Best wishes
TT