Custom Markup (continued 5) - SPEC

[pmario]

Hi folks,

This is the continuation of GG discussions at:

• Custom markup
• Custom markup (continued)
• Custom markup (continued 2)
• Custom markup (continued 3)
• Custom markup (continued 4)

Latest Version: https://wikilabs.github.io/editions/custom-markup/ !

have fun!
mario

[pmario]

---- TODO summary

[TiddlyTweeter]

The Ability to insert comments that never render is BRILLIANT!

A lot of issues arose in dev of CM. There are side issues that were dealt with well by @pmario. Amongst them is a way to COMMENT code (or anywhere) using CM. It has utility beyond CM.

The man deserves a high hat.

[TiddlyTweeter]

Ignore my question. I found a solution using CSS regular expressions.

Question: Can we COLOUR Glyphs?

[pmario]

I think it would be better to develop keyboard shortcuts for inserting non typeable glyphs. And using the TW Editor Stamp tool to insert needed glyphs too.

That's right and "on the way" ;)

[TiddlyTweeter]

My Criteria For (initial) Glyph Choice

Looking back over the discussions and thinking these through to a solution .... I have (for a first approximation) the following criteria in mind.

NEGATIVE
- Try to avoid choosing glyphs from Maths (Much used by many TW users) as well as similar use cases.
- Try to avoid glyphs from common languages
- Try to avoid shorthand symbols used in common usage (e.g. degree °). Rather, use similar looking glyphs from
elsewhere in the BMP.

POSITIVE
- Try to use, first, glyphs from Symbol blocks that are language neutral and are not dedicated to specific purposes.
- Prioritise use of glyphs in the Unicode BMP over the other plains.
- Prefer glyphs that can be used in pairs (i.e. implying open/close visually)
- Prefer (specific font) glyphs that are neither very small nor very big.
- Allow selection from "dead" languages.
- Allow selection from true "minority" languages (e.g. Canadian Aboriginal blocks)

@pmario & @AnthonyMuscio Let me know if you have other thoughts on criteria..

TT

[TiddlyTweeter]

The Ability to insert comments that never render is BRILLIANT!

It has utility beyond CM.

@pmario I wonder if it might be worth thinking about providing this function as it's own plugin?

Personally I asked about simple light-weight commenting on GG several times. The solutions proposed then were too complicated & loaded render output too with unneeded HTML.

I'm not sure how big the audience would be. But the current inability to comment code easily makes it hard to fully show how macros work.

TT

[AnthonyMuscio]

Mario,

Would it be possible in future to upgrade the customise plugin rather have to copy the wiki at https://wikilabs.github.io/editions/custom-markup. Even if we have a separate plugin or JSON containing the examples and documentation so far?

I have build examples and resources on different versions of the wiki, and now need to consolidate them.
The pre-release versions increment continuously as well.

Tony

[TiddlyTweeter]

@AnthonyMuscio Personally I'm okay as is. I tend to use only latest. When a new comes I look at differences from previous.

That said if there were a plugin with an address I could auto-download when the plugin changes (I use Powershell scripts to detect change and download files I monitor) I'd use that first.

TT

[pmario]

If you open: https://wikilabs.github.io/editions/custom-markup/#%24%3A%2Fplugins%2Fwikilabs%2Fcustom-markup and drag & drop import it to your TW it should be simple to get the latest plugin version.

There is the "green library-link" button on: https://wikilabs.github.io/ which you can import to your wiki. ... It will allow you to import new WL-plugins with the default plugin UI.

The problem atm is, that the "library creation process" for 3rd party libs, in TW 5.2.22, is broken. It will be fixed with 5.1.23 ...

So atm can't use the automatic "batch processing". I need to create new libs by hand, which is a bit cumbersome.

[pmario]

Just uploaded V0.9.0

Changed all keyboard shortcuts, to avoid overlapping
All toolbar buttons are visible atm. This will change in the future!
Add dynamic button "disabled" state to: $:/core/ui/EditTemplate/body/toolbar/button
    Added button disabled CSS
There are 3 "inline" elements
    ﹙ little﹚, ⠒ braille⠶, /° slash°/
There are 6 "block" elements
    pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›

The block icons are now dynamic and 2 of them are only enabled for "angle" and "about"

[TiddlyTweeter]

Ciao @pmario

Sorry for my quietness but I'm having issues with RSOD's like this (Firefox latest, latest CM version, latest TW release) ...

Internal JavaScript Error
Well, this is embarrassing. It is recommended that you restart TiddlyWiki by refreshing your browser
TypeError: this.parser.wiki.caches['$:/config/custom-markup/pragma/PageTemplate'] is undefined

So far I have NOT been able to pin-down exactly when it occurs or replicate it.
I try today to see if I can replicate it. But do you have any thoughts on why that particular error message happens?

Best wishes
TT

[pmario]

Yea, the "global pragma" code is a little bit hacky. ... But I didn't find a good way to initialize yet. So there may be some edge-cases. ..

It would really be helpful, if you could provide a "workflow" that would allow me to replicate the error.

[TiddlyTweeter]

@pmario > It would really be helpful, if you could provide a "workflow" that would allow me to replicate the error.

I'm trying. Problem is I get the issue in very complex wikis with lots of other plugins and it happens unpredictably. But I don't get any problem on simple wikis that are mostly vanilla empty. So it is hard to be precise in a useful way.

But I try once more tomorrow.

[TiddlyTweeter]

@pmario yesterday I had more crashes. One in particular was interesting: happened immediately after adding the "Internals" plugin via "Get More Plugins". That lock-up was fatal and with the same error message as before.

BUT I can't replicate it on https://wikilabs.github.io/editions/custom-markup/#%24%3A%2Fplugins%2Fwikilabs%2Fcustom-markup which works fine with my markup code.

I'm not really sure HOW to pin the issue down in a way that will help :-(.

[pmario]

• toolbar button for inline mode will be added next.

[TiddlyTweeter]

Is It Possible To Customise Custom Markup :-)

@pmario I'm looking ahead. I pretty much think I can use your Custom Markup plugin to solve several problems. One thing I was wondering about was IF it would be easy to hack your Javascript to change the glyphs IF I needed to have different ones? My thinking is to take your plugin and mod it for a specific app for styling Screenplays. Early thoughts! But I was wondering if the glyph assignments in the JS might be modifiable without too much hassle?

Just a query :-)
TT

[TiddlyTweeter]

I had a closer look at the fountain markup. ... The overall structure is relatively straight forward. BUT the exceptions are the problem. eg: A character name is ALL_UPPERCASE :/ ... TW wiki syntax has no rule to detect the meaning of "all uppercase" should be a character-name ... plus there is an exception "!ALL_UPPERCASE" is no character name .... and so on.

Right. Fountain.io system is very good. I have studied both the documentation and the regex coding used.

What, functionally, is really interesting about it is that it superbly deals with what you might best call "implicit markup". Meaning it absolutely takes Screenplay layout (a very defined rigorous invariant international standard based on typewritten text) and knows how to read it.

I actually created my own proof-of-concept parser using a module of BJ's Content Type parsers that is wholly a sequence of raw regular expressions--about two years ago--and it worked pretty well. And at that time Mark S. also made me a crude plugin from one of the existing fountain parser libraries that works for formatting a screenplay well IF it already exists in the correct plain text layout.

Both these experiments showed me what could be done. BUT issues arose I haven't solved yet. One of them is simply about ensuring PDF or print output remains rigorously controlled. That is essential if you want to submit a screenplay to a producer for consideration.

The other issue, and, I think, the most important one is to better leverage TW to have a parallel structure so you can do things like: "rearrange scene order" or "show only the dialogue of character X", etc.

The challenge is to keep it looking like a typewritten simple plain text-play BUT also have TW working tools to better manage the document in ways you really need for a "Production Script".

custom-markup is intended to "abstract" TW-wikitext-syntax away. ... Creating a new syntax is OK, as long as the new syntax is a "subset" of TW syntax. ... Which isn't the case for fountain.

Right.

fountain parser: https://github.com/mattdaly/Fountain.js/blob/master/fountain.js seems to be a "line based" parser and should be relatively easy to add to TW as a plugin. ... IMO the hard part will be to get a PDF file out of it. This is where I got to but haven't fully solved.

[TiddlyTweeter]

@pmario, regarding the possible role of Custom Markup to help me finally bring this "TW Screenplay Project" to completion ... It will take me more time to think through the different aspects properly but I can already comment ...

• Upside: Using just the existing Custom Markup it is easily possible to derive suitable screenplay layout. There are only a finite number of constructs needed (e.g. Dialogue, Action, Transition, Aside) and some few containing blocks to go a bit further than standard fountain.io (e.g. Act & Scene.) I think it is doable.

• Downside: But one issue with deriving a fountain.io methodology is that most of the time you never enter markup explicitly in fountain because the plain text layout is already its own markup. In other words, the overhead of, via Custom Markup, having to explicitly markup every para/block seems a bit more than I think ideal.

• Potential Solution: Being more positive I was thinking of a "mixed solution" where a "pre-parser" auto injects Custom Markup. Actual direct manual Custom Markup would be for the few cases where you need to explicitly define the layout because it does not follow the "Screenplay Standard".

I hope this is clear! Still early thoughts.

[TiddlyTweeter]

@pmario, finally a note on "Custom" glyphs for a mod of Custom Markup (if it is possible). I'm not sure yet. But what I was thinking for Screenplays was to use a special font that contains special glyphs (maybe dingbats, or newly created glyphs) that have semantic scope. What I mean is that for, say, an "Act Div" one uses a glyph that is a small representation of a stage. Or for "Transitions" a glyph indicating change. You get the idea? It is to provide the user with glyphs that have explicit meaning for their purpose specifically in screenplays.

I'm still thinking about it. But any thoughts you might have I would welcome! Tx, TT

[pmario]

I think, the fountain discussion would be worth a completely new thread

[TiddlyTweeter]

Ciao @pmario. Likely right. I need time to think it through more so I'd post something very clear.

Right now I want to support your Custom Markup tool first as its very good. I been doing a lot of testing and soon I hope to comment in detail. J, x

[AnthonyMuscio]

Just a word here that I am lurking, and testing the latest version when possible, sometimes the rest of life needs more focus that TiddlyWiki :)

[TiddlyTweeter]

@AnthonyMuscio, there is a new discussion at Custom Markup: Usage Notes & Queries of importance.

I don't want it to be just me.

IF you have interest please comment: so we can help @pmario bring to conclusion an amazing plugin.

[TiddlyTweeter]

Ciao @pmario. I have many comments on the Custom Markup plugin. These comments relate to usage much more than development. Would you like me to post the comments in THIS Discussion? Or start a new one?

TT

P.S. I originally posted a message like this to the WRONG (Bundler) discussion :-(.

[pmario]

If it's usage related, you should start a new discussion

[TiddlyTweeter]

Okay. Soon I start a new discussion.

[TiddlyTweeter]

@pmario I had another RSOD crash that was fatal :-(. I am trying to replicate it. This time it is simpler as I was working with a near empty TW. Later.

[pmario]

I did add some code. So it shouldn't happen again, in the next version.

[TiddlyTweeter]

Which browser do you use?

Normally Firefox. But I can replicate the issue exactly the same on Chrome too...

Uncaught TypeError: Cannot read property 'blockParseTree' of undefined And the wiki locks up.

This is bizarre! That I can replicate it and you can't! I must be doing something very weird! :-)

[TiddlyTweeter]

I did add some code. So it shouldn't happen again, in the next version.

Oh. Great! Please let me know when I can use it as I'm trying to migrate from a test wiki (which is just a copy of your online version) to a production wiki for further testing. The crashes stop me finishing that. But no pressure. I just can't do much at the moment.

[pmario]

I knew, that this code-path was brittle, as I wrote it. I'm directly accessing the parser-cache, without knowing if it already exists. I'm using the PageTemplate cache, which should always be available ... But it seems, sometime it doesn't ;)

Now I'm checking the existence. If it doesn't exist it will be created, which should be much more robust.

[TiddlyTweeter]

Well I'm glad you caught the issue now, not later! (I'm in awe of the skill of programmers. It would drive me nuts.)

[pmario]

@TiddlyTweeter I did find this: https://html.spec.whatwg.org/multipage/named-characters.html#named-character-references If you have a closer look at it, you'll see that our almost = ≈ is named: approx

What do you think. Should I give them the "specified" names? IFF they are "rememberable" and "short"

[TiddlyTweeter]

I think "approx" is best (short form of "approximate"). As you are likely aware, as a good writer in English, "about" has many, many meanings in English that are not relevant to CM usage.

[pmario]

see: #73

[TiddlyTweeter]

Is This A BUG? Use Of Parameters In v 0.10.1 Appears to Suppress the ".add-class" Method?

If I create a customise ...

\customize angle=POEM2 _endString=«POEM2 _element=$macrocall $name=addWidth _1=width
\define addWidth(src,width)<div class="poem-strict" style="width: $width$">$src$</div>

»POEM2:"25rem"

... it works WELL and produces ...

div class="poem-strict" style="width: 25rem"> ... etc

BUT if I enter ...

»POEM2.add-class:"25rem"

... the HTML remains ...

div class="poem-strict" style="width: 25rem"> ... etc

... the added class is entirely ignored!

Q: @pmario, I was wondering if that was the intended behaviour, or a bug??

[pmario]

Direct classes can only be assigned, if the _element is an HTML element. It can't work with macros. Macros can get their params from the macro call only.

If a macro is eg:

\define test(a,b) <div class="$a$"><div class="$b$">xx</div></div>

How should the custom »POEM2.add-class know, where to assign something. It can only use the "outer" element. But this outer element would be the macro call. But the macro call doesn't create any elements. It's the macro body that will return something.

[TiddlyTweeter]

Thanks for the clarification! Now I understand why it can't work. It is NOT a deal breaker. But it does mean I'm going to have to re-do my understanding of the syntax! :-)

Q: It should maybe also be mentioned in Advanced Docs?

[TiddlyTweeter]

Tagging Pragma $:/tags/Pragma that contain Macros Does NOT globalise them???

In the process of getting a TW working for your demo I discovered that adding $:/tags/Pragma to a Tiddler the pragmas break on items that have a $macrocall. But tagging those "pragma" tiddlers just $:/tags/Macro enables them to work!

Q: @pmario Is that the expected behaviour?

[pmario]

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

$:/tags/Pragma is intended for tiddlers that contain pragma definitions only. This tag does not import any macros atm. I'll have to have a closer look.

[TiddlyTweeter]

Thanks! For me the issue is that it makes best sense to be able to have the macros just below the pragma most of the time. Otherwise you orphan macros (i.e. you have to store them outside the pragma) from the context they are invoked in! Which makes maintaining the code more complex.

Just thoughts.

[pmario]

That's right. As the global macro definition was done, we didn't have the "call macro" functionality ;) So it's a "missing edgecase"

[TiddlyTweeter]

@pmario, would there be a problem tagging pragma Tiddlers $:/tags/Pragma AND $:/tags/Macro ???

[pmario]

see issue: #72

[AnthonyMuscio]

Gentlemen,

Glad to see this work continuing. You you may of noted my absence, we have being moving house. Lurking a little I also need to find an income but I will be back.

I am most keen at present to develop customised wiki text for an author to quickly add various page elements such as columns, assides, breakout boxes, details, code highlighters to etc...

Given an author would then use custom wiki text it should be trivial to search for lines using such. Thus an excerpt can be extracted from every tiddler containing tickexcerpt. It is this "make use of" custom wiki text once defined that deserves some tools. In some ways it's like debug mode from afar.

Tones

[TiddlyTweeter]

@AnthonyMuscio ... I am most keen at present to develop customised wiki text for an author to quickly add various page elements such as columns, assides, breakout boxes, details, code highlighters to etc...

FWIW, I think Custom Markup is ideal for that. Why? Because, with a bit of thought, you can design an entire markup system that does many things, yet with a fully consistent syntax for end users.

[TiddlyTweeter]

@AnthonyMuscio, you may find it useful to scan the other discussions on CM: #62
and #63.

[TiddlyTweeter]

Note On Limits Of $macrocall Method ... ??? Question.

I wanted to comment that, for instance, in my "CONSOLE" example that the (needed) ...

\rules except dash

... seems to be ignored by a macro when I try to convert the pragma so it will dynamically pass in a style attribute to set the width via "_1=width". It works!
BUT the called macro IGNORES \rules except dash. And that spoils the output as the dashes get converted to em-dashes, which you don't want.

Q: @pmario Is this inevitable?

[pmario]

You can do this:

\define macro()
\rules except dash
...
\end

The "macro parser" starts a new "parser instance" that is not initialized yet. So you need to do it inside the macro body.

[TiddlyTweeter]

That is VERY useful info! Thank you!

[TiddlyTweeter]

Thoughts On Hard-Coded CSS Classes ... Maybe LESS is better??

@pmario ... It is interesting. You did a LOT of work to enable new users to be able to immediately benefit from indenting, colouring and boxing. BUT I'm skeptical it is necessarily best to hard-code classes for the more minimal cases. How can I explain this? Erm ...

Giving the generic class wltc to all CM inserts DOES make sense IMO. It provides a "base mechanism" to apply styles, as and when required by an end user, who simply edits a stylesheet.

But, my sense now, is that auto-insertion of wltc-l1 or wltc-inline to base Glyphs is probably not needed? and, from my point of view, adds redundancy to the rendered HTML??

I DO see that insertion of wltc-l2 for »» ... through to wltc-l4 for »»»» does make sense as a good basic tool for using CM in an "off-the-shelf" way for basic blocks that some users will benefit from.

I hope my comment is clear! It is just an opinion, but maybe useful.
Basically added classes, I think, need to have clear function (apart from wltc which is a generic catch-all and is probably useful) .

I think you should maybe ask about this in the next beta?

Thoughts, TT

[TiddlyTweeter]

Is this a Bug? With "_mode=block" classes in render appear to lack wltc ??

@pmario by accident today, whilst using the HTML preview a lot I noticed that now the wltc class appears NOT to be always applied. Here is the the easiest case I could come up with ...

Q: Is this behavior by design or maybe a side effect of recent changes?? Anyway I thought you should know.

\customise single=TEST-BLOCK-CLASS _element=div _mode=block _classes=".test-class"
\customise single=TEST-INLINE-CLASS _element=div _mode=inline _classes=".test-class"

›TEST-BLOCK-CLASS Testing application of "classes" to _mode=block --- FAILS to include `wltc`

›TEST-INLINE-CLASS Testing application of "classes" to _mode=inline --- SUCCESS to include `wltc`

HTML ...

<div class="test-class wltc-l1">
<p>Testing application of &quot;classes&quot; to _mode=block — FAILS to include <code>wltc</code></p>
</div>
<div class="test-class wltc-l1 wltc">
Testing application of &quot;classes&quot; to _mode=inline — SUCCESS to include <code>wltc</code>
</div>

[pmario]

Did create an issue. #68

[TiddlyTweeter]

Comment: What Do We Actually Mean By "BLOCK" & "INLINE"? :-) :-)

I confess I think I have been confused by something. In TW when we talk about "block" & "inline" we seem to be referring to TWO things that differ. One is the normal HTML sense of "types of element" but also we are referring to the "behavior of a parser".

What confused me a long time was the resultant HTML in render seem quite different, even though the HTML tags are unchanged. A big difference is that "blocks" allow auto-insertion of the <p> tag very liberally.

Q: @pmario is that so? Am I better understanding the difference between (TW) "block" & "inline" or just confused?

[pmario]

You are right. These are 2 different things. ...

HTML elements are default block or default inline, which describes the browser rendering. So how the browser should "show" the elements. .... The html-element default behaviour can be changed by CSS settings;

---

The TW parser always starts with wikitext "block-parsing" eg:

! heading ''some bold text''

step 1
The block-parser will identify the "start of heading" and search for the "end of heading", which is a single new-line. It will create a parse-tree-object like:

[
    {
        "type": "element",
        "tag": "h1",
        "attributes": {
            "class": {
                "type": "string",
                "value": ""
            }
        },
        "children": [
------------ inline parser adds it's info here.
        ]
    }
]

step 2
It will take all the text between "heading start" and "heading end" and give it to the inline-parser. The inline parser will identify the text-elements and the bold-elements and create the rest of the structure, with 2 children. 1) text 2) bold text. like:

[
    {
        "type": "element",
        "tag": "h1",
        "attributes": {
            "class": {
                "type": "string",
                "value": ""
            }
        },
        "children": [
            {
                "type": "text",
                "text": "heading "
            },
            {
                "type": "element",
                "tag": "strong",
                "children": [
                    {
                        "type": "text",
                        "text": "some bold text"
                    }
                ]
            }
        ]
    }
]

step 3 (simplified)
The parser-tree is sent to the "renderer", that takes it and creates the widget-tree. Since there are no widgets here it will end up as "pure" html-text output. like

<h1 class="">heading <strong>some bold text</strong></h1>

[TiddlyTweeter]

Thanks! That is helpful to know!

[TiddlyTweeter]

Nightmare Scenario No.1: Change Default Behavior Of Glyphs? :-)

@pmario at the moment we have 6 block glyphs that behave like this ...

THREE are for <div> (one LINE =\n)
THREE are for <p> (one PARAGRAPH =\n\n)

My NIGHTMARE :-) thought was to better have ...

TWO are for <div> (one LINE =\n)
TWO are for <p> (one PARAGRAPH =\n\n)

... and ...

ONE is for <div> (one PARAGRAPH=\n\n)
ONE is for <p> (one LINE =\n)

Just a thought! TT

[TiddlyTweeter]

@pmario I fully agree with you. I posted the "nightmare" mainly to mark a spot where there may be initial difficulties by users comprehending the behaviours???.

I DO think there will be a need to be very clear in docs about the behaviour of the parser on single line v. paragraph. I think Tony himself had some difficulty with it??? See for instance #62 (reply in thread).

[AnthonyMuscio]

I second that.

I believe there can be a way to use the glyps and the default settings to assist as a memory aid. Key is that each glyph has a default that makes it useful stand alone or with the addition of classes only.

I know alternate or additional glyphs would be annoying at this point but the sun is about to set on such changes.

Unfortunately I am finding it difficult to explore all the combinations at this time.

I am thinking systematically at the new user stage, how can we minimise the complexity before the user starts to use more complex variations and customise.

Basically to write a paragraph for each glyphs default behaviour and use, then provide more advanced guidence on which to customise for different classes of formats eg; html elements or widgets or if you can find an alternate way to group etc.. some of these may be arbitrary but it allows us to guide the users towards a de facto standard. This will mean reading others custom markup may be easier because the defacto guide lines have being used.

Without limiting the possibilities, adding some constraints (unenforced) on which glyph to use for which purpose would help with adoption and documentation.

O hope. I am making sence?

Tony

[TiddlyTweeter]

@AnthonyMuscio I am thinking systematically at the new user stage, how can we minimise the complexity before the user starts to use more complex variations and customise.

The actual way ahead is I think unclear. Based on my use so far I think ...

1. It will pretty EASY to make a whole system in a wiki for a PURPOSE. One example would be Screenplays where the number of HTML constructs you need is small. In a case like that you could RE-ASSIGN the base Glyphs to the 5 needed markup elements. That is a great thing for dedicated apps.
2. The other obvious case, that is easy in principle, is to focus on the .class method, rather than via pragma rules. For many users, I think, that approach EXTENDS existing understanding of TW WikiText in an easier way at first.

IMO the flexibility of @pmario's Custom Markup means that, eventually, I hope you'll see BOTH approaches flourish. (1) is for specialist apps with minimal learning needed; (2) is more generic but may require more documentation (and demos) I think?

Just thoughts, TT

[AnthonyMuscio]

If we keep in mind the idea or importing pragma sets, eg: One for screenplays another for prose, another for manuals we should make it easy for them to be combined (Although this need not be the case).

It is thus where "using a symbol" in the pragma definition may help

Issues

• Makes the Custom mark-up longer
• Suggests adding glyph/symbol combinations to drop-down lists would help
• Suggests a drop down list for each "implementation" (screenplay, prose, manuals) would be useful.

Alternatively to making use of symbols,
tiddlers could have something which indicates which pragma implementation set to use here, in this tiddler, then clashes between different pragmas are not likely to occur. This would be similar to the current classes field on tiddlers, perhaps instead we have a custom-markup field which names the CM implementation set, although I would always encourage the ability to also set this via a variable eg custom-markup in the view template, then if it exists as a field on the tiddler ignore the variable. Thus one can say if tagged screenplay set the custom-markup variable to screenplay, and this applies the screenplay implementation of custom markup. ANy tiddler can be overidden localt to use another markup implementation

If something similar was available for the additional classes we use together with custom markup we should have sufficient control.

What I am suggesting here is making use of existing methods and practices to support the use of multiple custom mark-up sets, and set some standards/guidance to support multiple CM Pragma definitions.

Tony

[pmario]

Yea, Today I was thinking in a similar way. eg:

CTRL-SHIFT-8 ... opens the dropdown
1 shortcut ... will activate the snippet - close dropdown - copy snippet into clipboard
2 shortcut ... will activate the snippet - close dropdown - copy snippet into clipboard

Above the 1..0 shortcuts, there could be a "set - selector"
1 ... can be a select-widget, that allows you to select a snippet
2 ... can be a select-widget, that allows you to select a snippet
3 .. and so on.

So you can have any number of sets. 1 set can have up to 10 elements. Every element can be a different snippet.

Just an idea atm

[TiddlyTweeter]

Comment: Parameter Passing, No. 1. -- _1 & _2 v. _params=":::value1:::value2"

@pmario I spent some time studying your detailed example at test-params-with-https://example.com. I think I finally properly understand parameter passing in CM. I took your example and re-wrote it for myself to understand how it works.
It is pretty awesome!

The way I now express to myself what it can do is ...

In Custom Marked we can set default paramater values using _params= but can override them dynamically directly from CM text too if _1 & _2 are active.

[pmario]

That's right. I think the mechanism is similar as with _classes ... You can define them globally and add new ones with the wikitext command

[AnthonyMuscio]

See a related suggestion about CM meta issues.

[TiddlyTweeter]

Comment: Parameter Passing, No. 2. Thoughts On Use Cases

@pmario I think that your parameter passing that supports defaults with overrides so easily from text is VERY useful for having full easy control over HTML tag attributes.

A simple case would be the <q> tag where we could use _params= to set the default language code automatically, lang="xx", for quote marks and override it via _1 only when needed.

There will be hundreds of cases like that! In time I'll update my examples.

[pmario]

Yes. ... And it will get crazy, once "Comment On _use="[Glyph+String]" #65 will be implemented

[AnthonyMuscio]

Of course one way of "passing values" to macros etc... is setting variables that are used inside the macro, so they are not parameters. Can we explain how variables relate to custom mark-up?

I have always felt the ability to pass a keyword value list 'keyword1=”value1",keyword1=”value2"' then provide tools to then make these lists And turn these into variable=value for use in the macro would help, the fuller use of any parameter.

[TiddlyTweeter]

Comment: Parameter Passing, No. 3. Syntax

@pmario The triple colons ::: I don't think is any problem. Not for me. They are only ever used inside a \customise rule so once you have written it you never need to see them again.

[pmario]

Yea, I thought that too. We don't have triple colons anywhere in default wikitext atm. So we'll see how it goes

[TiddlyTweeter]

REQUEST: CM Stamp Tool Menus Have A class

@pmario, as in my example at #62 (comment), the list of snippets would benefit if I could re-style the CSS. At the moment it is far too "visually noisy" because standard <code> is rendered in a way that is too obtrusive for the purpose there.

To do that, for all of them, in one-go, I'd need a wrapping CSS class, something like: "wltc-snp".

I hope this is clear! Please ask if it isn't.
TT

[pmario]

see issue #83

[TiddlyTweeter]

Query: Are We Limited to TWO _params=:::par1:::par2 ???

This is just a query. Obviously _1 & _2 are the limit from "TEXT".
I just wondered IF _params= can only take 2 parameters? Or can it take more?

TT

[pmario]

Yea, but for some of your examples you use style which imo should be the last resort. ... Hardcoded styles will always win. So they are really hard to "theme". ...

So some users may start to use the !important CSS rule, which from my point of view is toxic.

[pmario]

I think I'll implement _3 and _4 but not documenting it.

[pmario]

And if someone finds the line above, they deserve to know about it ;)

[TiddlyTweeter]

@pmario you use style which imo should be the last resort. ... Hardcoded styles will always win. So they are really hard to "theme".

Right. Agreed. I try to limit it ONLY to necessary values that need defining for special cases (e.g. precise width setting for "Console Emulation" instances).

[TiddlyTweeter]

@pmario ... some users may start to use the !important CSS rule, which from my point of view is toxic.

Right.
FYI, I did a couple of experiments with Custom Markup creating via macro small in-Tiddler <style> blocks of .classes. It worked well but was too complex to maintain because you need a unique name for each css class in every Tiddler. style= is much easier to maintain.

[TiddlyTweeter]

@pmario, shall I start a new discussion for "Experiments With Custom Markup"?
I have one that is about trying to dynamically change GlyphSymbol via transclusion.

[pmario]

Yea, Why not.

Did push V 0.11.4 which fixes RSOD and adds some new functions. ...
The snippet tree is much more work as I thought. Will need more time.

[TiddlyTweeter]

Did push V 0.11.4 which fixes RSOD and adds some new functions. ...

Great! I'll test over next couple of days.

The snippet tree is much more work as I thought. Will need more time.

Right. TBH I think treeing snippets is actually of broader relevance to TW editor generally too!
Maybe a solution in CM will also work for snippets in general? A generic plugin?

I have no expectations.
Just very grateful you recognize the issue.
TT

[pmario]

The problem is the tree-macro. It needs to be much more flexible. I also want to use it for one of my other plugins. ... I'll try to get the changes into the core. ... So that's why it will take longer. ...

Yea, I was thinking about a mechanism to detect the "cm-tree-macro". If it's there ... use it. If not show the existing list.

[AnthonyMuscio]

Using custom markup to prepare content for copy.

I was just thinking since we can use custom markup to use html elements or widgets to render perhaps it can be used to support content reuse through copy. For example a button could be used to display one thing but click to copy another format. Or perhaps just smart html formats?

[TiddlyTweeter]

@AnthonyMuscio Perhaps inline styles removing CSS dependencies etc would make what is copied more useful.

Tony, as far as I understand it TW has no method to inline ALL styles you'd need. It would need a special plugin to do that.
FYI I have very successfully used browser plugins to achieve it for email and Google Groups that works well.

See the here for more info and basic examples: discussion on GG.

[pmario]

1 goal of CM was to create something that allows you to create a nice looking "copy to clipboard" function. IMO this would give you a possibility to copy / paste pretty much what ever you want

[TiddlyTweeter]

1 goal of CM was to create something that allows you to create a nice looking "copy to clipboard" function. IMO this would give you a possibility to copy / paste pretty much what ever you want

Ciao @pmario maybe we could add that as a discussion? FWIW I have tended to just use copy and paste from the HTML "preview" panel to get HTML for email I need. Why? I simply have not worked out an easier method under a button.

[pmario]

I send "text only" e-mails. .. So there is no need for html for me.

[TiddlyTweeter]

I send "text only" e-mails. .. So there is no need for html for me.

Okay. Me likewise! But I do send out "worksheets" to students periodically and HTML email might prove better if it were easier to pass the code. I'll report back if I figure it out. Best, TT

[TiddlyTweeter]

First Comments on V 0.11.4

@pmario it worked fine. No RSODs on _use= anymore.
And I successfully was able to use all _4 parameters.

So a BIG thumbs up! Thankyou!

There are a couple of minor issues but I need to document them for you for my comments to be useful.
I have Covid at the moment so it may take a few days yet.
TT

[pmario]

I have Covid at the moment so it may take a few days yet.

Wish you all the best. Get well soon!

[AnthonyMuscio]

Automatic Closure at end of tiddler;

Question/idea;

Given we can handle the closure of elements based on an end string and these end strings are often automatic!

Is it feasible to allow these to be closed in reverse order at the end of the tiddler?, ie the ability to request the end of the tiddlewr to be the end string and honour "nesting"

why

We could use custom pragmas to define things that wrap the content such as the $vars widget, or a div that wraps the who0le tiddler content (after the pragmas if any.

I believe there are a suit of issues arising for users where they would like to determine and apply values to the whole tiddler, but maintaining the matching closure adds complexity and often errors so perhaps having the ability to automatically close at the end of the tiddler some custom mark-up could be very useful, we could then make statements rather than necessarily wrapping the content or closure.

I do not know what if any technical issues may make the difficult or easy but surely its worth considering. eg _endString="eot" end of tiddler.

[TiddlyTweeter]

@AnthonyMuscio Is it feasible to allow these to be closed in reverse order at the end of the tiddler?, ie the ability to request the end of the tiddlewr to be the end string and honour "nesting"

Just FYI, couple of things.

First, as far as I understand it, all modern browsers auto-close open tags in "reverse nested" order they were created in. In TW that occurs in the Tiddler (though I'm unclear what would happen under TRANSCLUSION!!!).

Second, because the core parsers in TW are very clever, you might well find that your HTML output is populated by additional unwanted <p> elements???

I'm a bit unclear WHAT you'd need this for??? Dimmi (tell me! :-)

[TiddlyTweeter]

@AnthonyMuscio I do not know what if any technical issues may make the difficult or easy but surely its worth considering. eg _endString="eot" end of tiddler.

It is not needed to assert _endString="eot" IF you define an end string and just don't use it closure will be at the end of the Tiddler.
I wouldn't say it is a good idea to do that though! :-)

\customise degree=tony _endString=tony°

°tony wrap tony°
<p>1</p>
<p>2</p>
<p>3</p>

... resultant HTML render ...

<div class="wltc-l1 wltc">wrap </div><p><p>1</p>
<p>2</p>
<p>3</p></p>

COMPARE to this ...

\customise degree=tony _endString=tony°

°tony wrap 
<p>1</p>
<p>2</p>
<p>3</p>

... resultant HTML render ...

<div class="wltc-l1 wltc">wrap
<p>1</p>
<p>2</p>
<p>3</p></div>

[TiddlyTweeter]

Queries On _mode=block V. _mode=inline In Custom Markup (& core?)

This picks up on some issues @pmario raised in the Issue #95 (comment) concerning regex _endString= and issues involving TW core parsing (and a bug in it??).

These are just comments & questions. I am just trying to get clear on some real aspects of parsing behavior ...

1. Am I correct in thinking that ... when _mode=block in a \customise every \n\n in the "block" is automatically converted to <p> ?
2. IS that auto-insertion due to the "core" parser? (Sidenote: in a way it makes some sense for "container" blocks like div but not within <p> blocks, which are not supposed to nest??)
3. Am I correct that ... when _mode=inline (the default) in a \customise then this SUPPRESSES the behaviors that (1) & (2) invoke?

This is not any kind of criticism. I'm just trying to be explicit! :-)
TT

[pmario]

1. Am I correct in thinking that ... when _mode=block in a \customise every \n\n in the "block" is automatically converted to

   ?

Yes for "angle", "approx" and "pilcrow". It's the same behavior as the default TW parser.

"tick", "single" and "degree" work with DIV and a single \n

[pmario]

2. IS that auto-insertion due to the "core" parser? (Sidenote: in a way it makes some sense for "container" blocks like div but not within <p> blocks, which are not supposed to nest??)

Yes and No. ... The CM code only behaves the same way, because I use unmodified core functions.

---------- "geek speak" warning

this.parser.parseBlocks(terminatorRegExpString) and this.parser.parseBlock(terminatorRegExpString). (see the "s" in Blocks vs. Block)

If .parseBlock doesn't find a wikitext "block-rule" it uses a P tag by default. So for standard wikitext this is eg:

<<<
some text in a blockquote
<<<

versa this text in a P tag

The second paragraph doesn't have a specific block-rule, that's why a P tag is used.

With CM I'll need to trick the default behavior. I do have to make sure, that parseBlock() always finds a rule and uses it.

[pmario]

3. Am I correct that ... when _mode=inline (the default) in a \customise then this SUPPRESSES the behaviors that (1) & (2) invoke?

There are completely different function used this.parser.parseInlineRun(terminatorRegExp,options). Inline runs work for rules like /° xxx °/ and ''bold''

[TiddlyTweeter]

Thanks @pmario for explaining the behavior. I still don't 100% understand it. BUT you definitely are confirming my naive understanding on observed "block" behaviors. As I commented several times, for the average idiot like me, the "crossing" of different concepts of what a "block" is (i.e. [1] a type of element AND also [2] a parsing behavior) is a bit of a mind-warp :-) :-).

[TiddlyTweeter]

Comments on V 0.11.4 Parameter Passing

Finally, as promised, are my comments on parameter passing.
I made an example as its not so easy to explain ...

\\ Demo of unanticipated default _params deletion

\customise degree=TS _element=$macrocall $name=testSet _params=":::P1:::P2" _1=test-1 _2=test-2

\define testSet(src,test-1,test-2)
<p>$test-1$ $test-2$ $src$</p>
\end

°TS -- Case 1: FINE with defaults.

°TS::"Override P2" -- Case 2: BREAKS - without quote marks for param 1.

°TS:"":"Override P2" -- Case 3: DELETES P1 - with quote marks for param 1.

°TS:"Override P1":"Override P2" -- Case 4: FINE - correctly replaces P1 & P2 when needed.

The real issue is in Case 3.

I didn't want to delete the first item in _params= BUT you have to use :"" otherwise the parameter passing breaks (Case 2).
So in Case 3 what is passed is the value of the "empty string" for _1=test-1.

You see the issue? It gets worse the more params you pass through the text.
Being able to preserve default values unless you explicitly override them was what I was hoping for :-)

Please ask if the example is unclear!