Custom markup (continued 2)

290 views
Skip to first unread message

PMario

unread,
Sep 16, 2020, 6:22:05 AM9/16/20
to tiddly...@googlegroups.com
Hi folks,

This is the continuation of Custom markup [1] and Custom markup (continued) [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

V 0.4.0 https://wikilabs.github.io/editions/tick-text

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

PMario

unread,
Sep 16, 2020, 8:46:20 AM9/16/20
to TiddlyWikiDev
New Version 0.4.0 uploaded:

It contains the fixes, that Tony mentioned in the last 3 or 4 posts at: Custom markup (continued) [2]

I did remove the "comma", since it didn't work out for me at the start of the line eg:
,.something ... There isn't enough visual difference between comma and dot. ,.

I did add 2 new ID chars: ≈ ›  

≈ .. works similar to » and uses \n\n as the default _endString
≈ .. ID name is "almost"

› .. is a "tick-like" ID and can be toggled. Indent needs to be done with ›.i.i ... similar to tick
› .. ID name is "single" ... for single right angle quote

There is more docs. .. and in the making.


have fun!
mario
Message has been deleted
Message has been deleted

@TiddlyTweeter

unread,
Sep 17, 2020, 6:20:40 AM9/17/20
to TiddlyWikiDev
Revert to "Classic" (on Desktop). This will also let you complain to Google as it will ask you why you are reverting ...

TT

On Wednesday, 16 September 2020 19:59:23 UTC+2, Mat wrote:
Annoyingly I can't "reply privately to author" anymore so must post this publicly:

@PMario - could you edit the first post in this thread to include the main link you recommend for testing things?
Tx

<:-)
On Wednesday, September 16, 2020 at 12:22:05 PM UTC+2 PMario wrote:
Hi folks,

This is the continuation of Custom markup [1] and Custom markup (continued) [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

have fun!
mario

PMario

unread,
Sep 17, 2020, 12:22:28 PM9/17/20
to TiddlyWikiDev
------------ OT ------------

On Thursday, September 17, 2020 at 12:20:40 PM UTC+2, @TiddlyTweeter wrote:
Revert to "Classic" (on Desktop). This will also let you complain to Google as it will ask you why you are reverting ...

PMario

unread,
Sep 17, 2020, 5:02:49 PM9/17/20
to TiddlyWikiDev
Hi

New Version 0.4.1 https://wikilabs.github.io/editions/tick-text/  with more docs!

@Mat, there should be enough Basic, Advanced and Reference material now, to test it!

No new functions

have fun!
mario

TonyM

unread,
Sep 17, 2020, 8:28:28 PM9/17/20
to TiddlyWikiDev
Mario

More notes
  • I notice if I have the cursor anywhere in a line and apply the ID it works however the cursor jumps to the end of the line
    • If the cursor could remain where was, or perhaps be placed just after the symbol I could then type a .class or something, but this way all I save is hitting the end key.
  • Perhaps the short form of color boxes ".cbox-primary" should be cbp cbs etc... this leaves .cb available for simple color Blue
  • Perhaps a little padding could be added to each box definition "padding: 4px;"
  • I see value retaining the following styles working especially if the .i.i.i and .r.r.r do not work (why?)
    .i { margin-left: 2.65em; }
    .ii { margin-left: 5.3em; }
    .iii { margin-left: 7.95em; }
    .r { margin-right: 2.65em; }
    .rr { margin-right: 5.3em; }
    .rrr { margin-right: 7.95em; }

Related notes
  • An interesting observation is if you select and copy a rendered tiddlers text and paste it into a new tiddler, the result really needs this custom formatting help.
    • If you paste same into another apps like outlook you can keep the source formatting.
    • Perhaps this is something we could fix one day? Eg HTML to Wikitext, even an incomplete conversion.
    • The Code of course knows wikitext to HTML, pity we cant use this for HTML to Wikitext, this may be more easy now we have this opportunity.
Questions arising?
  • There is a large set of html color names, I wonder if there were a way to pass these into a text or background colour via this mechanism?
    • one example "°.class#green This is green text "
    • This would avoid needing to code a set of foreground and background colour specified classes
Incidental ideas.
  • The ability to select some text and have it duplicated. in place with an editor toolbar could be useful in general
    • However it would also help if one wanted to add another special character, just highlight it and hit the button to add another as well.
    • A matching duplicate line / selection / block as well would help.
Posted review from Yesterday,

Tony

TonyM

unread,
Sep 17, 2020, 8:34:16 PM9/17/20
to TiddlyWikiDev
Mario,

I have to download your new versions so I can save changes. Then you release another. Could you add the local storage plugin (not enabled) so I can activate it install other plugins is needed? I will export local storage, then clear local storage and reload when you release a new version and selectivity restore my working tiddlers? 

This is a method that works quite nicely on my playground https://anthonymuscio.github.io/playground.html

Tony

TonyM

unread,
Sep 17, 2020, 9:20:37 PM9/17/20
to TiddlyWikiDev
Mario,

View on top of V4.1
  • I think you could delegate the historical methods to a link rather than have them complicate the documentation from the beginning. How to style a Paragraph Misusing standard wikitext to indent a paragraph
  • Will there be some smart defaults for each special Characters out of the box, so unless they are inadequate they serve a purpose right away?
    • angel is already somewhat defined
    • If so a list of special Characters and their default functionality up front and an explanation of the buttons would be enough to get started. Including the name used in the customise pragma eg degree, perhaps the official character names would also help some.
  • Perhaps for shortcuts you could suggest in the doco the user may select alternatives that map to a similar character on their keyboard layout eg alt-' for tick alt-. for its shift > value for angle etc...
  • "markup for advanced users", yet to be written could be "use focused" (initially) rather than technically the current solution eg
    • Introducing html tags into you own markup
    • Using classes to rapidly style your content with css
    • Using the end string or \n or \n\n to terminate your custom markup
    • It may also provide one or more "libraries" of css that can be activated. In future you could add effective ones, developed in the community (like mine :)
      • When ever a solution enables the accumulation of techniques and methods it improves over time.
  • Perhaps in https://wikilabs.github.io/editions/tick-text/#Custom%20Markup%20Definition explain why the parameters begin with an underscore, this helps understanding and remembering the fact.
Wiki text integrations
By the way, this is so cool, and possibly replaces the need for custom macros in many cases. meaning once you know how to use is not need to write the macro solution when you can use a custom wikitext marker
  • This area will take sometime to explore; here is a quick test of mine, how would we go about forcing a line feed or using a template?
\customize tick="listtagging" _element="$list"  filter="[tag<currentTiddler>]"
´listtagging

\customize tick="listtagging" _element="$list"  filter="[tag<currentTiddler>]" template="$:/core/ui/ListItemTemplate2"
´listtagging
This works with a break after the link widget in the template

\customize tick="listprefixed" _element="$list"  filter="[all[]prefix<currentTiddler>]" template="$:/core/ui/ListItemTemplate2"
´listprefixed


Questions
  • Do you want a continued search for appropriate uni-code characters or are you happy with the available ones?
  • As in the examples above Wiki text integrations how do I make these useful options global?
    • I am confident I will want to push examples like ´listprefixed into view templates and macros so I must test these. Do you foresee any problems?
My Review continues;

Tony

On Friday, 18 September 2020 07:02:49 UTC+10, PMario wrote:

TonyM

unread,
Sep 17, 2020, 9:40:10 PM9/17/20
to tiddly...@googlegroups.com
Mario et al, minor related diversion.

In the process of us developing this solution I see the value in the use of templates, but this makes me baulk, because the standard naming needs to be a system tiddler, then as a result it needs another prefix such as in my last example 
$:/core/ui/ListItemTemplate2 we want to hide these so we are forced to use $:/

I have had in my mind the introduction of another namespace that allows simpler names for tiddlers and especially transclusions, 
  • I share now because it stands to improve markup further however we can start a new thread. 
The idea would be to use a low impact title appropriate indicator such as wrapping a title in standard brackets;
  • eg: a tiddler named (listlines) could replace $:/core/ui/ListItemTemplate2
    • {{||(listlines)}} is better (in my view) even than {{$:/listlines}} but we reallyneed {{$:/qualifier/listlines}}
  • This will work quite well as is, but my though is to treat such tiddlers as system tiddlers
  • It seems to me modifying the standard search to ignore titles (so wrapped) would be a start.
    • But then being able to preclude them in lists etc.. may be helpful
    • And including the operators is[bracketed] all[bracketed] etc.. would be good as well
  • Another simple example may be a user generated signature {{(signature)}} or other reusable content.
  • Or template=(listlines)
Why?
There are plenty of places where one designs a wiki where a solution may include external content, especially for templates where not being able to choose every day names, forces a need to lookup the tiddler in the system namespace. It makes it harder to provide more user friendly and easy to read markup.

All your initial thoughts please, do I start a new thread? Our could this be part of this solution?

Regards
Tony

On Friday, 18 September 2020 07:02:49 UTC+10, PMario wrote:

TonyM

unread,
Sep 17, 2020, 10:21:21 PM9/17/20
to TiddlyWikiDev
Version 4.0.1 Review continued; Advanced custom markup

As I said before, I love the "details" example of yours. However I just wanted to let you know, I do not resonate with you use of multiple hyphens -- and --- etc, perhaps because of my eye-site or the difficulty matching or remembering how many to do what. This example with the existing system is a little better for me;

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

´d ´s Details - Summary /s
line
1
line
2
/d
So I am quite happy with the "out of the box" solution.

However this prompts me to ask, if for block custom wikitext, that could we automate the end string if desired? eg wrap something in 
´d details here ´/d

or

´d
line
1
line
2
´/d

Where the ´/d or /d
  • is the default end-string unless one is provided
  • and of course all "Symbol/anything" are only possible end strings 
I expect this details and similar incantations are going to give us something many have called for, for a long time, easy sliders and toggled content. This also helps with Q&A quizzes, tests etc...

Question;
In the following case where I define a "More Details"
\customize tick="md" _element="details" _params=".notop.cbox.cbox-primary.hard-linebreaks" _endString="/md" _mode=block  
\customize tick="m" _element="summary" _params=".margin-init"

´md ´m
line
1
line
2
/md
  • Is there a way the tick="m" provides its own content eg more...
  • Or could we even hide the ´m in the ´md definition? ie define the summary in the more details since it is a default?
Regards
Tony



On Friday, 18 September 2020 07:02:49 UTC+10, PMario wrote:

PMario

unread,
Sep 18, 2020, 5:24:01 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 2:28:28 AM UTC+2, TonyM wrote:
[...]
  • I notice if I have the cursor anywhere in a line and apply the ID it works however the cursor jumps to the end of the line
    • If the cursor could remain where was, or perhaps be placed just after the symbol I could then type a .class or something, but this way all I save is hitting the end key.
I'll have a look, if there are functions in the core, that allow us to set cursor position.
 
  • Perhaps the short form of color boxes ".cbox-primary" should be cbp cbs etc... this leaves .cb available for simple color Blue
OK .. I'll make them .cb .. for the box definition and .cbX for the color definitions.
  • Perhaps a little padding could be added to each box definition "padding: 4px;"
The idea is to have .cb for padding, margin and so on. .cbX is color only. .. So if you need a new xb you should define one. The "box padding" is already very big for my personal taste.

We may be able to use CSS variables, to make settings more dynamic. ... We'll see. @Mat is the CSS variable voodoo master?
 
  • I see value retaining the following styles working especially if the .i.i.i and .r.r.r do not work (why?)
The browser doesn't do it that way. <div class="i i i xx" > is the same as <div class="i xx" ... 
  • .i { margin-left: 2.65em; }
    .ii { margin-left: 5.3em; }
    .iii { margin-left: 7.95em; }
    .r { margin-right: 2.65em; }
    .rr { margin-right: 5.3em; }
    .rrr { margin-right: 7.95em; }
I'll add the RRRs ... but I personally would only use the .r ..
.r and .-i .. is the same thing

-mario

PMario

unread,
Sep 18, 2020, 5:33:45 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 2:28:28 AM UTC+2, TonyM wrote:

Related notes
  • An interesting observation is if you select and copy a rendered tiddlers text and paste it into a new tiddler, the result really needs this custom formatting help.
I think this could be done with the TW drag&drop mechanism. ... That's a TW feature request.


Questions arising?
  • There is a large set of html color names, I wonder if there were a way to pass these into a text or background colour via this mechanism?
    • one example "°.class#green This is green text "
    • This would avoid needing to code a set of foreground and background colour specified classes
The problem is, that °.class#green isn't specific enough if you want the text color, text background, image color or image background

So the way to go is °.X  where X is defined in a CSS tiddler and exactly defines, what should be done.

The "customize parser" is already overloaded. It's probably the "biggest" parser element in TW already. .. IMO it is already a bit "feature overloaded"

 
Incidental ideas.
  • The ability to select some text and have it duplicated. in place with an editor toolbar could be useful in general
    • However it would also help if one wanted to add another special character, just highlight it and hit the button to add another as well.
    • A matching duplicate line / selection / block as well would help.
You want a "clone / duplicate selection" button?

-m

PMario

unread,
Sep 18, 2020, 5:39:04 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 11:24:01 AM UTC+2, PMario wrote:

  • Perhaps the short form of color boxes ".cbox-primary" should be cbp cbs etc... this leaves .cb available for simple color Blue
OK .. I'll make them .cb .. for the box definition and .cbX for the color definitions.

I just found out that I used:  .c, cbox ... cb isn't used. .. So you can use it for color Blue. .. but as I wrote you are not specific enough

IMO it needs to be

.bg-b  .. background blue
.fg-b  .. text color blue and so on.

There is no standard yet. ... So we may have a look at "short" but specific shortcuts. ... May be: https://tailwindcss.com/ will give us some hints. The idea behind the mechanism is the same.

So I'll change nothing atm.
-mario

PMario

unread,
Sep 18, 2020, 5:45:44 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 2:34:16 AM UTC+2, TonyM wrote:

I have to download your new versions so I can save changes. Then you release another. Could you add the local storage plugin (not enabled) so I can activate it install other plugins is needed? I will export local storage, then clear local storage and reload when you release a new version and selectivity restore my working tiddlers? 

I'll use my release setup from now on. So the plugin will get new version numbers. Only if the plugin changes.
The TW importer can be used to import new plugin versions.

The edition (docs) will have its own versioning.

I'll need to rename the plugin from Tick Paragraph to Custom Markup
The edition will be custom-markup too .. So the URL will change. ..
 
-m

PMario

unread,
Sep 18, 2020, 6:16:03 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 3:20:37 AM UTC+2, TonyM wrote:
...
View on top of V4.1
That will be a ToDo, since we will need to improve the TW doc quite a bit, so we can link to it. The existing docs for specific styling imo needs some love
 
  • Will there be some smart defaults for each special Characters out of the box, so unless they are inadequate they serve a purpose right away?
    • angel is already somewhat defined
Yea, I thought, that angel is the only one, that has active toolbar buttons, if you install the plugin. So it can be used "out of the box". Mainly to modify paragraph styling.

All the other toolbar buttons can be enabled using the ControlPanel and the Plugin Settings / Plugin Readme page.
    • If so a list of special Characters and their default functionality up front and an explanation of the buttons would be enough to get started. Including the name used in the customise pragma eg degree, perhaps the official character names would also help some.

But the "special" chars do nothing visual "out of the box" other than covering 1 line of text into a "div" with no styling. Similar to » which starts to create a difference, if you use 2 of them »» ..

  • Perhaps for shortcuts you could suggest in the doco the user may select alternatives that map to a similar character on their keyboard layout eg alt-' for tick alt-. for its shift > value for angle etc...
I think editor keyboard shortcuts need a button, per shortcut. ... Is there some info at tiddlywiki.com how to create buttons and shortcuts. .. I'm not keen to create it.
 
  • "markup for advanced users", yet to be written could be "use focused" (initially) rather than technically the current solution eg
    • Introducing html tags into you own markup
    • Using classes to rapidly style your content with css
    • Using the end string or \n or \n\n to terminate your custom markup
    • It may also provide one or more "libraries" of css that can be activated. In future you could add effective ones, developed in the community (like mine :)
      • When ever a solution enables the accumulation of techniques and methods it improves over time.
  • Perhaps in https://wikilabs.github.io/editions/tick-text/#Custom%20Markup%20Definition explain why the parameters begin with an underscore, this helps understanding and remembering the fact.
OK will go to ToDos
 
Wiki text integrations
By the way, this is so cool, and possibly replaces the need for custom macros in many cases. meaning once you know how to use is not need to write the macro solution when you can use a custom wikitext marker
  • This area will take sometime to explore; here is a quick test of mine, how would we go about forcing a line feed or using a template?
\customize tick="listtagging" _element="$list"  filter="[tag<currentTiddler>]"
´listtagging

\customize tick="listtagging" _element="$list"  filter="[tag<currentTiddler>]" template="$:/core/ui/ListItemTemplate2"
´listtagging
This works with a break after the link widget in the template

\customize tick="listprefixed" _element="$list"  filter="[all[]prefix<currentTiddler>]" template="$:/core/ui/ListItemTemplate2"
´listprefixed


Yea, that's really cool. .. I want to have the copy-to-clipboard widget, that can be customized. ... the existing solution is a TW docs-macro. .. And we can't call macros. .. So I'll create a new widget. .. Not sure, if Jeremy will merge it.
 

Questions
  • Do you want a continued search for appropriate uni-code characters or are you happy with the available ones?
I would be happy to get new ones. .. At the moment I'm happy with the existing situation. We have 4 + 2. 4 that stop at \n and 2 that use \n\n

We will see, how the community reacts. It's basically a "keyboard layout" problem. I think only 1 character has to work, to use the full potential.

  • As in the examples above Wiki text integrations how do I make these useful options global?
    • I am confident I will want to push examples like ´listprefixed into view templates and macros so I must test these. Do you foresee any problems?
At the moment I personally would _not_ use this in TW ViewTemplate or tiddlers tagged with $:/tags/ViewTemplate .. it's too dangerous to "brick" the system.

At the moment the only way to influence the parser is \importcustom per tiddler and per macro. BE AWARE

\define x()
\importcustom [[pragma-details]]
°d °s Details - Summay
---
line 1
line 2
------
\end

<<x>>

Pragma definitions have to be imported on a per macro basis. BUT you can use [tag[xxxx]] to import several of them.

BUT this will slow down templates. ... I'm not sure if I would use it that way. .. The parsing results are cached on a per tiddler basis by TW core. .. BUT I'm not sure if this will be used here.

PMario

unread,
Sep 18, 2020, 6:23:20 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 12:16:03 PM UTC+2, PMario wrote:

At the moment the only way to influence the parser is \importcustom per tiddler and per macro. BE AWARE

\define x()
\importcustom [[pragma-details]]
°d °s Details - Summay
---
line 1
line 2
------
\end

<<x>>

I also don't see any advantage of the custom system here. It's only slowing things down. If you want to create macros, you should definitely use the existing system only.

It will avoid the introduction of 3rd party dependencies.

just my thoughts
mario



PMario

unread,
Sep 18, 2020, 6:55:56 AM9/18/20
to TiddlyWikiDev
I'll give it an  ---------------- OT ----------------- marker.
But it is slightly related.

You are right. "readable" wikitext shouldn't contain the $:/xxx/yyy/zzzz namespace.

I was already thinking about the possibility to use my uni-link plugin with the custom-markup plugin.

At the moment unilink allows you to give every tiddler an "aliases" field, which can contain several aliases.
At the moment it will _not_ use "shadow" tiddlers for speed reasons. We know, that no core shadows use aliases atm. This would need to be changed.

[[aliasName|?]] will create a link to any tiddler including system tiddlers.

[[AliAsNaMe|?]] is _not_ case sensitive, this gives the user the possibility to nicely use it in prose text. eg: At the start of the line.

[[aliasName|?c]] will show the caption field as the link text. [[aliasName|?myField]] can use any field.

------

The right sidebar More: Aliases tab gives an overview about used aliases.

The plugin comes with 2 new toolbars to improve usability of aliases.

There are some filter functions for alias-backlinks ... and so on.

IMO . It should be possible to use \importcustom [[alias|?]] ... BUT I'm not sure if this is an advantage already.

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

I was hesitating to allow [[alias|?{]]  or something similar as a representation for {{real tiddler name}}

The only reason to do that, would be the "backlinks" mechanism would work for these links.

just some thoughts.

-m

PMario

unread,
Sep 18, 2020, 6:58:13 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 3:40:10 AM UTC+2, TonyM wrote:

In the process of us developing this solution I see the value in the use of templates, but this makes me baulk, because the standard naming needs to be a system tiddler, then as a result it needs another prefix such as in my last example 
$:/core/ui/ListItemTemplate2 we want to hide these so we are forced to use $:/

You can use a field name: my-field: template for $:/xxx

\customize template={{{[my-field[template]]}}} should give you the right tiddler name

I didn't test it, but I think it should owrk.
-m

TonyM

unread,
Sep 18, 2020, 7:06:13 AM9/18/20
to TiddlyWikiDev
Mario,

Like Tail winds says;
Most CSS frameworks do too much. They come with all sorts of predesigned components like buttons, cards, and alerts that might help you move quickly at first, but cause more pain than they cure when it comes time to make your site stand out with a custom design.

  • I suppose what I think we need  is an even simpler set for the author of the content in a tiddler, leveraging CSS for layout and formatting within that space. All more easily implemented via the customised wikitext. No need to stray into designer territory since that is handled already. I best do a little research.

  • Yes I do "..want a "clone / duplicate selection" button? "
    But I can create it. Just noting its value along side customised wikitext

I observe - No Quote or code button in the new Groups!

  • I am expecting your link changes etc...
  • Custom Markup  sounds good 

Regards
Tony


PMario

unread,
Sep 18, 2020, 7:11:32 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 4:21:21 AM UTC+2, TonyM wrote:

As I said before, I love the "details" example of yours. However I just wanted to let you know, I do not resonate with you use of multiple hyphens -- and --- etc, perhaps because of my eye-site or the difficulty matching or remembering how many to do what. This example with the existing system is a little better for me;

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

´d ´s Details - Summary /s
line
1
line
2
/d
So I am quite happy with the "out of the box" solution.

That's fine. You can use it that way. I'll add some more information, that the _endString is "just a convention" (In this case my convention). But everyone can develop their own thing.
 
However this prompts me to ask, if for block custom wikitext, that could we automate the end string if desired? eg wrap something in 
´d details here ´/d

tick automatically defaults to end of line. So you can skip it, if there is only 1 line like your example
 
´d
line
1
line
2
´/d

Where the ´/d or /d

This can be done. You only need to configure it that way.
 
  • is the default end-string unless one is provided
yes. 4 + 2 ... 4 elements use \n and 2 elements use \n\n by default.
  • and of course all "Symbol/anything" are only possible end strings 
It has to be a unicode character. So it basically depends on the OS and the installed unicode fonts, what's possible.
 
I expect this details and similar incantations are going to give us something many have called for, for a long time, easy sliders and toggled content. This also helps with Q&A quizzes, tests etc...

Yes. .. I was thinking about a "details widget", that can store the state.

There may be some CSS eg: for printing, that makes all the details open by default ... or something similar.
 

Question;
In the following case where I define a "More Details"
\customize tick="md" _element="details" _params=".notop.cbox.cbox-primary.hard-linebreaks" _endString="/md" _mode=block  
\customize tick="m" _element="summary" _params=".margin-init"

´md ´m
line
1
line
2
/md
  • Is there a way the tick="m" provides its own content eg more...
Use:

´md ´m more ...
 
  • Or could we even hide the ´m in the ´md definition? ie define the summary in the more details since it is
  • a default?
If you use this:

´md
line 1
line 2
/md

The browser will use a "default" summary. It's a _browser_ thing. So I do nothing here.

-mario

TonyM

unread,
Sep 18, 2020, 7:39:42 AM9/18/20
to TiddlyWikiDev
Mario,

Some responces;

That will be a ToDo, since we will need to improve the TW doc quite a bit, so we can link to it. The existing docs for specific styling imo needs some love

So true 
 
 
  • Will there be some smart defaults for each special Characters out of the box, so unless they are inadequate they serve a purpose right away?
    • angel is already somewhat defined
Yea, I thought, that angel is the only one, that has active toolbar buttons, if you install the plugin. So it can be used "out of the box". Mainly to modify paragraph styling.

All the other toolbar buttons can be enabled using the ControlPanel and the Plugin Settings / Plugin Readme page.

Yes, but apart from naming the two that respond to \n\n would it make sense to give some default customisations for the additional characters so the work out of the box, many users may then simply select from an existing character, perhaps add a class we provide and that is the end of the story for them. No need to revert to customisations. This may allow instructions to be shared without having to present bespoke customisations except for those keen to extend the power;

Example (just a brainstorm) may be inaccurate as I learn still to memorise the existing, its just the concept. I am still to learn how some simple defaults will lend them self to each character. But publishing firs as just a larger set of symbols and no defaults my b fine with a view to giving them some defaults as we lean more about the scope and opportunities.
  •  ° degree use for emphasis 
  •  ´ to introduce styles
  •  › dividers lines/headings 
  •  _ specials including html 
  •  » Formatting blocks
  •  ≈ indicating state
    • But the "special" chars do nothing visual "out of the box" other than covering 1 line of text into a "div" with no styling. Similar to » which starts to create a difference, if you use 2 of them »» .. 
 And this is what I question, perhaps we do craft some default behaviours, because many users may be happy with the "Out of the box" only.
  • Perhaps for shortcuts you could suggest in the doco the user may select alternatives that map to a similar character on their keyboard layout eg alt-' for tick alt-. for its shift > value for angle etc...
I think editor keyboard shortcuts need a button, per shortcut. ... Is there some info at tiddlywiki.com how to create buttons and shortcuts. .. I'm not keen to create it.

Me neither, was doing it recently for myself, I have to return to that, but It was becoming a night mare. However I need to so perhaps this is my Job then.

But - all I am saying is to add to the documentation that users can go to the definitions at Control Panel > Keyboard Shortcuts and select alternatives that map to a similar character on their keyboard layout eg alt-' for tick alt-. for its shift > value for angle etc.. (no more or less)

Wiki text integrations
By the way, this is so cool, and possibly replaces the need for custom macros in many cases. meaning once you know how to use is not need to write the macro solution when you can use a custom wikitext marker
  • This area will take sometime to explore; here is a quick test of mine, how would we go about forcing a line feed or using a template?
\customize tick="listtagging" _element="$list"  filter="[tag<currentTiddler>]"
´listtagging

\customize tick="listtagging" _element="$list"  filter="[tag<currentTiddler>]" template="$:/core/ui/ListItemTemplate2"
´listtagging
This works with a break after the link widget in the template

\customize tick="listprefixed" _element="$list"  filter="[all[]prefix<currentTiddler>]" template="$:/core/ui/ListItemTemplate2"
´listprefixed


Yea, that's really cool. .. I want to have the copy-to-clipboard widget, that can be customized. ... the existing solution is a TW docs-macro. .. And we can't call macros. .. So I'll create a new widget. .. Not sure, if Jeremy will merge it.

There is the "WidgetMessage: tm-copy-to-clipboard", but it is only an action widget. Would it be more productive to feed the message (or action tiddler title) into a button?
I will experiment on that.

 
 

Questions
  • Do you want a continued search for appropriate uni-code characters or are you happy with the available ones?
I would be happy to get new ones. .. At the moment I'm happy with the existing situation. We have 4 + 2. 4 that stop at \n and 2 that use \n\n

OK
 

We will see, how the community reacts. It's basically a "keyboard layout" problem. I think only 1 character has to work, to use the full potential.

I agree, but the value of more than one, Is why I proposed some different default behaviours. 
 

  • As in the examples above Wiki text integrations how do I make these useful options global?
    • I am confident I will want to push examples like ´listprefixed into view templates and macros so I must test these. Do you foresee any problems?
At the moment I personally would _not_ use this in TW ViewTemplate or tiddlers tagged with $:/tags/ViewTemplate .. it's too dangerous to "brick" the system.

I accept you guidance,  but if I thought of this others will, so we should suggest the best practice for reusing custom wiktext definitions such as import only.

Great work, thanks for your diligence.

TonyM

unread,
Sep 18, 2020, 7:41:34 AM9/18/20
to TiddlyWikiDev
Sorry,

Not sure what you mean here, but its intriguing.

Tony

TonyM

unread,
Sep 18, 2020, 7:45:12 AM9/18/20
to TiddlyWikiDev
Mario,

These answers of yours really are demonstrating the flexibility. We need some how to capture this knowledge, without making it too complex for users.

Tony

TonyM

unread,
Sep 18, 2020, 7:58:47 AM9/18/20
to TiddlyWikiDev
Mario,

I think this could be an independent solution. ANd alias may be away to go, but I am thinking more with a view to core one day, perhaps that's where a simplified alias should go as well?

Regards
Tony

PMario

unread,
Sep 18, 2020, 8:03:01 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 1:45:12 PM UTC+2, TonyM wrote:

These answers of yours really are demonstrating the flexibility. We need some how to capture this knowledge, without making it too complex for
users.

Yea, I try to build a "story" around the possibilities. ... I did try to start with the simple things. ... But if you have a look at the code of this tiddler: https://wikilabs.github.io/editions/tick-text/#test-high-abstraction

The Usage string is: ° » ´ › - -- --- ----

Which is close to insanity or close to Brainf*ck syntax and IMO doesn't make sense at all. ... BUT it was nice to see, that it works.

-m

TonyM

unread,
Sep 18, 2020, 8:05:44 AM9/18/20
to TiddlyWikiDev
All,

In the below it demonstrates how convention allows the Capital to be used, eg Big X refers to Close all
  • Close all works, but not copy to clipboard?
  • Again this shows how rather than write a macro you can use  _element="$widget" to simply code a shortcut for a button
    • I imaging this should work in lists with variable content as well?
  • My use here of the degree, may be a convention for customised wikitext buttons as an example, of my prior idea of preconfigure the behaviour, or at least set a de facto standard.

\customize degree=X _element="$button" message="tm-close-all-tiddlers"
\customize degree=C _element="$button" message="tm-copy-to-clipboard" param={{!!text}}

°X Close all  
°C copy content


Regards
Tony

PMario

unread,
Sep 18, 2020, 8:17:27 AM9/18/20
to tiddly...@googlegroups.com
On Friday, September 18, 2020 at 1:39:42 PM UTC+2, TonyM wrote:


Example (just a brainstorm) may be inaccurate as I learn still to memorise the existing, its just the concept. I am still to learn how some simple defaults will lend them self to each character. But publishing firs as just a larger set of symbols and no defaults my b fine with a view to giving them some defaults as we lean more about the scope and opportunities.
  •  ° degree use for emphasis 
In my examples I did use the degree ° ID to indicate functions that have been "imported"
  •  ´ to introduce styles
It was the first one, that worked after dot failed. So we are used to it.
  •  › dividers lines/headings 
I thought you would want them for CTRL-A - toggle button as a fast way to apply custom styles
and relatively nice way to read prose text.
  •  _ specials including html 
I think I could live with _ for "specials" like HTML tags. ... Will have a closer look.
  •  » Formatting blocks
I want to use it for simple paragraph formatting
  •  ≈ indicating state
This is a spare one at the moment. It also has 2 elements in the char. Which indicates \n\n as the default _endString

-------

°° some text°° is used at the moment for "\customizeinline" .. But only °°.class.c.lass is implemented atm°°

We will need to use it for awhile and then we can see, if we can identify some patterns ...

-m

TonyM

unread,
Sep 18, 2020, 8:18:47 AM9/18/20
to TiddlyWikiDev
In the new Google Groups I can edit an existing post :( again
Additional Content

\customize degree=x _element="$button" message="tm-close-tiddler"

°X Close all 
°x Close me
°C copy content

Again,
This use of X for All and x for here would be a suggested de facto standard to guide users (Which they can ignore)
But having some standards will open people eyes to the possibilities as well as encouraging some informal standards.

Tony

PMario

unread,
Sep 18, 2020, 8:22:43 AM9/18/20
to TiddlyWikiDev
Hi,

I think the following works well out of the box for me.

».hl several lines of paragraph text with
single line breaks
where onyl 1 indicator is needed

just a thought.
-m

PMario

unread,
Sep 18, 2020, 8:27:27 AM9/18/20
to TiddlyWikiDev
That's a nice example.

But what I wanted is a "partial" copy-to-clipboard, which isn't possible atm. The <$button> body </$button> is used to create the button-text instead of defining the text, that should be copied.

So the widget I'm imagining is more like this

<$clipboard buttonText="copy to clipboard" class="" showCode=yes/no showText=yes/no mode=block/inline template="name of a template tiddler">
Content, that is copied to the clipboard
</$clipboard>
just brainstorming
-m

PMario

unread,
Sep 18, 2020, 8:29:00 AM9/18/20
to TiddlyWikiDev
It would be used mainly for documentation purposes
-m

PMario

unread,
Sep 18, 2020, 8:33:33 AM9/18/20
to TiddlyWikiDev
On Friday, September 18, 2020 at 2:18:47 PM UTC+2, TonyM wrote:
In the new Google Groups I can edit an existing post :( again
Additional Content

In the below it demonstrates how convention allows the Capital to be used, eg Big X refers to Close all
  • Close all works, but not copy to clipboard?
  • Again this shows how rather than write a macro you can use  _element="$widget" to simply code a shortcut for a button
    • I imaging this should work in lists with variable content as well?
  • My use here of the degree, may be a convention for customised wikitext buttons as an example, of my prior idea of preconfigure the behaviour, or at least set a de facto standard.

\customize degree=X _element="$button" message="tm-close-all-tiddlers"
\customize degree=C _element="$button" message="tm-copy-to-clipboard" param={{!!text}}
\customize degree=x _element="$button" message="tm-close-tiddler"

°X Close all 
°x Close me
°C copy content

Again,
This use of X for All and x for here would be a suggested de facto standard to guide users (Which they can ignore)
But having some standards will open people eyes to the possibilities as well as encouraging some informal standards.

That's definitely something that should work as inline-text eg: If you click this °°x Close me°° button, this tiddler will be closed. So we can use working buttons within wikitext and still have readable prose text, that makes sense.

-m

TonyM

unread,
Sep 18, 2020, 9:44:48 AM9/18/20
to TiddlyWikiDev

Mario,


The Usage string is: ° » ´ › - -- --- ----

Lol

Actually finally we have a way to obfuscate! for good I mean, like hard to find strings. Or user or password details?

Regards
Tony

TonyM

unread,
Sep 18, 2020, 9:53:15 AM9/18/20
to TiddlyWikiDev
I need to clock Off, almost midnight here, Great work, 
The revolution is Brewing :)
Tony

TonyM

unread,
Sep 19, 2020, 7:12:12 PM9/19/20
to TiddlyWikiDev
Mario,

This idea is very powerful from a user perspective, but I have no idea how achievable technically, please give it some thought. 
  • If feasible it only needs the development of one new customise feature reference the content
  • My thought is a variable such as currentContent, idealy  $(currentContent)$ because then it is easy to concatinate
    • eg to="$:/prefix/$(currentContent)$"
  • This also raised the desire to access other variables in the pragma such as current tiddler / storyTiddler or any if possible.

I am experimenting with customise to try and toggle something. 
  • I realise that I would be useful if the content of the line could be referenced in the "pragma" 
Here is a simple example I have "fudged"
\customize degree="button" _element="$button" to="Content"
°button Content 
°button A Todo item 

I have set the to="Content" as if I could have the content of the line passed into the pragma. This navigates to a tiddler named "Content" however I would like the second "button" to navigate to " A Todo item"

Why?

I expect its obvious, The ability to create toggles and new buttons and a lot more such as state tiddlers/data indexes and much more would be possible by allowing the content of the line be a parameter to the customised mark-up.

For me this started with a desire to construct custom mark-up such as
°do An item I may have to do, quickly typed into a tiddler
  • Which could be used to generate a clickable item in the view template to indicate complete
Other possibilities
  • Click line
    • to flag that line/paragraph for subsequent processing
    • to create a tiddler by that title
    • to places that text in a data tiddler with next nth key
    • Turn text into a tag
    • to copy line to keyboard
  • Allowing footnotes to be created 
  • many more
Tony

TonyM

unread,
Sep 20, 2020, 12:02:43 AM9/20/20
to TiddlyWikiDev
Mario, Et al.

More review and research into the extensibility on top of  Version 0.4.1  

I just did this in a tiddler
\customize degree="button" _element="$button" mode="block"
\customize tick="kbd" _element="kbd" 

°button Content

´kbd This is > [[A List]] > of items
another

However I am confused the content button has the kbd result wrapped onto the same line but the word "other" seems to me to be more than one line below.

This continues to be a stumbling block, I am trying to commit to memory how to make use of the two cases \n and \n\n when customising.
  1. Such as customising something so it occurs until the end of line only, or until a blank line "\n\n" only 
  2. once I master this I need to work out how to have the result generated on the current line, and in other cases to end with a blank line
  3. Then I want to find how to apply things inline, like in a middle of a sentence.
  4. I am also well aware of the endString, but here I am looking for the line based customisations without having to specify an endString.
Perhaps its the 24 hour break I had, or Sunday laziness, but it could also be a lack of clarity either in the solution or in the documentation.

Would it be possible for you to write a short clarifying summary of the differences between these 4 items above please?
  • It seems to me this is a key area of the documentation

Thank in advance
Tony

PMario

unread,
Sep 20, 2020, 7:50:57 AM9/20/20
to TiddlyWikiDev
On Sunday, September 20, 2020 at 1:12:12 AM UTC+2, TonyM wrote:

This idea is very powerful from a user perspective, but I have no idea how achievable technically, please give it some thought. 
  • If feasible it only needs the development of one new customise feature reference the content
  • My thought is a variable such as currentContent, idealy  $(currentContent)$ because then it is easy to concatinate
    • eg to="$:/prefix/$(currentContent)$"
  • This also raised the desire to access other variables in the pragma such as current tiddler / storyTiddler or any if possible.
The \pragma command is evaluated at "parsing time". There are no variables. They are created at that time.



 
I am experimenting with customise to try and toggle something. 
  • I realise that I would be useful if the content of the line could be referenced in the "pragma" 
Here is a simple example I have "fudged"
\customize degree="button" _element="$button" to="Content"
°button Content 
°button A Todo item 

That's not the goal. ... Use \define and use macros for stuff like this. Don't try to use it that way it will and should never work. It will only create frustration.

The button widget is a "frankenstein" widget. If you want to customize it, it has to fail! ... There is a reason, why Jeremy created all the action widgets. ... Because the button widget can't cope with all the different usecases.

There is only 1 way, the <$button widget should be used also in standard TW. The existing parameters are there for compatibility, because we can't remove them.

<$button actions=<<actions>> >button text</buttons>

That's the __only__ way, that is available to customize it. ... That is one reason, why I wanted to create a new "copy-to-clipboard" widget. (Which I haven't atm)

Widgets that can be customized in full HAVE to be structured in the way as <$list ... The schema has to be like this:

<$widget-name param=value param=value param=value ... template=XXX >
content to be worked with.
</$widget-name>

OR

<$widget-name param=value param=value param=value >
< content used as template>
</$widget-name>
 
I have set the to="Content" as if I could have the content of the line passed into the pragma. This navigates to a tiddler named "Content" however I would like the second "button" to navigate to " A Todo item"

As I wrote. This will never work. If I would make the the \customize xxx to be able to work with a buttion I would create a "frankenstein \customize".

So the only way it can work is the button structure that I did describe.

I think (but not sure yet), the only way to solve this problem is a new XButton widget, that has a schema as described above.

It may look like this:
<$xbutton btn-text="click me" actions= template=XXX > content </$xButton> or

This should be fully customizable, in the way it should be.

I expect its obvious,

Yes it is, but at the moment _not_ all of the the existing widgets will allow us to customize them. They haven't been designed that way. Especially the really old ones, like the button-widget.
 
The ability to create toggles and new buttons and a lot more such as state tiddlers/data indexes and much more would be possible by allowing the content of the line be a parameter to the customised mark-up.

I'm not sure, it this should be the goal. We do have macros and "toggle buttons" and the like should be implemented that way ... and at the moment they have to!
 
For me this started with a desire to construct custom mark-up such as
°do An item I may have to do, quickly typed into a tiddler
  • Which could be used to generate a clickable item in the view template to indicate complete
I think this should be doable already. ... But I'm not sure. I'll need to test it.

I would go with: https://grosinger.net/tw5-checklist/ instead.

 
Other possibilities
  • Click line
    • to flag that line/paragraph for subsequent processing
    • to create a tiddler by that title
    • to places that text in a data tiddler with next nth key
There is a lot of logic in the line above. ... eg: nth key need some logic to be incremented / changed. We are at "parser time"!!!! Logic needs to be done at rendering time, which is way later.
    • Turn text into a tag
    • to copy line to keyboard
  • Allowing footnotes to be created 
  • many more

I can see, the desire. I did have it too. The plugin already has some code to "extract" the content between start: and _endString, for debugging purposes.

BUT at the moment it seems, the different existing widgets, do know more about their context as they should. .. EG. Your checkbox example.

°do - Some text

Should be doable already. _but_ it fails with a RSOD. ...

The <$checkbox widget creates a parsetree that is different, to mine. --> may be a bug in \customize

\customize degree=do _element="$checkbox" tiddler=<<qualify "state/">> tag=done

°do - Das ist ein Test


Should work .. but doesn't

-mario

PMario

unread,
Sep 20, 2020, 7:58:37 AM9/20/20
to TiddlyWikiDev
On Sunday, September 20, 2020 at 6:02:43 AM UTC+2, TonyM wrote:
Mario, Et al.

More review and research into the extensibility on top of  Version 0.4.1  

I just did this in a tiddler
\customize degree="button" _element="$button" mode="block"
\customize tick="kbd" _element="kbd" 

°button Content

As I wrote. Don't try to work with the button-widget in an other way as I suggested in the last reply. It won't work out.
 

´kbd This is > [[A List]] > of items
another

However I am confused the content button has the kbd result wrapped onto the same line but the word "other" seems to me to be more than one line below.

IMO that's a bug in the plugin... because of _element="$button"  ... _element="div" works as expected. I'll have to have a closer look.
 

This continues to be a stumbling block, I am trying to commit to memory how to make use of the two cases \n and \n\n when customising.
  1. Such as customising something so it occurs until the end of line only, or until a blank line "\n\n" only 
  2. once I master this I need to work out how to have the result generated on the current line, and in other cases to end with a blank line
  3. Then I want to find how to apply things inline, like in a middle of a sentence.
  4. I am also well aware of the endString, but here I am looking for the line based customisations without having to specify an endString.
Perhaps its the 24 hour break I had, or Sunday laziness, but it could also be a lack of clarity either in the solution or in the documentation.

No seems to be a bug. ...

-m

TonyM

unread,
Sep 21, 2020, 12:05:06 AM9/21/20
to TiddlyWikiDev
Mario,

Thanks for your responses. I built a macro for "active todo items" for the checkbox idea and more; below;

It is clear the processing of pragmas is a black box I cant see in. So thanks for being patient with my suggestions.
  • The following does work as a pure macro, it is simply to give an outline of how I though we may accommodate macros
  • I understand if it is technically impossible or difficult, no need to explain why if so.

I use the below macro as follows

In this example below the macro is called thus
<<☐ """This is a todo line""">>
<<☐  "This is another line">>

I expect it is too late in the rendering process; but it seems common sense (does not mean it is) that some pragma could read as such;
°☐ "This is a todo line"
parsed to
<<☐ "This is a todo line">> 
and thus call the macro 
In this case I am accepting if I wanted to pass other parameters to the macro the first, the content needs to be quoted.
Eg
°☐ "This is a todo line"  color:"blue"

In this case I am using the customise simply as a shortcut. Which is easier to read. An editor toolbar would wrap lines with prefix "°☐ "suffix ""
The pragma would wrap it with prefix "<<symbol " suffix ">>"

This is not finished, I plan to reduce line spacing between items, allow text and possibly more, to be edited inline.


Regards
Tony

The macro(s) just for completeness
\define done-check(tiddlername)
\whitespace trim
<$set name=tiddlername value="""$tiddlername$""" emptyValue=<<currentTiddler>> >
<$list filter="[<tiddlername>!done[yes]!done[cancel]]">
<$button tooltip="click to indicate done" class="tc-btn-invisible">
<$action-setfield $tiddler=<<tiddlername>> done="yes"/>
☐&nbsp;$(content)$
</$button>
</$list>
<$list filter="[<tiddlername>has[title]done[yes]]">
<$button tooltip="click to cancel or reset" class="tc-btn-invisible">
<$action-setfield $tiddler=<<tiddlername>> done="cancel"/>
☑&nbsp;$(content)$
</$button>
</$list>
<$list filter="[<tiddlername>has[title]done[cancel]]">
<$button tooltip="click to reset"  class="tc-btn-invisible">
<$action-setfield $tiddler=<<tiddlername>> done="no"/>
☒&nbsp;$(content)$
</$button>
</$list>
</$set>
\end
\define ☐(content)
\whitespace trim
<$set name=todo-tiddler value="""$:/todo/$(currentTiddler)$/$content$""">
<$set name=content value="""$content$""">
<$tiddler tiddler=<<todo-tiddler>> >
<$button tooltip="This is marked as a todo item, click to change status">
<$macrocall $name=done-check/>
</$button>
<$list filter="[all[current]has[text]]">
&nbsp;{{||$:/core/ui/Buttons/edit}}
</$list>
</$tiddler>
</$set></$set>
\end

@TiddlyTweeter

unread,
Sep 21, 2020, 4:54:48 AM9/21/20
to TiddlyWikiDev
Ciao PMario

I had an example Use Case to show but things changed so much in your tool I'm revising it. Hopefully I have time soon.

I think, over-all, your approach is really good. It is somehow managing to balance existing TW coding with extensions AND innovations well.

I can see it got complex. Only a good programmer could do what you are doing.

I note your comment on buttons. Right.

I also read the detail on discussion of using it for macros. I'm slightly nervous about that. 
The GAINS on HTML insertion and CSS styling are very substantial. I would not want handling macros to confuse the basic need to expand easy invoke of HTML & CSS.

I do have issues with INLINE markup (°) in that there is no way to nest at the moment. It is also "verbose" having to do °°match°°.

I will try give you at least one example use case ASAP to illustrate some issues that came up for me, as well as success.

Best wishes
TT

@TiddlyTweeter

unread,
Sep 21, 2020, 5:18:41 AM9/21/20
to TiddlyWikiDev
PMario

Regarding B*F matching on closure. 

I think its fine you COULD do it (might be needed in some off-beat use cases). Just don't document those :-).

TBH closing "»" a default of "«" looks good to me.

TT

PMario

unread,
Sep 21, 2020, 5:53:59 AM9/21/20
to TiddlyWikiDev
On Monday, September 21, 2020 at 10:54:48 AM UTC+2, @TiddlyTweeter wrote:

I had an example Use Case to show but things changed so much in your tool I'm revising it. Hopefully I have time soon.

Yea, It was alpha as we started. It is beta now. So I think we settled on the naming conventions.
 
I note your comment on buttons. Right.

I also read the detail on discussion of using it for macros. I'm slightly nervous about that. 
The GAINS on HTML insertion and CSS styling are very substantial. I would not want handling macros to confuse the basic need to expand easy invoke of HTML & CSS.

The existing widgets haven't been designed with our usecase in mind. Especially the button widget is a "monster". It has way too many different usecases and way to many parameters. Some of them are used, some of them don't. .. Depending on the usecase. ... That's why the action-widgets have been invented. .. They do _only 1 thing well_

There was a bug in the code, that made it impossible to handle widget parameters in the right way. I fixed it, and will publish it soon.
 
I do have issues with INLINE markup (°) in that there is no way to nest at the moment. It is also "verbose" having to do °°match°°.

Yea, Inline needs more love. It's the basic function only. similar to @@match@@ So we don't win anything yet. Nesting like:

°° xxxx °° yyyy °° zzz °° will never be possible. since the TW parser doesn't work that way with inlines. There is the _need_ to have a uniquely identifiable endstring. So the \customizeinline will need an _endString param to make nesting possible. 

-mario

@TiddlyTweeter

unread,
Sep 21, 2020, 6:11:19 AM9/21/20
to TiddlyWikiDev
@TiddlyTweeter wrote:

I do have issues with INLINE markup (°) in that there is no way to nest at the moment. It is also "verbose" having to do °°match°°.


PMario wrote: 
Yea, Inline needs more love. It's the basic function only. similar to @@match@@ So we don't win anything yet.

Right. No advantage. It largely repeats what we have already.
 
There is the _need_ to have a uniquely identifiable endstring. So the \customizeinline will need an _endString param to make nesting possible. 

Noted. I will comment on that, I hope, in an example to help clarify some use cases.

Best wishes
TT

TonyM

unread,
Sep 21, 2020, 8:15:55 AM9/21/20
to TiddlyWikiDev
Mario,

The need for an endString, although may be valid in other use cases is a good way to recognise when a multi-line block or inline text is in use, rather than the line based approach. Many of the current wiki text is line based.

It seems to me that making use of a method like °/.classname something here  /° or 
°/.classname 
something here  

and/or
Start of line °/id.classname something here  /°  end of line.

The key being you can see which opens and which closes, ie its asymmetric yet palindromic.

But if course, since unfortunately the mechanism's you are using are unknown to me, I leave the feasibility to you.

If you were looking for a point at which to publish an initial release, perhaps this could be the dividing line, between the first and second release. As long as nothing in the first release compromised later inline annotations, it does not all have to be solved at once.  I certainly think that the matching CSS and other interesting applications of the customise pragma can come from the community. Perhaps a challenge for the most impressive applications and their subsequent documentation would be a way to get feedback, doco etc...

In the mean time, best rest assured I continue to exercise your latest releases, and If I am truthful, primarily trying to test its limits. Trying to do things that until now has either being impossible or long winded.

As an aside I am working on leveraging macros and transclusions to complement opportunities to authorship along side the customize pragma.

Regards
Tony

PMario

unread,
Sep 21, 2020, 9:21:22 AM9/21/20
to TiddlyWikiDev
Hi Tony,

I did find a bug, that made it impossible to use \customize _element="$xxx"  properly. ... There was a problem with the parameter parsing. It will  be fixed with the next version.

I did also have a look, which widgets can be customized. .. It seems all of them should work. But I'm not sure, if that's really needed.

I'm not sure, if can fix the "macro" problem with the "content" parameter.

-mario

PMario

unread,
Sep 21, 2020, 11:23:47 AM9/21/20
to TiddlyWikiDev
On Monday, September 21, 2020 at 6:05:06 AM UTC+2, TonyM wrote:

I expect it is too late in the rendering process; but it seems common sense (does not mean it is) that some pragma could read as such;
°☐ "This is a todo line"

This will work with V0.5.1!

There was a bug in my praser _and_ the widget call didn't set the "src/content" variable. If _element is set to $widget now, the _srcName, which defaults to "src", will be used to set the variable to the content text.
eg:

\customize degree=do _element="$macrocall" $name=☐ _srcName=content

If you would use "src" instead of "content" you could skip this parameter

and thus call the macro 
In this case I am accepting if I wanted to pass other parameters to the macro the first, the content needs to be quoted.
Eg
°☐ "This is a todo line"  color:"blue"

At the moment this will not happen. It would be almost the same as a macro call like

<<☐ "This is a todo line" color:"blue">>

For me it doesn't make sense to make custom markup plugin even more complex, to solve something that is already solved.

To make the macrocall work, it needed the bugfix and 5 lines of new code. To read macro parameters, I would need to add the macro parameter parser. If you need to add _params you can use: °.class + CSS definitions. eg:

\customize degree= _params=".cb" _element="$macrocall" $name=☐

° This is a todo line

I'm pretty sure this can do what you want.

-mario

PMario

unread,
Sep 21, 2020, 11:31:40 AM9/21/20
to TiddlyWikiDev
On Monday, September 21, 2020 at 6:05:06 AM UTC+2, TonyM wrote:

The macro(s) just for completeness
\define done-check(tiddlername)
\whitespace trim
<$set name=tiddlername value="""$tiddlername$""" emptyValue=<<currentTiddler>> >
<$list filter="[<tiddlername>!done[yes]!done[cancel]]">
<$button tooltip="click to indicate done" class="tc-btn-invisible">
[...]
<$set name=todo-tiddler value="""$:/todo/$(currentTiddler)$/$content$""">

The main problem I have with this code is, the line above. If you rename the tiddler title, or the $content$ text, your ToDo-state will be gone.

So there needs to be a way to make the "state name" 100% predictable and unchangeable. ... I don't have a solution for this

-m


PMario

unread,
Sep 21, 2020, 11:34:06 AM9/21/20
to TiddlyWikiDev
On Monday, September 21, 2020 at 10:54:48 AM UTC+2, @TiddlyTweeter wrote:
...
I also read the detail on discussion of using it for macros. I'm slightly nervous about that. 
The GAINS on HTML insertion and CSS styling are very substantial. I would not want handling macros to confuse the basic need to expand easy invoke of HTML & CSS.

We can customize the $macrocall widget now. Which should be flexible enough. .. It has to ;)

-m

@TiddlyTweeter

unread,
Sep 21, 2020, 12:06:56 PM9/21/20
to TiddlyWikiDev
The more I hear about "macros" in this the worse I feel.

I don't care if the device lets you skip over the moon. I DO care that mortals can understand it. OR totally avoid it.

IMO "macro use" within this tool is a highly advanced feature. I am very UNCLEAR of the added value.

I need examples to see the added value!!!

Best wishes
TT

@TiddlyTweeter

unread,
Sep 21, 2020, 12:13:28 PM9/21/20
to TiddlyWikiDev
The checklist example TonyM gave I don't think adds anything that does not exist already.

As PMario implied before, the Grossinger plugin IS using markup intelligently to deliver live.

Dimmi (tell me) the added value, please!

Regards
TT

PMario

unread,
Sep 21, 2020, 1:12:37 PM9/21/20
to TiddlyWikiDev
Hi


V0.5.1

@ Tony your "macro" call works now. And there is a new _srcName parameter.

Mario

PMario

unread,
Sep 21, 2020, 1:20:37 PM9/21/20
to TiddlyWikiDev
On Monday, September 21, 2020 at 6:06:56 PM UTC+2, @TiddlyTweeter wrote:
The more I hear about "macros" in this the worse I feel.

Why? ... It works now, which is a big win.
 
I don't care if the device lets you skip over the moon. I DO care that mortals can understand it. OR totally avoid it.

If you don't need it, don't use it. ... The problem was, that the implementation had a bug, that's why something which should have worked .. didn't. That was confusing for Tony.
 
IMO "macro use" within this tool is a highly advanced feature. I am very UNCLEAR of the added value.

It has the same value as "abstracting" widgets. For some "special" usecases it will be possible to use wikitext to activate all kind of UIs, without the need of "alien" widget names.

I need examples to see the added value!!!

There are a lot of test-xxx tiddlers, where I do test the code and the TOC contains the beginning of the docs.

-m

PMario

unread,
Sep 21, 2020, 1:25:51 PM9/21/20
to tiddly...@googlegroups.com
On Monday, September 21, 2020 at 6:13:28 PM UTC+2, @TiddlyTweeter wrote:
The checklist example TonyM gave I don't think adds anything that does not exist already.

As PMario implied before, the Grossinger plugin IS using markup intelligently to deliver live.

Dimmi (tell me) the added value, please!

I think he's testing the possibilities. There is a lot of trial and error, to see, what works and what doesn't. 

I did see some value in the abstraction of simple presentations. Where the text looks like this:

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


But it activates the reveal.js plugin. The text that would have been used is:

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

I think it depends on the users taste, what they like more

-mario

PMario

unread,
Sep 21, 2020, 1:34:24 PM9/21/20
to TiddlyWikiDev
@Tony,

If you drag & drop import the WikiLabs Plugin Configuration tiddler into your wiki, you can update with the default TW plugin update workflow.

-mario

@TiddlyTweeter

unread,
Sep 21, 2020, 1:42:38 PM9/21/20
to TiddlyWikiDev
PMario wrote:
@TiddlyTweeter wrote:
The more I hear about "macros" in this the worse I feel.

Why? ... It works now, which is a big win.

Right. More power to you.

BUT are we seeing a version of Advanced Yoga (bloke was able to twist his leg behind his head)?

My concern is it will confuse adding macros. Let's see. The issue is you will have to find a way to document BOTH major layout change AND the indefinable scope of macros (not all though) elegantly.
I'm concerned its getting too complicated. BUT let us see.

TT

PMario

unread,
Sep 21, 2020, 2:19:31 PM9/21/20
to tiddly...@googlegroups.com
On Monday, September 21, 2020 at 7:42:38 PM UTC+2, @TiddlyTweeter wrote:

BUT are we seeing a version of Advanced Yoga (bloke was able to twist his leg behind his head)?

Probably yes. ...
 
My concern is it will confuse adding macros. Let's see.


With TW5 Jeremy invented the widgets. Widgets are more complicated to use than macros. ... BUT they are more powerful, since they expose all parameters, that can be used.

On the other hand, the learning curve is much steeper with widgets. eg: Let's have a closer look at the

<<list-links filter:"[tag[HelloThere]]">> macro call. .. It's simple and does a decent job. Right?

The usecase above is the most common.
But in reality the macro has a lot more parameters: filter, type, subtype, class and emptyMessage.

So if you want to use all params it looks like this:

<<list-links filter:"[tag[HelloThere]]" type:"ol" subtype:"li" class:"test" emtpyMessage:"Nothing found!">>

Which is already more complicated. ... But still much easier as the real code.


\define list-links(filter,type:"ul",subtype:"li",class:"",emptyMessage)
\whitespace trim
<$type$ class="$class$">
<$list filter="$filter$" emptyMessage=<<__emptyMessage__>>>
<$subtype$>
<$link to={{!!title}}>
<$transclude field="caption">
<$view field="title"/>
</$transclude>
</$link>
</$subtype$>
</$list>
</$type$>
\end

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

The problem now is, that if you _have_ to use a macro like this, it already has the potential to confuse readers.

<<list-links filter:"[tag[HelloThere]]" type:"ol" class:"iNeedIt" emtpyMessage:"Nothing found!">>

With custom-markup plugin we can reduce this to:

\importcustom [[customOrderedList]]

°orderedList [tag[HelloThere]]

So the only thing the user has to see is the above 2 lines. ... And if the "names" are chosen in the right way it shouldn't need more explanation.

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

The content of "customOrderedList" is a bit tricky but that's not, what the user has to see:

\customize degree="orderedList" _element="$macrocall" $name="list-links" type="ol" class="iNeedIt" emptyMessage="Nothing found!" _srcName=filter

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

With definitions like this, it's possible to create new wikitext commands, that would be much more complicated to read. .... Well -- you could clone the "list-links" macro and change it in the way you need it. ... BUT then you also have to maintain it. ...

And users are really hesitant to change the core. May be custom-markup is a way to go. We will see!
 
The issue is you will have to find a way to document BOTH major layout change AND the indefinable scope of macros (not all though) elegantly.
I'm concerned its getting too complicated. BUT let us see.

That's right.

-mario

TonyM

unread,
Sep 21, 2020, 7:31:33 PM9/21/20
to TiddlyWikiDev
TT,

I understand your concern, its correct to raise it. I think you need a explanation from me who is pushing this capacity, is warranted.
  • What I am doing is pushing the solution to its logical conclusions, not to necessarily expand the features (although that is good), but explore its consequences.
  •  We are not offering macros here, we are offering customised wiki text. If we keep its documentation clear and concise it will be written in a systematic way.
    • The result of a concise systematic solution will be designers will abstract and experiment. I am running down these paths to test the validity.
      • I am also doing this for issues that I perceive to be existing limitations, 
    • By voicing these Mario looks at the "what if's", now if he discovers with a tweak they can be made to work, we do not need to document exceptions, exceptions make a solution more complex
    • To me to exclude macros, perhaps even transclusions (not raised yet) will actually add exceptions and complicate the solution.
    • users and designers bring with them a complex set of assumptions.
  • We may need to document some warnings, what are the warnings if we do not discover them?
  • This solution is by its nature is handed to us by our Yogic teacher, the Yoggy is empowering us to explore all the branches of our being. 
Not withstanding this desire, "not to limit" the possibilities (unless identified as necessary)
  • I expect customised wiki text is going to be a method to an end, basically with small group of designer and users actually writing customise pragmas for themselves
    • A common use may be just the defaults
  • I expect for example a writers wiki to be designed, with this plugin and a set of prepared customisations to be included.
    • The writer's wiki will not document the customisation plugin so much, but the resultant set of custom markup that the writer will use.
    • That is, there will often be an abstraction layer introduced, between the specific implementation and the customise pragma.
  • If however if someone goes down the customise pragma writing themselves, the more they can leverage this commitment to a sophisticated solution, and the more they will care about the capabilities.
In short, the use of the customise pragma will be as complex as the user wishes to make it. As is already the case for standard wiki text.

Regards
Tony

Mat

unread,
Sep 22, 2020, 6:04:52 AM9/22/20
to TiddlyWikiDev
I'm unfortunately swamped with work, thus my absence here. Sorry for that.

However, as part of my work I found a use case that I figured is worth reporting because it should be a rather common one:

I have to go through several books and in doing so I take out notes and quotes. I want to refer to these snips by the page they can be found at. It is common practice to refer to a page using the abbreviation "p." or "pp." (not sure what pp stands for?).

It would thus be convenient if one can someone use this for the markup. I'm not sure about the latest developments here but the natural way to document such snips would be either of e.g:

pp30 Subsequent text
p30 Subsequent text
pp.30 Subsequent text
p.30 Subsequent text

- or for multiple pages -

pp30-35 Subsequent text
p30-35 Subsequent text
...etc

The "output" needs to display the Subsequent text but also the page number/s. 

Maybe the current implementation in this thread is spot on, I don't know because I have lost track (again, sorry). I'm just reporting this because it is a use case we can expect. Because it is note-taking, it has to be really smooth and minimally distracting to make the actual note.

(Some may argue that such snips ought to be individual tiddlers. Not only is that another discussion so let's not get in to it - but the (native) UI for creating individual tiddlers is definitely not smooth enough for live note taking.)

OK, just a report from IRL.

<:-)

TonyM

unread,
Sep 22, 2020, 6:11:10 AM9/22/20
to TiddlyWikiDev
Mat,

Can you give me a quick sample of what details you will give and how you want it to appear.

For the minute a macro seems the best.

Regards
Tony

Mat

unread,
Sep 22, 2020, 7:04:37 AM9/22/20
to TiddlyWikiDev
Thanks for reply Tony. OK, so there are actually some more nuances and bits but what I noted above is a "base case":

Here is the most simple example from my own notes. It is an arbitrary snip from a tiddler named "The Thomas Sowell Reader, Sowell" :

pp336 When people put up dogmatic ideas, ask "Suppose you are wrong? How would you know? How would you test for that possibility?"

The quoted part is from the book but the preceding explanation are my own words. Because they're just my private notes, I can mistreat quotes freely, but I typically still want to separate the original from my own meta notes. Obviously, academic papers or public work would require separating original quotes and personal notes properly. When I add my fully own thoughts (e.g a conclusion) I sometimes add a prefixing "mg:" (my initials).

Another variant when there are several snip/notes from one page and the "pp" is used as a heading. Here I'm using a definition list to show how I currently do it with native TW:

;pp338
:When people put up dogmatic ideas, ask "Suppose you are wrong? How would you know? How would you test for that possibility?".
:...campaings for a longer school day are farcical. If a lack of time is the problem, why are schools wasting so much time on innumerable non-academic activities?

A problem here is that it is not clear if the last sentence is a quote or something from me. In reality I write my thoughts in Swedish (and most of my book sources are in English) so this is rarely a problem. But/and if I'm note-taking from a Swedish source, I'm unstructured and sometimes use quotation marks, sometime add my "mg" prefix, sometimes add a new line, etc. Kinda' depends. On mood, I guess. Or lack of having thought it through and established a best practice.

Regardless of all, it has to be simple. The simplest solution that TW already has is probably:

;.pp 338 Lorem ipsum

this could be a defined style. Maybe the first word, i.e the 338 could be styled but there is no :first-word pseudo element (!). That'd be useful (here's supposedly a solution).

;.pp 338 is decent but it is definitely more intricate/errorprone to type than pp338 so it is not optimal.


OK, hope this clarifies a bit. Thanks.

<:-)

Mat

unread,
Sep 22, 2020, 7:07:48 AM9/22/20
to TiddlyWikiDev
TonyM wrote:
For the minute a macro seems the best.

Sorry, missed this point.
The problem with a macro is that it is too finicky to use for quick note taking. It demands too many characters.

<<pp 338 """.............""">> 

<:-)

PMario

unread,
Sep 22, 2020, 7:37:29 AM9/22/20
to TiddlyWikiDev
On Tuesday, September 22, 2020 at 12:04:52 PM UTC+2, Mat wrote:
I'm unfortunately swamped with work, thus my absence here. Sorry for that.

no problem.

I have to go through several books and in doing so I take out notes and quotes. I want to refer to these snips by the page they can be found at. It is common practice to refer to a page using the abbreviation "p." or "pp." (not sure what pp stands for?).

I think it is:

p .. page
pp ... pages eg: pp30 page 30 and the following
 
-m

PMario

unread,
Sep 22, 2020, 8:20:08 AM9/22/20
to TiddlyWikiDev
Hi Mat,

I think it can be done in a similar way to the html DETAILS element.

I'd go with something similar to this: BUT the <style> section should be in a separate CSS tiddler

\customize angel="note" _element="div" _params=".note.notop.cbox.cbox-primary.hard-linebreaks"  open _mode=block _endString="------"
\customize tick="page" _params=".margin-init.page"

<style>
.note p {
  margin-left: 1rem;
}

.page,
.page .tc-tiddlylink {
  font-weight: 600;
}
</style>

»note ´page [[book]] 30-5
some text öalsdjf sdjfösj döfsad
a sfsadföl sjadfjsöadf
aö skfjsaödfsa
------

more text

There is still a bug in the _end-hadling with \n\n .. So the ------ shouldn't be possible in the future.

-mario

PMario

unread,
Sep 22, 2020, 8:21:36 AM9/22/20
to TiddlyWikiDev
On Tuesday, September 22, 2020 at 2:20:08 PM UTC+2, PMario wrote:


»note ´page [[book]] 1-5
your comment!
------

You can define a stamp of the above text to be quicker.

Just some thoughts.

-mario

PMario

unread,
Sep 22, 2020, 8:23:26 AM9/22/20
to TiddlyWikiDev
Hi,

If you have some text from the book, ASIDE would be an option too. 


So your comments can be the aside element.

-mario

@TiddlyTweeter

unread,
Sep 22, 2020, 2:14:40 PM9/22/20
to TiddlyWikiDev
Ciao PMario

I been working on a sample case for you to see later.

One issue came up is related to the complexity of some the \cstomize rules. 
Basically the need, ideally, to be able to add COMMENTS so the author can note what they are doing ... 

Lets take this as an example...

PMario wrote
 The content of "customOrderedList" is a bit tricky but that's not, what the user has to see:

\customize degree="orderedList" _element="$macrocall" $name="list-links" type="ol" class="iNeedIt" emptyMessage="Nothing found!" _srcName=filter

... done like this ...

\customize degree="orderedList" /* MAIN framework, project 9 */

_element
="$macrocall" $name="list-links" type="ol" class="iNeedIt" emptyMessage="Nothing found!" _srcName=filter


... or this ...

\customize degree="orderedList" _element="$macrocall" $name="list-links" type="ol"
class="-v-p9" // NOTE project 9 must have this
emptyMessage
="Nothing found!" _srcName=filter

You get the idea?

Would something like that be possible? 

I find TW macros & rules frustrating to comment well when you need to. I was wondering if "customize" could address that issue?

Best wishes
TT


 

Mat

unread,
Sep 22, 2020, 2:46:25 PM9/22/20
to TiddlyWikiDev
PMario - thanks for replies. Some questions and thoughts:

So, if the CSS is defined elsewhere, do I understand it right that the user has to insert the following bit in every tiddler that he wants to make such styled notes in?

\customize angel="note" _element="div" _params=".note.notop.cbox.cbox-primary.hard-linebreaks"  open _mode=block _endString="------"
\customize tick="page" _params=".margin-init.page"

For real world I think this needs to be a template of some kind. E.g any tiddler tagged "book" has this automatically applied, i.e triggered via someting intuitive that the user probably already does (e.g tag). It is unrealistic to think that a user would manually add this even via a stamp unless he is totally into it and working with a dedicated book-note-taking wiki. The wiki user who occasionally wants to make a "book notes tiddler" would otherwise need to dig this out, which it just unlikely IMO. Or do I misunderstand something?

»note ´page [[book]] 30-5

How is the above to be interpreted? Style it with "note", yes, but then there's also "page" style? But [[book]] 30-5 are "headlines" seen in the text, right?

Thanks

<:-) 

PMario

unread,
Sep 22, 2020, 3:12:11 PM9/22/20
to TiddlyWikiDev
On Tuesday, September 22, 2020 at 8:46:25 PM UTC+2, Mat wrote:
So, if the CSS is defined elsewhere, do I understand it right that the user has to insert the following bit in every tiddler that he wants to make such styled notes in?

 
For real world I think this needs to be a template of some kind.

\importcustom can use filter syntax to import pragmas only from several tiddlers eg: [tag[basic-pragmas]] ...
 
E.g any tiddler tagged "book" has this automatically applied, i.e triggered via someting intuitive that the user probably already does (e.g tag). It is unrealistic to think that a user would manually add this even via a stamp unless he is totally into it and working with a dedicated book-note-taking wiki. The wiki user who occasionally wants to make a "book notes tiddler" would otherwise need to dig this out, which it just unlikely IMO. Or do I misunderstand something?

At the moment it's not possible to make pragmas global.

»note ´page [[book]] 30-5

How is the above to be interpreted?


Your question will be answered at Reference: https://wikilabs.github.io/editions/custom-markup/#Custom%20Markup%20Definition and Advanced

Style it with "note", yes, but then there's also "page" style? But [[book]] 30-5 are "headlines" seen in the text, right?

angel » is the ID. "note" is the <userSymbol> the class definitions are defined in _params

-mario

TonyM

unread,
Sep 23, 2020, 2:46:08 AM9/23/20
to TiddlyWikiDev
Folks,

A little experimental fun;

This method uses the vars widget to pre-define a set of variables for use inside the custom markup. As in this examples we have all out standard address details using well known names. You choose which to use and how to arrange them. Of course the variable are only available inside the vars

\customize tick=address _element="$vars" address="N Blah St Randwick" name="Anthony Muscio" phone="612 4075581847" email="to...@virtual.com"

´address  Here we use <<name>> <<phone>> <<address>>
´address  Here we use <<name>><br>Phone: <<phone>><br><<address>>



The following shows how the list widget with a pre-set filter can be used to choose if the content is to be displayed or not, emptyMessage can be used as well.
\customize tick=debug _element="$list" filter="[all[current]has:field[debug]]"
\customize tick=design _element="$list" filter="[{$:/config/design-mode}match[yes]]"
\customize tick=draft _element="$list" filter="[all[current]has:field[draft.of]]"

´debug  Debug: in <<currentTiddler>><br>Transclusion=<<transclusion>>
´design Show only when global design mode is set. to yes

´draft `Show only when Tiddler is in draft mode`



This also triggers me to ask Mario
  • How do I get a new line, but not double, newline to be used in the result(s)?
    • Was it a specific Character?
  • Would it be costly to have an alias to \customize of \customise? For me this is a common error.
As expressed earlier, I would so love to pass the filter to a customized list definition.

Here we simply use list to access a canned list of tiddlers defined by a filter
\customize tick=toc _element="$list" filter="[tag[toc]]"

´toc <<currentTiddler>><br>

´toc <$link/><br>

´toc <$transclude/><br>
Notice how common wiki text is all you need that refers to currentTiddler?
  • Empty message can also be used in the customise.
In this case you can test is the current tiddler, or a named tiddler is a member of the canned filter
\customize tick=toc _element="$list" filter="[tag[toc]]"  

´toc <$text text={{{ [all[current]match[Basics]then[Matches Basics]] }}}/><br>

´toc <$text text={{{ [all[current]match<storyTiddler>then[In TOC list]else[]trim[]] }}}/>
- however this second one produces empty lines.

Tony

On Wednesday, 16 September 2020 20:22:05 UTC+10, PMario wrote:
Hi folks,

This is the continuation of Custom markup [1] and Custom markup (continued) [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

V 0.4.0 https://wikilabs.github.io/editions/tick-text

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

TonyM

unread,
Sep 23, 2020, 4:49:18 AM9/23/20
to TiddlyWikiDev
Mario and Folks,

This example not only shows that the customise pragma can be used to store a canned filter for reuse, but also shows how the first in a nested list can be concealed behind a helpful name like system-shadows 
\customize tick=system-shadows _element="$list" filter="[all[shadows]is[system]]"

´system-shadows <$list filter="[all[current]has[caption]] +[!is[blank]]">{{!!title}} {{!!caption}}<br></$list>

I am confident with Mario's nesting method a simple line could define a set of nested lists with the content of the line equal to each final record.
If named well the variable set for each nested level will make the wiki text look like some 4th Generation reporting languages.

'customers `country `state {{{ [all[current]size[large]] }}} Automatic end string for each on \n?
But in this example I think the last filter here, on the line, needs to be in a list because otherwise it generates unnecessary line breaks
This is approaching simpler than SQL
  • Of course if somehow we can pass the filter to each nested level, not only would canned filters be used.
  • However if one has structured data in a wiki it would be simple to create the set of canned filters for handling the structured content in the wiki.
    • For users of a wiki (rather than owner designers) it may be simple to provide them the info they need to generate any list or report
    • Especially with some useful templates.
In the following case we use a list template
\customize tick=all-tiddlers _element="$list" filter="[is[tiddler]!is[system]]" template="$:/core/ui/ListItemTemplate"

´all-tiddlers This does nothing so can describe it
This is another case where passing the template value may be helpful

I am working on a better way to name templates/transclusions so the above could read
\customize tick=all-customers _element="$list" filter="[is[tiddler]!is[system]object-type[customer]!archive[yes]]" template="(customer-record)"

´all-customers List all customer-records

By the way, If the List widget was to contain two new parameters before and after, that could provide header and footer content, Only if there were content, this would expand further, allowing content and or table headers. I miss foreachtiddler still :(

Posting now, in the mean time I am working on customised standard filtered lists
\customize tick=all-tiddlers _element="$list" filter="[is[tiddler]!is[system]]" 
\customize tick=all-plugins _element="$list" filter="[plugin-type[plugin]]" 
\customize tick=recent _element="$list" filter="[haschanged[]]" 
\customize tick=open _element="$list" filter="[list[$:/StoryList]]" 
\customize tick=draft _element="$list" filter="[all[]has[draft.of]]"
\customize tick=closed-draft _element="$list" filter="[all[]has[draft.of]] -[list[$:/StoryList]]" ???
\customize tick=unsaved _element="$list" filter="[haschanged[]] -[prefix[$:/temp]] -[prefix[$:/state]] -[[$:/HistoryList]] -[[$:/StoryList]]"
\customize tick=missing _element="$list" filter="[all[missing]sort[title]]" 
\define note() Below for current tiddler
\customize tick=subtiddlers _element="$list" filter="[prefix<currentTiddler>] -[<currentTiddler>]"
\customize tick=tagging _element="$list" filter="[tag<currentTiddler>]"
\customize tick=children _element="$list" filter="[parent<currentTiddler>]"


And the last one children has set me of on a one and many to many relationship solution
* now that what TocP is no longer magical to me :)


Regards
Tony

On Wednesday, 16 September 2020 20:22:05 UTC+10, PMario wrote:
Hi folks,

\customize tick=tagging _element="$list" filter="[tag<currentTiddler>]"

On Wednesday, 16 September 2020 20:22:05 UTC+10, PMario wrote:
Hi folks,

PMario

unread,
Sep 23, 2020, 5:44:37 AM9/23/20
to TiddlyWikiDev
On Wednesday, September 23, 2020 at 8:46:08 AM UTC+2, TonyM wrote:

A little experimental fun;

:)
 
This method uses the vars widget to pre-define a set of variables for use inside the custom markup. As in this examples we have all out standard address details using well known names. You choose which to use and how to arrange them. Of course the variable are only available inside the vars

\customize tick=address _element="$vars" address="N Blah St Randwick" name="Anthony Muscio" phone="612 4075581847" email="to...@virtual.com"

´address  Here we use <<name>> <<phone>> <<address>>
´address  Here we use <<name>><br>Phone: <<phone>><br><<address>>


Nice idea! I like it. 

The following shows how the list widget with a pre-set filter can be used to choose if the content is to be displayed or not, emptyMessage can be used as well.
\customize tick=debug _element="$list" filter="[all[current]has:field[debug]]"
\customize tick=design _element="$list" filter="[{$:/config/design-mode}match[yes]]"
\customize tick=draft _element="$list" filter="[all[current]has:field[draft.of]]"

´debug  Debug: in <<currentTiddler>><br>Transclusion=<<transclusion>>
´design Show only when global design mode is set. to yes

´draft `Show only when Tiddler is in draft mode`


Very interesting. I didn't think about that use case
 
This also triggers me to ask Mario
  • How do I get a new line, but not double, newline to be used in the result(s)?
    • Was it a specific Character?
The space-space-enter plugin is installed on the page. So you can use either space-space-enter or space-space-backslash  \
at the end of the line, to create a newline.

But playing with your examples and newline .. I think, there is still a bug with \n and \n\n and whitespace handling. Will have a closer look.
 
  • Would it be costly to have an alias to \customize of \customise? For me this is a common error.
Very ;) ... No, it should be simple.
 
As expressed earlier, I would so love to pass the filter to a customized list definition.

Here we simply use list to access a canned list of tiddlers defined by a filter
\customize tick=toc _element="$list" filter="[tag[toc]]"

´toc <<currentTiddler>><br>

´toc <$link/><br>

´toc <$transclude/><br>
Notice how common wiki text is all you need that refers to currentTiddler?

There is a new parameter: _srcName ... use this:

\customize tick=list-a _element="$list"  template="currentTiddler-template" _srcName=filter
\customize tick=
list-b _element="$list"  template="link-template" _srcName=filter
\customize tick=
list-c _element="$list"  template="transclude-template" _srcName=filter

´
list-a [tag[toc]]

´
list-b [tag[toc]]

´
list-c [tag[toc]]

The *-template tiddlers use: <<currentTiddler>>  \   and  <$link/>    and   <$transclude mode=block/>  
as their content.

  • Empty message can also be used in the customise.
In this case you can test is the current tiddler, or a named tiddler is a member of the canned filter
\customize tick=toc _element="$list" filter="[tag[toc]]"  

´toc <$text text={{{ [all[current]match[Basics]then[Matches Basics]] }}}/><br>

´toc <$text text={{{ [all[current]match<storyTiddler>then[In TOC list]else[]trim[]] }}}/>
- however this second one produces empty lines.

Nice experiments.

I'd like to ad them as test-xxx to the published version. Is that OK?

have fun!
mario

PMario

unread,
Sep 23, 2020, 6:04:00 AM9/23/20
to TiddlyWikiDev
On Wednesday, September 23, 2020 at 10:49:18 AM UTC+2, TonyM wrote:

This example not only shows that the customise pragma can be used to store a canned filter for reuse, but also shows how the first in a nested list can be concealed behind a helpful name like system-shadows 
\customize tick=system-shadows _element="$list" filter="[all[shadows]is[system]]"

´system-shadows <$list filter="[all[current]has[caption]] +[!is[blank]]">{{!!title}} {{!!caption}}<br></$list>

Very interesting! .. If you use the template=xx parameter in the pragma and move the second list into the template, it could look like this.

´system-shadows-plus-caption

Similar to my examples in the last post, but without the _srcName parameter
 
I am confident with Mario's nesting method a simple line could define a set of nested lists with the content of the line equal to each final record.
If named well the variable set for each nested level will make the wiki text look like some 4th Generation reporting languages.

Yea, I think using the right naming is essential to create "wikitext" that is selfexplaining.
 
'customers `country `state {{{ [all[current]size[large]] }}} Automatic end string for each on \n?
But in this example I think the last filter here, on the line, needs to be in a list because otherwise it generates unnecessary line breaks
This is approaching simpler than SQL

 
  • Of course if somehow we can pass the filter to each nested level, not only would canned filters be used.
That's possible with the _srcName config. ... For 1 parameter

  • However if one has structured data in a wiki it would be simple to create the set of canned filters for handling the structured content in the wiki.
    • For users of a wiki (rather than owner designers) it may be simple to provide them the info they need to generate any list or report
    • Especially with some useful templates.
In the following case we use a list template
\customize tick=all-tiddlers _element="$list" filter="[is[tiddler]!is[system]]" template="$:/core/ui/ListItemTemplate"

´all-tiddlers This does nothing so can describe it
This is another case where passing the template value may be helpful

;) See last post.
 
I am working on a better way to name templates/transclusions so the above could read
\customize tick=all-customers _element="$list" filter="[is[tiddler]!is[system]object-type[customer]!archive[yes]]" template="(customer-record)"

´all-customers List all customer-records


 
By the way, If the List widget was to contain two new parameters before and after, that could provide header and footer content, Only if there were content, this would expand further, allowing content and or table headers. I miss foreachtiddler still :(

You can use a $macrocall widget here. IMO it should be simple. The default _srcName is src . So the macro will bet a "src" parameter, which can be used in the macro. src can be passed to the list-widget and the macro body can contain "before" and "after" elements.

IMO it's not needed in the list-widget.

 Thx for sharing
-mario

PMario

unread,
Sep 23, 2020, 6:05:37 AM9/23/20
to TiddlyWikiDev
On Wednesday, September 23, 2020 at 10:49:18 AM UTC+2, TonyM wrote:

\customize tick=children _element="$list" filter="[parent<currentTiddler>]"


And the last one children has set me of on a one and many to many relationship solution
* now that what TocP is no longer magical to me :)

I see :)
-m

TonyM

unread,
Sep 23, 2020, 6:22:54 AM9/23/20
to TiddlyWikiDev
Mario,

Thanks, there is a lot of good news there.

Especially the use of src

Do I understand correctly the _srcName=filter effectively says, assign the value found in the line, to the parameter filter, in this case that is in the list?

FYI only

With TocP I noticed I can create the child field via an alternate computed fieldname which I call a relationship field. Now I am working to identify and provide the filters for selecting from a set of possible relationships, like a man(tiddler) can create a new tiddler with, or assign another tiddler with the father-relationship field with the man(tiddlers) title. But it should also allow the child to nominate who their father is. Of course if a person is female then the mother relationship can be available, if a child is male female they can be identified as son or daughter etc...

  • Although this example is an important I aim to make this generic. As a result I need a field naming standard. I am thinking of using the hyphen -relationshipname for a one to one, and --relationshipname for one to many
Regards
Tony

TonyM

unread,
Sep 23, 2020, 7:20:52 AM9/23/20
to TiddlyWikiDev
Mario,

I think you suggested this before, but our use of widgets is limited by those who do not honour the close part of <$wiggetname params>content</$wiggetname> rule

A case in point is the <$count widget, as it can only be closed with /> not </$count>

Going forward
  • Perhaps we should raise this as a fix, for each widget we find, just to get the consistency we need that all widgets to allow the full close
  • I do not think you should cater for this because it could compromise nesting (a guess)
Regards
Tony

On Wednesday, 16 September 2020 20:22:05 UTC+10, PMario wrote:
Hi folks,

PMario

unread,
Sep 23, 2020, 1:22:32 PM9/23/20
to TiddlyWikiDev
On Wednesday, September 23, 2020 at 12:22:54 PM UTC+2, TonyM wrote:
 
Especially the use of src

Do I understand correctly the _srcName=filter effectively says, assign the value found in the line, to the parameter filter, in this case that is in the list?

Right!

If _element is a widget the content of the line is automatically added as an parameter named: src  .... src is the default.

eg: copy-to-clipboard and the docs-wikitext uses this name. some others use text. That's why it needed to be configurable.

-m


PMario

unread,
Sep 23, 2020, 1:28:27 PM9/23/20
to TiddlyWikiDev
On Wednesday, September 23, 2020 at 1:20:52 PM UTC+2, TonyM wrote:
 
I think you suggested this before, but our use of widgets is limited by those who do not honour the close part of <$wiggetname params>content</$wiggetname> rule

It needs to be content or template in the body.
 
A case in point is the <$count widget, as it can only be closed with /> not </$count>

Every widget that is used "self closing" like <$count /> there should be _no_ problem. They should all work. _And with the _srcName you have one parameter, that can be defined in the "user line"..
 
Going forward
  • Perhaps we should raise this as a fix, for each widget we find, just to get the consistency we need that all widgets to allow the full close
  • I do not think you should cater for this because it could compromise nesting (a guess)
As written with the _srcName parameter, there should be almost no limit in using any widget. ... except may be the <$button widget, if you want more than 1 parameter from the line.

-mario

TonyM

unread,
Sep 23, 2020, 5:13:10 PM9/23/20
to TiddlyWikiDev
Mario,

Yes I was erroneously using the 4.1 version while testing 5.1 (my Bad)

Every widget that is used "self closing" like <$count /> there should be _no_ problem. They should all work. _And with the _srcName you have one parameter, that can be defined in the "user line"..


However, without customisations
Count: `<$count filter="[prefix[$:/state]]"/>` works
Count: `<$count filter="[prefix[$:/state]]"</$count>` does not
So I think this observation still stands. 
Since customise will generate </$count> It will not work
I do not know how to identify others without exhaustive testing or reading (understanding) widget definition code.

As written with the _srcName parameter, there should be almost no limit in using any widget. ... except may be the <$button widget, if you want more than 1 parameter from the line.

  • Can I ask?, I have not test yet but is their any reason this would be limited to widgets?, because html could also make use of the content being applied to an attribute?
  • Perhaps too much to ask if there were a way to pass SOME content into the src and other as usual treated as content. 
    • In a dreamy state you could imagine any key=value pair in the "content" being translated to attribute=value with every thing else placed in the body.

Here is another experiment that has WORKED!
\customize tick=style _element="style"

´style .mystyle {  border: 1px solid green; border-style: dotted; }

;.mystyle Content
;Perhaps also;

´style {{myStyleSheet}}
so one could have a 

Anyway, Best start my day

Tony

PMario

unread,
Sep 23, 2020, 6:07:29 PM9/23/20
to TiddlyWikiDev
Hi
I did update the page and the pluginlibrary 5 minutes ago
-m

PMario

unread,
Sep 23, 2020, 6:29:15 PM9/23/20
to TiddlyWikiDev
On Wednesday, September 23, 2020 at 11:13:10 PM UTC+2, TonyM wrote:
 
However, without customisations
Count: `<$count filter="[prefix[$:/state]]"/>` works
Count: `<$count filter="[prefix[$:/state]]"</$count>` does not

There is a typo: you need to close the first widget element: `<$count filter="[prefix[$:/state]]"></$count>`
 
So I think this observation still stands. 
Since customise will generate </$count> It will not work

Not really. The string </$count>  is like the _endString parameter for the standard TW parser. So it doesn't need to be created.

I do not know how to identify others without exhaustive testing or reading (understanding) widget definition code.

see above typo.

As written with the _srcName parameter, there should be almost no limit in using any widget. ... except may be the <$button widget, if you want more than 1 parameter from the line.

  • Can I ask?, I have not test yet but is their any reason this would be limited to widgets?, because html could also make use of the content being applied to an attribute?
Do you have any examples, that would need it. .. There is no special reason.
 
  • Perhaps too much to ask if there were a way to pass SOME content into the src and other as usual treated as content. 
    • In a dreamy state you could imagine any key=value pair in the "content" being translated to attribute=value with every thing else placed in the body.
The problem is, that there is no way for the algorithm to know, if it is content, or if it is key:value as parameter.

Wouldn't it be better to use the "real" widget call instead of making "custom markup" more complex. I think, if we have parameters in the first line, we loose the "readablility" advantage.
 
Here is another experiment that has WORKED!
\customize tick=style _element="style"

´style .mystyle {  border: 1px solid green; border-style: dotted; }

;.mystyle Content
;Perhaps also;

´style {{myStyleSheet}}
so one could have a 

Yea, but that is not best practice. It will hide a <style> element, which shouldn't be used except for examples... <style> will always win and if a user wants to do some CSS customisation, those elements are very hard to find.

But anyway. It's interesting..

-mario
 

TonyM

unread,
Sep 23, 2020, 7:36:28 PM9/23/20
to TiddlyWikiDev
Mario,

Is it not your bed time?

There is a typo: you need to close the first widget element: `<$count filter="[prefix[$:/state]]"></$count>`

Not really. The string </$count>  is like the _endString parameter for the standard TW parser. So it doesn't need to be created.

My mistake again. However the following tick is not working
\customize tick=count-filter _element="$count"  _srcName=filter

Count: <$count filter="[prefix[$:/state]]"/>

´count-filter [prefix[$:/tags/macros]]

  • Can I ask?, I have not test yet but is their any reason this would be limited to widgets?, because html could also make use of the content being applied to an attribute?
Do you have any examples, that would need it. .. There is no special reason.

I will explore this further and report, however;
  • I imagine it uses a very similar mechanism
  • People may assume it will work
  • Perhaps too much to ask if there were a way to pass SOME content into the src and other as usual treated as content. 
    • In a dreamy state you could imagine any key=value pair in the "content" being translated to attribute=value with every thing else placed in the body.
The problem is, that there is no way for the algorithm to know, if it is content, or if it is key:value as parameter.

Fair enough, but since we have some methods to to access various values in the pragma definitions, perhaps we just need to document the way to make use of these
Thus rather than use parameter in the content we use them in our definitions, 
  • I will identify and document as I go
Yea, but that is not best practice. It will hide a <style> element, which shouldn't be used except for examples... <style> will always win and if a user wants to do some CSS customisation, those elements are very hard to find. 
 
I agree, in fact personally I do not like <style></style> in tiddlers, unless the css uses selectors, because the css bleeds into anything else on screen at the time a tiddler with this is open.
  • You demo site does this with red boxes if you have the "wrong" tiddler open.
The adventure continues

Tony

@TiddlyTweeter

unread,
Sep 24, 2020, 12:18:10 PM9/24/20
to TiddlyWikiDev
Comments as I work on a concrete example for PMario to see.

UPSIDES

1 - I think use cases will be able to BETTER leverage the more modern usefully semantically supportive HTML5 elements, like ...

nav
main
article
section
header
footer

2 - open-up much EASIER use of CSS because ...

3 - ... the way that \customize works is a VERY GOOD balance between old and new WikiText.

DOWNSIDES

1 - Only READABILITY (in the strict Gruber [Markdown] sense) is not so clear. Part of the issue is CHARACTERS used in markup got EATEN already.

I could write a lot about Unicode and reliability in fonts. BUT the issue is this: we do NOT actually know clearly WHAT characters are available for use. The result is that we take from the common European code pages. I am NOT convinced that is ideal. But can't find any definitive solution that could embrace Unicode Plane One better.

TT 


@TiddlyTweeter

unread,
Sep 24, 2020, 1:10:22 PM9/24/20
to tiddly...@googlegroups.com
Ciao PMario

I read through all the threads from the start again.

Doing that is interesting! The evolutions!

I'm looking at it thinking "is this for MAKERS of Wikis mainly?"

It would certainly enable me to make BESPOKE solutions much more easily. 

Why? Simpler leverage of HTML & CSS. 

Your approach POTENTIATES writing base CSS & HTML end-code very efficiently & flexibly.

HATS OFF!

But, as I work with it myself I sometimes struggle with the PERMUTATIONS possible.

My main wondering is WHO is it FOR, mainly?

Just a question.
Best wishes
TT

TonyM

unread,
Sep 24, 2020, 7:42:17 PM9/24/20
to tiddly...@googlegroups.com
TT,
 
But, as I work with it myself I sometimes struggle with the PERMUTATIONS possible.

This is so often the case in tiddlywiki, the customisations and possibilities are virtually infinite in many directions.
This is just another few dimensions of control.
 
My main wondering is WHO is it FOR, mainly?

Just as for tiddlywiki, we will not know except through lived experience. 
Unlike commercial solutions we do not need to lead with a defined user or market. 

The most substantial features this introduces in my view is;
  • The application of wikitext or CSS to any line, not just lines beginning with existing markup like * : ; # !
    • Shortcuts to apply css to any line
    • This is fixing a GAP in the current mark-up
  • The ability to build shortcuts for HTML and Widgets such that you do not need to close the tag and you can pre-set attributes and parameters 
  • </tagname> </$widgetname>

  • Defining your own wikitext markup using the special characters and symbol provided.
  • The opportunity to address various gaps in tiddlywiki via a customisation route
    • Improved sliders and details
    • Building more semantic elements
    • Interactive wikitext eg checkboxes

My view is that configurations will be made available to address different needs such as those below. 
I think this will be used in a way that macros do, people will craft and distribute solutions based on all or part of the customise solution.
  • An individual being able to build short cuts for themselves (productivity)
  • A canned set of customisation for different users eg
    • Authors
    • Book authors
    • Blog or newsletter writers.
  • Automated website or page generation
  • Providing custom mark-up for users to use in content - almost another mark-up language, where the designer sees the value.
    • Will need to be structured and documented in the solution, by the designer. See my "address" post, that uses vars to supply predefines variables
  • and many as yet unforeseen possibilities
Regards
Tony

@TiddlyTweeter

unread,
Sep 25, 2020, 4:26:40 AM9/25/20
to TiddlyWikiDev
Ciao TonyM

As ever from you an inclusive, broad reply.

I'm actually wondering a slightly different way. Narrower. But very real. ... For instance ...

Does it matter if an end-user on web has the markup character in a font?

Personally I like to use glyphs from any of the UTF-16 doable Unicode (=Unicode “Basic Multilingual Plane”, choice of 55k plus characters). That way you can have symbols that actually have meaning (open, close, paragraph, section etc). I have local fonts available for that. So *I* will see them in TW (OS font substitution or explicit invoke in TW settings). A user may not; likely will not. 

BUT, since the BESPOKE markup is mine for my use they DO NOT need to have the font for the markup character since they will NEVER edit a Tiddler in an application I build using this approach. that would be blocked. Its for reading, not editing.

In any case it would not be compatible with providing, on-line, editable TW. 
BUT it is GOOD from point of view of author making TW for USE, not edit, by users.

I think this comment encapsulates my point well enough?

Regarding the OP I am wondering a bit about whether PMario's setting of the "base glyphs" to be in a "European language" font is necessary.

Its a thought :-) I'll expand on a bit later.

Best wishes
TT

@TiddlyTweeter

unread,
Sep 25, 2020, 4:59:08 AM9/25/20
to TiddlyWikiDev
This for PMario & TonyM

Its a thought.

TWO config modes ...

Config 1 - that adds the editing tools to enable the PMario Custom Markup explicitly (i.e for any user)

Config 2 - that adds the tool BUT adds NOTHING to the editor. I'm thinking of cases where USER needs basic usage but NOT to ever see complexity of PMario Custom Markup system.

Thoughts on real utility (never add visible tools an end-user does not need).
TT

@TiddlyTweeter

unread,
Sep 25, 2020, 5:11:56 AM9/25/20
to TiddlyWikiDev
PMario & TonyM

Unicode does provide many paired glyphs, albeit some are outside the UTF-16 range. 
See, for instance, some of them: https://www.compart.com/en/unicode/mirrored

Best wishes
TT

On Friday, 25 September 2020 10:26:40 UTC+2, @TiddlyTweeter wrote:

@TiddlyTweeter

unread,
Sep 25, 2020, 6:00:22 AM9/25/20
to TiddlyWikiDev
To clarify my last point about TWO configs, nasty & irritating as the idea is :-(...

I think it very LIKELY that PMario's Custom Markup system will be, eventually, widely used by AUTEURS (originating author geeks).

I am NOT convinced that a TW that uses that brilliant system should expose it to every user. I think it would be a support issue of scale to do so.

Ongoing thoughts. Just thoughts.
Best wishes
TT

@TiddlyTweeter

unread,
Sep 25, 2020, 6:13:08 AM9/25/20
to TiddlyWikiDev
Ciao PMario

Can you PLEASE correct angel to angle. !!!!

You may not realise the cognitive dissonance it causes.

In English my life partner was Angela (German, deceased), I am godfather to the child Angelo (Italian, male) & friend of Angelo (an Italian policeman).

Add in the generic issue that no way is an Angel an angle.

Please. It is confusing!
TT 

PMario

unread,
Sep 25, 2020, 6:20:12 AM9/25/20
to TiddlyWikiDev
On Friday, September 25, 2020 at 11:11:56 AM UTC+2, @TiddlyTweeter wrote:

Unicode does provide many paired glyphs, albeit some are outside the UTF-16 range. 
See, for instance, some of them: https://www.compart.com/en/unicode/mirrored

For javascript, it's not necessary, to use UTF-16. It can work with unicode. So technically, we should be able to use any character in the unicode space.

... BUT I would need feedback, which of them make sense. The "mirrored" chars are mainly math. So only very view of them can be used, without creating unintended "meaning".

-m

@TiddlyTweeter

unread,
Sep 25, 2020, 6:42:07 AM9/25/20
to TiddlyWikiDev
Ciao PMario

Right. But beyond 16 it looks like A character it isn't exactly that. But glad you'd be happy with that.

Sure there are many pairs not to use because of common usage already. That still leaves a lot of Unicode pairs available. There are more than I pointed too.

My POINT, I think, was IF we took Unicode more seriously pairing would be so much easier.

There are two issues in our context ...

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.

2 - font support is a very complex issue. It is extremely difficult to determine what glyphs are available visually universally (because of sophisticated OS substitutions). HOWEVER, I made the point that in many cases it is ONLY the author who needs to have them supported by a font.

Thoughts 
TT

PMario

unread,
Sep 25, 2020, 7:26:12 AM9/25/20
to TiddlyWikiDev
On Friday, September 25, 2020 at 12:00:22 PM UTC+2, @TiddlyTweeter wrote:
To clarify my last point about TWO configs, nasty & irritating as the idea is :-(...

I think it very LIKELY that PMario's Custom Markup system will be, eventually, widely used by AUTEURS (originating author geeks).

I did have an idea, this morning. .. You know the time, where you are not sleeping anymore, but also not awake. ... I was thinking about a possibility to completely customize _every_ possible widget, that has a visual representation.

It really bothered me, that the following fails, if you change the text.

\customize degree=☐ _element="$macrocall" $name="xx"

\define xx(src)
<$checkbox tiddler=<<__src__>> tag=done class="db"> <<__src__>></$checkbox>
\end

°☐ This is a Test
°☐ This is a test 1

Tony wanted the possibility to add more key=value _params. .. And I think it should be possible, in the _params section and calling it. eg:

°☐:a This is a Test
°☐:b This is a test 1   .... or something similar

Where "a" and "b" can be unique identifiers, that makes it possible to change the "This is a test" text, without loosing the state. It will also make it possible to use "system states", without the need for the user to type $:/state/xx, because they only need to type the "xx".

 
I am NOT convinced that a TW that uses that brilliant system should expose it to every user. I think it would be a support issue of scale to do so.

You are right, but IMO it is a similar idea as Jeremy proposed at github: Implement wikitext shortcuts as macros.
 
have fun!
mario

PMario

unread,
Sep 25, 2020, 7:35:17 AM9/25/20
to TiddlyWikiDev
On Friday, September 25, 2020 at 12:13:08 PM UTC+2, @TiddlyTweeter wrote:

Can you PLEASE correct angel to angle. !!!!

I knew, that someone would have a problem. But for me this looks like an angel »|« , with some phantasy.

I'll think about it, since there may be some "religious" concerns too. ... But otherwise I'd definitely keep it ;)

And we have the "almost" ID too, which can be used instead ;)

-mario

PMario

unread,
Sep 25, 2020, 7:43:26 AM9/25/20
to TiddlyWikiDev
On Friday, September 25, 2020 at 1:26:12 PM UTC+2, PMario wrote:
...

Tony wanted the possibility to add more key=value _params. .. And I think it should be possible, in the _params section and calling it. eg:

°☐:a This is a Test

It should be also possible to use the Ballot Box as an ID instead of the degree eg:

\customize ballot=check ...

☐check:a This is a test
☐check:b This is a test

Which would make it a "very very" specific ID for a special usecase. ... I'll need to think about it, if that should be done.

mario

PMario

unread,
Sep 25, 2020, 7:47:42 AM9/25/20
to TiddlyWikiDev
Hi folks,

We should go on here: Custom markup (continued 3)

have fun!

@TiddlyTweeter

unread,
Sep 25, 2020, 7:51:16 AM9/25/20
to TiddlyWikiDev
On Friday, 25 September 2020 13:35:17 UTC+2, PMario wrote:
On Friday, September 25, 2020 at 12:13:08 PM UTC+2, @TiddlyTweeter wrote:

Can you PLEASE correct angel to angle. !!!!

I knew, that someone would have a problem. But for me this looks like an angel »|« , with some phantasy.

A lot of phantasy since its just the one wing "»" at the moment. :-)  Anyway it is a right-pointing guillemet.

TT

PMario

unread,
Sep 25, 2020, 7:57:23 AM9/25/20
to TiddlyWikiDev
On Friday, September 25, 2020 at 12:42:07 PM UTC+2, @TiddlyTweeter wrote:

There are two issues in our context ...

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.

You are right, but 1 of my main goals for this project is to have the prose text as readable as possible.
 
2 - font support is a very complex issue. It is extremely difficult to determine what glyphs are available visually universally (because of sophisticated OS substitutions). HOWEVER, I made the point that in many cases it is ONLY the author who needs to have them supported by a font.

Yea, it would be nice to have a 2 configuration tiddlers, that can initialize the IDs at wiki startup. ... I don't want to read these tiddlers with every occurrence of the  \customize pragma. This can considerably slow down this parser.

But it would allow users to create their own IDs.

THE downside of this approach is: It may create a new Tower of Babel. 

-mario.

TonyM

unread,
Sep 25, 2020, 11:13:27 AM9/25/20
to TiddlyWikiDev
Mario,

I don't think very specific id's are a problem if the result is of substantial utility.

I have a larger concern about the symbols which have a wider applicability, because I think they need to be given a default purpose, kind of defacto standard for each of them, to encourage some consistency. 

Without some suggested uses for each and a suitable default state even an individual may have a problem re-reading their mark-up later. We create some rules but you can always break them.

Defacto standards are just a suggestion, but deciding before deployment some common suggestions, will help the community build a language.

Perhaps the suggestion may be (brainstorm follows)
  • One for inline classes and formatting CSS
  • One for block classes and formatting CSS
  • One for html entities
  • One for widgets
  • One for transcluding content
  • one for list outputs (multiple items)
  • One for checkboxes
Questions?
  • What major areas of possible application can you think of?
  • Perhaps knowing the above could help us choose the characters to use?
For example >> for lists? or blocks

I have not yet attempted any inline uses, Do you have a working example yet?

Regards
Tony
Reply all
Reply to author
Forward
0 new messages