Custom markup?

[Mat]

It would be useful if TW could work as a custom markup constructor+interpretator.

I.e that it featured "potential wikitext markdown" that people can CSS-style freely. For example, we currently have the list elements * and : that give predefined <ul><li> and <dl><dd> with specific styling. It would be neat if e.g § or other characters would trigger custom styling IF the user choses to define such styles. If no style is defined then, I guess, the characters and subsequent content displays as usual.

Notably, HTML has this built in i.e it allows custom tags like <mytag>Lorem ipsum</mytag>, but the requred angle brackets and possibly closing tags make this too verbose. I want a smooth wikitext markdown command.

I identify two "base cases"; one with a opening and a closing mark (compare to a div). And the other as list element marker with only an explicit opening mark and an implied closing mark consisting of newline or similar.

One idea would be to use the aforementioned § character. IF a row is prefixed with § and has a subsequent empty row (or end of tiddler) then it is interpreted as a list element. If the row instead is encapsulated with a § and a suffixing § then it is interpreted as a div. For example the first case could be interpreted as <li class="custom-li"> and the second case as <div class="custom-div">....</div>.

We'd get infinite options if one could use §1, §2, ...

(Possibly the character should trigger more than mere CSS. I would guess pipe characters, when creating wikitext tables, do this, right? In that case, § could trigger some user defined macro, perhaps titled § ...or §1, §2... to operate on the text snippet in question.)

Thoughts?

<:-)

[PMario]

Hi Mat,

IMO it will be hard to use the (paragraph) § sing as a start or end of special markup. .. It's way to common in "law related" texts. eg: § has a meaning on its own. Same is true for §§. So we will need at least 3 of them to start or end with. ...

IMO it will be very similar or the same as: https://tiddlywiki.com/#Styles%20and%20Classes%20in%20WikiText

-mario

[@TiddlyTweeter]

Ciao Mat

Broadly agree with PMario on this for modest customisation within standard TW content type. Not least because the mechanism is there for handing open and closing changes already for custom styles. That said, I could imagine a "custom pragma" that user can add to might be worth thinking about. Decent pragma have a bit more intelligence than just substitution. Lists, for instance, need to faultlessly handle nesting.

In a way, the issue partly devolves on how far you want to go with custom styling elements. Personally I use BJ's variant pre-parser tool that enables regex to insert any manner of changes in HTML or CSS before render. That, for me, is for specific needs for laying out screenplays. But that would be overkill for more modest changes in normal type tiddlers.

Thoughts

TT

[Mat]

@pmario

As noted, if no style is defined, then it appears just like a regular character. The idea is that it is user controlled. (But I actually chose the specific § character because it is not unlikely that people will want it to style "paragraphs" - also in law related texts, e.g indented or monospace etc.)

An alternative character might be to extend the wiki markup for quotations, i.e the > or <<<  Particularly the latter, which requires an otherwise empty line, should be doable (<<<3 to trigger some third styling). The single > character might be trickier.

IMO it will be very similar or the same as: https://tiddlywiki.com/#Styles%20and%20Classes%20in%20WikiText 

Really? Do you feel the same about the * and : markup? Might as well do it with @@... instead?

The point is to access ones own look/behaviour as smoothly as with e.g *

<:-)

[PMario]

On Thursday, August 27, 2020 at 6:54:16 PM UTC+2, Mat wrote:

...

IMO it will be very similar or the same as: https://tiddlywiki.com/#Styles%20and%20Classes%20in%20WikiText 

Really? Do you feel the same about the * and : markup? Might as well do it with @@... instead?

The problem is, that we don't have enough unique "indicators" left.

 

The point is to access ones own look/behaviour as smoothly as with e.g *

eg: I'm working on a new plugin that will allow us to style paragraphs. It uses the "accent" aka "Tick"

´ some text or

´´ some more text indent level 1

´´.test paragraph indent level 1 and class "test" added

BUT there is already a problem, which may not be obvious. .. The damned thing isn't part of every keyboard layout. It depends on the language settings.

An alternative is "angle quotes" »

» some text or

»» some more text indent level 1

»».test paragraph indent level 1 and class "test" added

Same thing here. I needed to copy paste it from a different site :/

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

One idea would be to use the aforementioned § character. IF a row is prefixed with § and has a subsequent empty row (or end of tiddler) then it is interpreted as a list element. If the row instead is encapsulated with a § and a suffixing § then it is interpreted as a div. For example the first case could be interpreted as <li class="custom-li"> and the second case as <div class="custom-div">....</div>.

Your first example is

* standard list element

*.custom-li different list text

raw html is:

<ul>
  <li>standard list element</li>
  <li class="custom-li">different list text</li>
</ul>

Your second example is

@@.custom-class

* element 1

* element 2

@@

raw html is:

<ul class="custom-class">
  <li>element 1</li>
  <li>element 2</li>
</ul>

which works out of the box. So I don't see too much difference and it's already there.

-mario

[Mat]

PMario wrote:

The problem is, that we don't have enough unique "indicators" left. 

For one I'd think specifically § does occur on all western keyboards but, regardless, if the OP is made fully general in the sense that the user can define his own indicators then he can use whichever indicator he wants. This should be particularly appealing for those that don't even use western keyboards at all. 

 

The point is to access ones own look/behaviour as smoothly as with e.g *

eg: I'm working on a new plugin that will allow us to style paragraphs. It uses the "accent" aka "Tick"

(Are you really working on that or are you just making example? How would it be different from simply styling bullets instead of requiring a new indicator? But if you do want a special indicator, then why not go with § which was literally created to define paragraphs?)

 

<div class="custom-div">....</div>

Your second example is

@@.custom-class

* element 1

* element 2

@@

First, you're only talking about styling. As I mention, I envision that the indicator could also be a macro/code (like what I assume is done with pipe characters to create tables).

But more cricitally you misunderstand the point with my proposal. The point is not to achieve a specific visual end result. That can be done with @@ or with html. Rather, the point is (1) to simplify authoring, and (2) quoting Gruber:

“The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.”

Surely, you must agree it is both friendlier for the eye and much simpler to type:

§ So this is a "special" paragraph
§ This one also

..than e.g:

@@.myclass So this is a "special" paragraph@@
@@.myclass This one also@@

...and, again, that even only looks to the styling aspects. Really, it should be:

<<mymacro """So this is a "special" paragraph""">>
<<mymacro "This one also">>

...but this would cause further problems with other wikitext like

<<mymacro "So this is a <<anothermacro special>> paragraph">>

...and so we'd need to go full wikitext coding on it, leaving pretty markup all together.

Things like * and : and | and > are very useful and elegant. My proposal is about extending this.

<:-)

[Eric Shulman]

On Thursday, August 27, 2020 at 1:30:03 PM UTC-7, Mat wrote:

§ which was literally created to define paragraphs

In legal texts, the § symbol can be used as a printable character to *cite* a section of the legal code as in:

USC17 §107

which is a reference to United States Code, Title 17, Section 107 - Copyright Limitations on exclusive rights: Fair use

Using this code to control formatting would preclude using it as a printable character in legal texts.

-e

[Mat]

Eric Shulman wrote:

Using this code to control formatting would preclude using it as a printable character in legal texts.

Good then that my proposal is for "custom markup", as defined by the user, and not predefined markup. As noted in the OP, if no styling etc is defined then using the character doesn't "do" anything. 

Any thoughts on the OP (with the goal of simplifying authoring)? 

<:-)

[TonyM]

Mat,

I support your desire for a solution. As Mario indicated we have being looking at a method markup method to force a line into a paragraph, the old chestnut, however I believe it indicates a possible solution.

When it comes to classes we may have an answer, but yes I would appreciate further custom markup constructor+interpreter,  However what we are working on may go a long way.

Many of the wikitext items accept a .classname such as ; : * #

eg

:.classname

*.done List item

As with the paragraph there is no quick and easy way to add css to any other wikitext such as simple lines, and a way to force paragraphs <p></p> around a set of sentences - If a line is empty, Paragraphs ensure one, not more blank line(s) between paragraphs. 

To me this is a clear gap in the css address-ability of wikitext, including lines without wiki text.

Hopefully I and Mario will have a solution soon.

Regards

Tony

[TonyM]

Mat,

Any thoughts on the OP (with the goal of simplifying authoring)? 

It this Mario/Tony solution is complete any line can become a styled paragraph. To extend to your OT consider this;

• Wiki markup is effectively translated to HTML tags (Except macros and transclusion which are eventually)
• Of course one form of custom markup is to start using html tags in your text
  • But we know this is harder to read than wikitext, where we need not always close something like "*" rather than `<li>item</li>`
• So what if we had a way to craft a html "template" then access it via a markup escape character? The HTML would then act on the line we marked up
  
  • But why stop there, why not define a template html or otherwise, then have a wikitext markup that applies that template to the wikitext line.
• You can see below there is a large range of Unicode characters available to use that in wikitext can be used
  • We can provide a EditorTool Bar button to insert or prefix lines with out custom characters.
  • This fine for tiddler wiki authored text because these unicode characters will not be in the text unless the author puts them there, and they only become alternative markup if escaped.
  • Tiddlywiki core could understand the escape and show nothing if there is no markup definition.
• It would be easy to share a set of alternate markup to support authors etc.. 

For example if we used the character you pointed out

§☐ Item  

Would use the special template labelled ☐ to format Item, which may be <<checkbox "$item$">><li>$Item$</li>

I think there may be a better character, I will share if I find it.

Regards

Tony

[@TiddlyTweeter]

Mat & PMario

 

PMario: The problem is, that we don't have enough unique "indicators" left.

Dead right. And actually the finite nature of standard available keyboard characters is already an issue. For instance "backtick" is not standard on all keyboards. Italian keyboard, for instance, lacks it. User has to get round such issues by getting OS to change keyboard mapping; or learning keyboard numeric escape sequences to input characters; or using the editor "stamp" tool to hold boilerplate for it, or some other utility/method. 

The messiness around all this is ultimately a consequence of hardware design. One that can be relatively easily addressed. However it surely needs better adjunctive documentation to assist users understand what to do--even for existing WikiText.

 

Mat: The point is to access ones own look/behaviour as smoothly as with e.g *

Right. That makes it "Markdown Like" i.e. the trigger markup is simple and readable/semantic as plain text. Point is markdown is a simple approach to insert HTML elements (with attributes if needed, esp for classes) in order to preserve plain text readability. Styling is then applied via CSS in standard way. So, wanting to extend that in standard content type modestly with one or two WikiText custom elements I grasp. 

How? Obvious method would be a "custom pragma" that permitted definition of new character/pair of characters.

But a design issue tension exists between "available characters" & "my new markup schema". Its inevitable! But that issue--paucity of characters on default setups, including variable layouts on different keyboards etc--needs addressing another way and should not be allowed to muddy the waters of the intent to achieve "Markdown Like" extensions to the pragma.

TT

[@TiddlyTweeter]

Eric Shulman wrote:

In legal texts, the § symbol can be used as a printable character to *cite* a section of the legal code as in:

USC17 §107

which is a reference to United States Code, Title 17, Section 107 - Copyright Limitations on exclusive rights: Fair use

Using this code to control formatting would preclude using it as a printable character in legal texts.

Ciao Eric & Mat

I think it should be possible, with a proper custom pragma, to use \rules to control for this. I.e. be able to use "§" in one wiki both as a lawyer (no substitution, remains printable) and for markup (substitution).

Yes?

TT

[@TiddlyTweeter]

On Thursday, 27 August 2020 23:53:53 UTC+2, Mat wrote:

Eric Shulman wrote:

Using this code to control formatting would preclude using it as a printable character in legal texts.

Good then that my proposal is for "custom markup", as defined by the user, and not predefined markup. As noted in the OP, if no styling etc is defined then using the character doesn't "do" anything. 

In any case, if constructed through a proper pragma then it should be possible to de-activate the behaviour using \rules for specific Tiddlers.

Mat: Any thoughts on the OP (with the goal of simplifying authoring)? 

The principle of the OP has been hashed over a bunch of times. BJ long ago made an entire system in three variants to get control of parsing. His approach is maybe worth looking at, I think, to basically grasp how to do it. Then apply to standard content type.

TonyM has asked about this a bunch of times. Some of the discussions with him are informative.

IF you want to have links to TM or BJs stuff let me know (could take some time). But maybe you know all this already.

So, the most robust method would likely be a new pragma that has config options for (a) character choice (b) basic behaviour.

TT

[@TiddlyTweeter]

Mat wrote:

We'd get infinite options if one could use §1, §2, ... 

That sounds like a shift away from "Markdown Like" ... In that the character pair is "code for something" ... one might argue that "<<< ...<<<" is already not that Markdown Like. Its an interesting question. In earlier discussions with TonyM using a "universal prefix" came up. Extending on that idea, for instance starting a line with a full-stop, or whatever ... 

.§ = activate Mat style Custom Wikitext pragma for "§"
.d = activate screenplay Dialogue styling

These approaches remain nicely compact but are not ideal "Markdown Like"--plain text readability is not brilliant. That said, once you use up available characters with meaning its a viable alternative.

Another approach it to add NO EXPLICIT MARKUP AT ALL but construct a pragma that via regex analyses pattern of text in line. That works easily for highly structured texts. For instance any line of a "transition" in a script (like "CUT TO:" or "FADE OUT:") are easily identified by pattern without adding any markup & can be styled appropriately. The text in these cases is "its own markup". I often wonder if that "silent" approach could be extended to more conventional text.

It would be useful if TW could work as a custom markup constructor+interpretator.

(Possibly the character should trigger more than mere CSS. I would guess pipe characters, when creating wikitext tables, do this, right? In that case, § could trigger some user defined macro, perhaps titled § ...or §1, §2... to operate on the text snippet in question.)

I'm not so sure about extending this into basically a command parser :-) . If you going pragma route then its possible, but focus on simple insertion of styled elements is quite a lot to get working well for one pragma already.

How many many pragma were you thinking of? :-)

I do think a "kitchen sink" pragma (i.e. does a bunch of different things at once) is probably not a good idea. On this, extending beyond element styling, to "interpret activity insertion" some use cases are needed to think with.

My further thoughts

TT

[TonyM]

TT,

Offline I and Mario were working on a dot paragraph solution, perhaps a  §  paragraph,  » or  leading  ⁋  paragraph, or trailing ¶  paragraph or <dot><space><space> at the end of a "line". The character is somewhat irrelevant for considering the idea.

However we have moved away from dot as it works as .classname.

In someways the key is a markup character you can use on a line that has no other markup character.

What we have discovered however we do this, the special character can be followed with a .classname and in fact .clasname.classname to apply multiple; so we found this simple example

.i  { margin-left: 3em;}

.ii  { margin-left: 6em;}

.r  { margin-right: 3em;} 

.rr  { margin-right: 6em;}

.j { text-align: justify; text-justify: auto; }

Allowing 

Using the above css its simple to use

».ii.rr,j  Paragraph line here indented twice both left and right side, and justified.

Or set and indent a paragraph twice

»»» Paragraph line here indented twice

Keep in mind the .classname is already available with other markup *, # ; : etc... not that you would indent an "indent markup" but you may color it and more.

In composed tiddlers, or pasted text it would be easy to apply a level of markup via css if there is the leading character to trigger the option of .classname

• Unlike @@ .mystyle you do not have to close it, it autoclosed at \n or end of line @@ and seriousely @@ is obstructive.
• Perhaps we need a block line (paragraph), multi-line block and inline versions?

Just sharing some thoughts

Regards

Tony

[Mat]

As noted, I think a key question for this discussion is what the purpose is:

To (merely) control the styling of text snips, one can use common HTML. So, for a TW solution to be meaningful, it has to improve something. Using @@.foo ...@@ achieves the identical styling outcome, so no improvement in that regard. And semantically the difference between @@.foo ...@@ and <div class="foo">...</div> is very small - it takes almost as much typing and it is almost as visually distracting when reading the code, so almost no benefit in that regard either. But, in contrast to pragma rules, both alternatives have the "plus" that they manipulate the "very current" text part that one is authoring.

@PMario/Tony , I really like your idea to apply style with

X.classname My text here\n

...and, even nicer, directly:

.classname My text here\n

...because it significantly simplifies applying styes for the author, and readibility is superior to html or @@ (at least if the classnames are not confused with the text itself).

This jives perfectly with the styling aspects of my OP (tho not any "programmatic functionality" like pipe chars). And if the class is undefined then, just like usual with css, the result is "no effect".

Are you saying your approach works or did you hit some problem?

Have you considered syntax for styling bigger text portions, i.e that contains multiple \n ? I.e how to specify an end marker?

@TiddlyTweeter

I am not the least fond of the pragma route for the reason I hinted in this post, i.e that it breaks the authoring workflow. Imagine if you were forced to add a pragma every time you wanted bullet lists? It is distracting and bad UX, IMO. Pragmas definitely have their place, for instance for macros where the pragma is part of what actually constitutes the thing. Another case is a pragma that implies "this tiddler should have this special functionality" but my OP here is for something mundane and comparable to * for bullet lists - it's just that the user himself can make up what the effect should be.

<:-)

[@TiddlyTweeter]

Mat wrote:

@TiddlyTweeter

I am not the least fond of the pragma route for the reason I hinted in this post, i.e that it breaks the authoring workflow. Imagine if you were forced to add a pragma every time you wanted bullet lists? It is distracting and bad UX, IMO. Pragmas definitely have their place, for instance for macros where the pragma is part of what actually constitutes the thing. Another case is a pragma that implies "this tiddler should have this special functionality" but

 

... my OP here is for something mundane and comparable to * for bullet lists - it's just that the user himself can make up what the effect should be.

Right. But that involves a parser that inserts the <li> element and deals with nests etc.

Excuse me if I read the original OP (which I was responding to) as wanting to ...

(1) custom style given to blocks like <p>, <li> etc using more Markdown Like method than the @@ ... @@ approach.

(2) insert new HTML elements, not covered by extant WikiText, to enhance TW markup vocabulary?

(3) permit gizmos (e.g. pipe) to alter what hits render?

I can't see all of the three being achieved without at least a parser, and likely a pragma bit too (esp. for \rules).

But, IF, the OP is to only cover  easier tweaks/overrides to standard styling ... well its pretty much in arena that TonyM & PMario touched into in some detail already I think.

Anyway its an interesting thing. One can finally smell some coffee maybe coming.

Best wishes

TT

<:-)

[@TiddlyTweeter]

Ciao TonyM

Good stuff!

I think it is worth underlining that you are interested in LINE AWARENESS.

That the scope of some(?) of what you want is line (i.e. /^.+\n/gm) NOT the standard paragraph (i.e. /^.*\n\n+/gm)

Best wishes

TT

[PMario]

On Saturday, August 29, 2020 at 7:02:26 PM UTC+2, @TiddlyTweeter wrote:

...

I think it is worth underlining that you are interested in LINE AWARENESS.

That the scope of some(?) of what you want is line (i.e. /^.+\n/gm) NOT the standard paragraph (i.e. /^.*\n\n+/gm)

I'm not Tony, but anyway. That's right, at the moment we will "end" the block with the first \n that is found. ... And the comment from Mat made me think. ... That's bad. Since what seemed to be finished seems to start over again :/

I do want it both. I want to be able to create something that makes copy paste - styling - actions easier for Tony, and I want to style paragraphs as well.

´´´.class will be published first and works with \n

where

´.iii may be the better option, to make indents more readable. I'm also considering to make it a <div> instead of a <p> tag. <div>s are more flexible which content they contain.

».class will follow and should work with \n\n as paragraphs. Implementation will be harder as it seemed at first.

<space><space>\n will be recognized as a hard linebreak with a second plugin.

All of this is experimental and topic to change completely. ... I did study the different keyboard layouts at wikipedia. Especially international and German / EU-style German where I only found a german description. I found out, that my own keyboard is completely outdated :/

I also found out, that Linux users have a big advantage here.

For my own keyboard I need to compile custom windows settings without "dead" keys to get "ticks", "backticks" and others in a convenient way.

-mario

[Mat]

@PMario and @Tony

I'm really looking forward to your plugin. Some questions:

As PMario notes, the "indicator" characters are problematic especially the » which doesn't even exist on many keyboards, including mine. So then... how is that simpler than using e.g @@.class ? 

I take it that the style defs are customizable but would it be possible to make the indicator character customizable? This would solve everything since the user knows his own habits and keyboard. Even "Joe the Finger", whos hacker career totally tanked after the accident (but he did get ever so popuplar among the ladies), even he will be able to use your plugin comfortably then.

Maybe one could make a user modifiable dictionary like so

» : <classnames>

i : <classnames>

ii : <classnames>

asdf : <classnames>

(or even style definitinos directly instead of the classnames)

Also, @Tony did briefly mention a dot classname syntax, i.e:

.class My text/n

without any other prefixing indicator. I didn't quite understand why this is not possible, could someone explain?

<space><space>\n will be recognized as a hard linebreak with a second plugin.

When manipulating text in filters, can <space><space> be retained or do I remember right that filters often trim space chars?

<:-)

[Diamond Demon]

so which one is twFile download link?

[TonyM]

Folks,

A Few quick points.

I am not sure we need be so fussed if the character is not normaly available on the keyboard, we can access it many ways including EditorToolbars and even shortcodes, and this means it is much less likely to clash.

I have not tested it but I abhor the @@ syntax for single lines or inline styles as it dominated too much, but it may be suitable and already work for applying css to a block of multiple lines, in which case it is better it be visible.

One idea was to allow for named html tags like 

 

»div.classname This is text (Autocloses div at EOL)

So the <dot> paragraph would become 

»p.classname

Multiple lines can use the existing;

@@.classname
1
2
3
@@

I think we may need to extend these ideas to inline css as well

how can we trigger .classname inline ⇨.classname blah blah⇦ text continues

Finally, I have not confused the sh-t or out you all; I am wondering about using custom classes, and content to inject functionality

eg

*.check Items details
*.check Item2 details

Would present check boxes to toggle if the items complete, ether only current session or indefinitely.

This currently is confused by the fact CSS "is rendered at the last moment".

Regards

Tony

[TonyM]

Mat,

» : <classnames>

i : <classnames>

ii : <classnames>

asdf : <classnames>

I was thinking about this too, but also designed to allow a cheat sheet and editor tool bar button to lookup and insert as needed. 

Perhaps ii even displays  the css 

{ margin-left: 6em;}

Really good when developing the ad Hoc personal markup (via CSS)

Tones

[TonyM]

TT

Thant sounds correct, but I seem to suffer from dyslexia with Regex, I know it just needs time on task, practice etc...

Tones

[PMario]

On Sunday, August 30, 2020 at 2:30:17 PM UTC+2, Mat wrote:

...

I'm really looking forward to your plugin. Some questions:

I'll try to publish an experimental version today.

 

As PMario notes, the "indicator" characters are problematic especially the » which doesn't even exist on many keyboards, including mine. So then... how is that simpler than using e.g @@.class ? 

hihi. ... Yea that's the question. ... There will be new editor toolbar buttons and a keyboard shortcut. ;)

 

Maybe one could make a user modifiable dictionary like so

I'm thinking about it, but at the moment I didn't have a good idea. The main concern is content "exchangeability" ... A well defined wikitext syntax guaranties readability with federated wikis. .. There is still some hope :)

» : <classnames>

i : <classnames>

ii : <classnames>

asdf : <classnames>

This would mean I need to create a completely new parser. ... ATM I'm using the default functions, that are already part of the core and battle tested.

 

(or even style definitinos directly instead of the classnames)

ONOooooo... style is hardcoded and will always win. So document consistency will be broken completely.

 

Also, @Tony did briefly mention a dot classname syntax, i.e:

.class My text/n

without any other prefixing indicator. I didn't quite understand why this is not possible, could someone explain?

This clashes with CSS tiddlers that are type text/vnd.tiddlywiki ...

 

<space><space>\n will be recognized as a hard linebreak with a second plugin.

When manipulating text in filters, can <space><space> be retained or do I remember right that filters often trim space chars?

There is a second version which looks similar to a "bash": <space><space><backslash> which will also create a hard linebreak.

But with my experiments I probably found a third way too. Which uses a similar mechanism to https://tiddlywiki.com/#Hard%20Linebreaks%20with%20CSS

-mario

[TonyM]

Mario

 

I'm thinking about it, but at the moment I didn't have a good idea. The main concern is content "exchangeability" ... A well defined wikitext syntax guaranties readability with federated wikis. .. There is still some hope :)

» : <classnames>

i : <classnames>

ii : <classnames>

asdf : <classnames>

This would mean I need to create a completely new parser. ... ATM I'm using the default functions, that are already part of the core and battle tested.

 

(or even style definitinos directly instead of the classnames)

ONOooooo... style is hardcoded and will always win. So document consistency will be broken completely.

I believe all we are talking about here is a dictionary of  custom or standard classes one may use in the wiki. they are .classnames the user build or takes from a small list, Either to lookup and type or apply with an Editor toolbar button. 

No parsing required in the greater tiddlywiki, it will just work out of the box.

I will have a look at building it to demo.

Regards

Tony

[PMario]

Hi Mat,

I did publish an EXPERIMENTAL wiki [1] at wikilabs, that contains 3 new wikitext elements.

The orginal conversation between Tony, TiddlyTweeter and me can be found here [2] ;)

-------------- BACKUP - BACKUP - DO NOT USE IT FOR PROUCTION WIKIS !!!!!!!!! --------------

A "tick" and an "angle bracket".

The "tick" aka Acute cccent: ´  Alt 0180

The "angle brace" aka Angle quotes: » Alt 0187

The "tick" will create a DIV element _and_ stopps at the first \n newline it finds

The "angle" will create P element, stopps at the first \n\n double-newline it finds.

There are a lot of classes predefined. you'll need to find the yourself. There is no docs atm.

Open all tiddlers and view them in edit mode with preview ON. You'll see what's going on.

eg:

´.r.j.c.cp Some test text

will create

<div class="r j c cp wltc-l1 wltc">Some test text </div>

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

´´´.r.j.c.cp Some test text

<div class="r j c cp wltc-l3 wltc">Some test text </div>

which is indented about 6em. .. Indentation should match bullet-lists.

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

´ii.r.j.c.cp Some test text

<div class="ii r j c cp wltc-l1 wltc">Some test text </div>

This example has the same visual output but creates differnt HTML code. It depends on the users taste, what will be used.

Using the "angel brackets" does the same things, _but_ using a P tag and stopping at double-newline.

There are 5 new edit-toolbar-buttons: Only 3 have shortcuts atm. You can assign them at the Control Panel

from left:

  - Add 1 new-line at the end of the line, for all selected lines.

  - Remove a "tick"

  - Add a "tick" at the _start_ of the line

  - Remove and "angel brace"

  - Add an "angel brace"

 

Remove actions will also remove spaces at the start of the line. ... This may change in the future.

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

The site  also contains the space-space-newline pugin, that creates hard line breaks using

 - space-space-newline  or

 - space-space-backslash

There are  2 tiddlers

 -  test-hard-linebreak-and-transclusion

 -  nl-is-hard-linebreak

That test a different way to crate hard linebreaks. NO plugin involved!!

========================

I'll update the link frequently .. Hopefully with some more docs and new functions.

Planned:

 - test if it's possible to use ---  aka HR instead of \n\n as a stop-indicator.

 - test if it's possible to use pragmas to use different HTML tags instead of DIV and P

 - test if it's possible to use a pragma to define the stop-indicator

 - test if it is possible to create a wrapper element and call a macro using the text as the ONLY parameter

That's it for the moment.

have fun!

mario

PS: Yea I know my page has a typo. I named it "angel bracket" .. and I'm not sure if I'll fix it ;)

[1] WikiLabs - tick-text

[2] Initial Thread with Tony and me

[PMario]

Hi,

Did anybody test it? .. Or is it too complicated? ...

If this simple version can't be tested, what will happen if the advanced stuff is published?

-mario

[Mat]

PMario, I'm looking at it right now. (I wrote a private message to you earlier today via the board about looking at it tomorrow, did you not get it?) I will look at it more closely tomorrow when I'm not so tired but a first glance looks really cool!!! Here are some very quick thoughts:

The class names there are of course cryptic but I note I can easily create my own.

I note the difference between the tick and the quote e.g for this text

aaa aaaa aaaa
bbb

...but since that single linebreak disappears when I use the quote, what's the point in making a distinction between if it stops at \n or \n\n? I mean, you can't get the \n to show up anyway so why would one use it?

More tomorrow. This is a great start!

<:-)

[TonyM]

Mat,

you can't get the \n to show up anyway

I noticed in the HTML preview tabs are actually displayed,  I recall earlier word processes allowing you to display symbols in the page such as tabs, new lines and paragraphs. Perhaps a special preview that did would be useful?

Regards

Tones

[TonyM]

Mario,

I am reviewing this now. From my perspective it is very very good, for an author to quickly format the output, build their own easy styling shortcuts.

Notes;

• this tiddler has no $        ":/plugins/wikilabs/tick-text/styles"
• We need to get naming clear 
• <tick> ' for turning a line into a div
• <angle quotes>  » for paragraphs
• To me  The "angle brace" aka Angle quotes: » Alt 0187 just does not sound correct although it is official?
• I have a class defined .cb { color: blue; } /* Text color blue /*
  • » .cb does nothing?
  • ´.cb does nothing? 
    
  • :::.cb.rrr works but for the blue?
    
• I would like a  The "angle" will create P element, stops at the first \n newline it finds.
  • Because it will change \n\n to `<p>content</p>\n <p></p>` which suits me because additional new lines collapse into one line between paragraphs

The editor toolbar buttons need the add before the remove, perhaps a simple list-before 

$:/plugins/wikilabs/tick-text/EditorToolbar/add-newline

$:/plugins/wikilabs/tick-text/EditorToolbar/add-tick

$:/plugins/wikilabs/tick-text/EditorToolbar/remove-tick

$:/plugins/wikilabs/tick-text/EditorToolbar/add-angel

$:/plugins/wikilabs/tick-text/EditorToolbar/remove-angel

Could my custom classes not be working because the result is as follows?

• » .cb does nothing?
• ´.cb does nothing? 

`<div class="cb wltc-l1 wltc">` and your classes replace the inline provide calls? 

eg `<div class="wltc-l1 wltc cb">`   

I continue to work on related ideas.

eg; Setting the css in a tiddler and allowing it to be toggled between the required css or display: none; 

Regards

Tones

[PMario]

On Tuesday, September 1, 2020 at 4:19:32 AM UTC+2, TonyM wrote:

...

• this tiddler has no $        ":/plugins/wikilabs/tick-text/styles"

 That's intentional. It is still part of the edition, but needs to go to the plugin. Removing the $ will keep the tiddler visible while development goes on.

• We need to get naming clear 

 that's right

• <tick> ' for turning a line into a div
• <angle quotes>  » for paragraphs

 that's the intention atm. I'm testing pragmas atm. ... But it seems to be more complicated and not less.

• To me  The "angle brace" aka Angle quotes: » Alt 0187 just does not sound correct although it is official?

I like to call it "angel quotes" ... We could name them Frensh or Swiss quotes. I know they use them. .. German books sometimes use those quotes too.

• I have a class defined .cb { color: blue; } /* Text color blue /*
  • » .cb does nothing?

no space between  the indicator and the class: ».cb should do

• • ´.cb does nothing? 
    

Are you sure you did set the $:/tags/Stylesheet tag? I did test it. It works for me.

• • :::.cb.rrr works but for the blue?
    

I don't understand this question

• • 
    

• I would like a  The "angle" will create P element, stops at the first \n newline it finds.

  Because it will change \n\n to `<p>content</p>\n <p></p>` which suits me because additional new lines collapse into one line between paragraphs

That may be possible with the "tick" in the future.

 

The editor toolbar buttons need the add before the remove, perhaps a simple list-before 

$:/plugins/wikilabs/tick-text/EditorToolbar/add-newline

$:/plugins/wikilabs/tick-text/EditorToolbar/add-tick

$:/plugins/wikilabs/tick-text/EditorToolbar/remove-tick

$:/plugins/wikilabs/tick-text/EditorToolbar/add-angel

$:/plugins/wikilabs/tick-text/EditorToolbar/remove-angel

In my brain they need to be the other way around, as they are. .. You can use the <<tag "$:/tags/EditorToolbar">> dropdown to sort them according to your liking.

 

Could my custom classes not be working because the result is as follows?

• » .cb does nothing?
• ´.cb does nothing? 

If you insptect the element with right-click: Inspect Element, they should have the class wltc-l1 and wltc

`.i.cb should indent the paragraph. So you know the detection works.

 

`<div class="cb wltc-l1 wltc">` and your classes replace the inline provide calls? 

eg `<div class="wltc-l1 wltc cb">`   

It worked for me. So there needs to be a different problem.

-mario

[PMario]

On Tuesday, September 1, 2020 at 4:19:32 AM UTC+2, TonyM wrote:

...

Could my custom classes not be working because the result is as follows?

• » .cb does nothing?
• ´.cb does nothing? 

Yes.

» needs 2 newlines. It will "eat" the next line and since there is 1 space too much nothing turns blue. Use this

».cb does nothing?

´.cb does nothing?

or

´.cb does nothing?

».cb does nothing?

-m

[PMario]

@Tony,

I think for your usecase you should always use the "tick" version.

The "swiss quote" is for everyone else ;) It may be the default. ...

I'm not sure if I should splitt them into 2 plugins. .. But this will cause code and CSS duplication, which shouldn't happen.

-m

[PMario]

On Tuesday, September 1, 2020 at 9:50:51 AM UTC+2, PMario wrote:

I think for your usecase you should always use the "tick" version.

As I wrote "tick" and may be "angel" should be able to use pragmas like this. ------Just an idea----------

\ticktext default end="---"

\ticktext name=x tag=p start=´ params=".c.cp" end=eee

\ticktext name=y tag=div

And be used like:

´ ! header 1

some more text

----

´.x Some text

! header 1

some more text as paragraph

eee

´.y same behaviour as it is atm.

BUT BUT BUT this functionality causes more problems than it solves. So "y" may be OK, but "x" may be removed.

@Mat

IMO this will be very close to the OP ?

-mario

[Mat]

@PMario

OK, so I'm testing things directly on your site. As noted, this is super cool and could become very useful.

I did publish an EXPERIMENTAL wiki [1] at wikilabs, that contains 3 new wikitext elements.

I understand these three to be

´ = tick

» = angle quotes

space-space-newline

That last one is independent of the former, yes? However, this code does not render line break between 111 and 222:

».aaa 111   (ends with space space newline)
222

<style>
.aaa {background:red; display:inline-block; max-width:133px;}
</style>

 ...and using tick instead also shows no difference between space-space-newline and just newline.

The "tick" will create a DIV element _and_ stopps at the first \n newline it finds

The "angle" will create P element, stopps at the first \n\n double-newline it finds.

So, the point here is presumably that one is allowed to do \n and still keep the styling after. But, as noted, what is the point in allowing a \n when such a single linebreak is not seen in the rendered text anyway? I still cannot use one "command" to style two paragraphs (i.e separated by an empty row). Or can you give an example where ´ is insufficient but » saves the situation?

...or maybe you mean one also has to use your .h class that you bring up below, for the linebreaks?

 

´.r.j.c.cp Some test text 

will create 

<div class="r j c cp wltc-l1 wltc">Some test text </div>

So do tick and anglequote add extra classes beyond what the user specifies (wltc-11 etc)?

 

There are 5 new edit-toolbar-buttons: Only 3 have shortcuts atm. You can assign them at the Control Panel

IMO this is a pretty expensive compromise for not using more accessile markers. It is expensive in real estate and visually (four!). Note also that there's a Controlpanel setting to Show/hide the toolbar. I, for one, prefer it hidden. More cricitally I stand by my opinion that we should aim for Grubers goal as much as possible in that the authoring process should be minimally distracted and adding the marker should be as non-distracting as adding a list-bullet or a heading exclamation mark.

...or no marker; I don't think anyone answered why there needs to be a marker at all beyond just starting the line directly with 

.class My text

 

BTW, it is worth noting that all options also require an empty preceding row (except the very first line in editor). This is not a complaint, just a fact.

 - space-space-newline  or

 - space-space-backslash

There are  2 tiddlers

 -  test-hard-linebreak-and-transclusion

 -  nl-is-hard-linebreak

That test a different way to crate hard linebreaks. NO plugin involved!!

Nice! So that is done by adding the .h class if I understand. It works for angle quotes but not tick so, as noted above, maybe this is the practical outcome difference between angle quotes and tick?

 

Planned:

 - test if it's possible to use ---  aka HR instead of \n\n as a stop-indicator.

(Advantage: Visible in edit mode.)

 

 - test if it's possible to use pragmas to use different HTML tags instead of DIV and P

So would this mean one would also have to add pragmas as soon as one wants to use, say, ´.foo ?

 

 - test if it's possible to use a pragma to define the stop-indicator

Locally?

 

 - test if it is possible to create a wrapper element and call a macro using the text as the ONLY parameter

I'm kneeling in prayer.

 

PS: Yea I know my page has a typo. I named it "angel bracket" .. and I'm not sure if I'll fix it ;)

Angels are more interesting than angles so keep it ;-)

<:-) 

[Mat]

PMario wrote:

\ticktext default end="---"

\ticktext name=x tag=p start=´ params=".c.cp" end=eee

\ticktext name=y tag=div 

...

@Mat

IMO this will be very close to the OP ?

If the above is a global setting then it is possibly practical enough, yes. There's little chance a user will remember this syntax so maybe it would need a little UI to hide the parameter names etc. (Idea, that I did't think through: Maybe local tiddler custom fields could be used somehow, comparable to the class field?)

<:-)

[Mat]

TonyM wrote:

Mat,

you can't get the \n to show up anyway

I noticed in the HTML preview tabs are actually displayed,  I recall earlier word processes allowing you to display symbols in the page such as tabs, new lines and paragraphs. Perhaps a special preview that did would be useful?

I'm not talking about a visual representation of the end of line character. I meant that neither the angle quote nor the tick results in a rendered line break when the text contains a newline. I.e the angle quote simply disregards a newline just like wikitext normally does and the tick ends from a newline (thus resulting in a visual brake with an empty row). So you can't get a new line by inserting \n (i.e by breaking the line and continue to type on the new row). 

<:-)

[TonyM]

Mat,

I must say I am finding the discussion a little overwhelming despite being a key proponent of this.

I noticed in the HTML preview tabs are actually displayed,  I recall earlier word processes allowing you to display symbols in the page such as tabs, new lines and paragraphs. Perhaps a special preview that did would be useful?

I am talking about a visual presentation (I understand you are not) perhaps a preview that allows one to see the hidden characters assumed in the output, if you look at the raw html output (preview addition core plugin

Internals: Tools for exploring the internals of TiddlyWiki) from there you can see how tabs are represented. It Just allows us to see the invisible.

 

I'm not talking about a visual representation of the end of line character. I meant that neither the angle quote nor the tick results in a rendered line break when the text contains a newline. I.e the angle quote simply disregards a newline just like wikitext normally does and the tick ends from a newline (thus resulting in a visual brake with an empty row). So you can't get a new line by inserting \n (i.e by breaking the line and continue to type on the new row). 

I think I understand why this seems an issue, but as you know we are forced to use \n\n between normal lines/paragraphs just to stop them collapsing back into one paragraph at render. The missing piece is the ability to call any line not using another wikitext prefix like * or # or ; or : to be treated as a separate entity, that why responding to the first \n is so important. 

Having the facility to cause a \n\n to appear at the end of a line is a valid, but opposite need to what I see at the original need. The thing about paragraph tags is one or more empty paragraphs collapse into one blank line between each paragraph with text, so prefixing a set of lines with wiki text to cause a paragraph is a quick way to tidy up pasted content.

Regards

Tones

[TonyM]

Post Script,

I used the P or paragraph here, but Mario wisely pointed out the use of div (with CSS), so you can nest things.

Regards

Tony

[PMario]

On Tuesday, September 1, 2020 at 12:08:01 PM UTC+2, Mat wrote:

PMario wrote:

\ticktext default end="---"

\ticktext name=x tag=p start=´ params=".c.cp" end=eee

\ticktext name=y tag=div 

...

@Mat

IMO this will be very close to the OP ?

If the above is a global setting then it is possibly practical enough, yes.

The global settings are the default settings. ... pragmas are for special usecases and they have to be part of the tiddler, to make export import possible. Otherwise users will always forget, what to export.

I think the TW "stamp" utility is under-rated. So may be the plugin should contain a predefined "stamp" setting. You'll need to remind me, if I forget about it ;)

 

There's little chance a user will remember this syntax so maybe it would need a little UI to hide the parameter names etc. (Idea, that I did't think through: Maybe local tiddler custom fields could be used somehow, comparable to the class field?)

If it gets too complicated users should use macros or @@ instead. ... The wikitext thing has to be easy and also limited. The more configuration options we have, the more complicated it gets.

-mario

[Mat]

The global settings are the default settings. ... pragmas are for special usecases and they have to be part of the tiddler, to make export import possible. Otherwise users will always forget, what to export.

OK, so the pragmas will be to add to, or overwrite, the global settings then?

<:-)

[PMario]

On Wednesday, September 2, 2020 at 10:55:26 AM UTC+2, Mat wrote:

The global settings are the default settings. ... pragmas are for special usecases and they have to be part of the tiddler, to make export import possible. Otherwise users will always forget, what to export.

OK, so the pragmas will be to add to, or overwrite, the global settings then?

 

There are _no_ global configTiddlers atm and I'm not sure if I can create some. ... configTiddlers can create variables, that can be used by widgets.

But at parsing time, when pragmas are executed, there are no widgets and variables yet. They come much later in the process.

So I'm not sure, if parsers have access to variable settings. ... I probably could load tiddler content from the wiki. BUT this will be quite some overhead and I'm not sure if I want to slow down the parser.

I'll have to have a look.

New test-version will be uploaded today (hopefully). .. It can do crazy stuff. ... but it also can create RSODs if parameters are missing or wrong :/ ...  so some more testing is needed. eg:

\ticktext tick="d" tag="details" params=".notop.c.cl" endString="---" mode=block
\ticktext tick="s" tag="summary" params=".-m"

´.d ´.s Details - Summay
line 1  
line 2  
adsf
---

Will give this html code:

<details class="notop c cl wltc-l1">
  <summary class=" -m wltc-l1 wltc">Details - Summay</summary>
  <p>line 1<br>line 2<br>adsf </p>
</details>

I think that's cool BUT ... the first line is "ugly" at least for me. ... So I'm not sure, if a macrocall wouldn't be more userfriendly

-mario

[PMario]

Hi, I did modify the last post. Changed code a little bit.

-m

[PMario]

Hi,

Version updated: 0.0.2 at: https://wikilabs.github.io/editions/tick-text/

-mario

[PMario]

It's Version 0.0.5 now. Did mess up the hard linebreak CSS should be OK now

[Mat]

We need to make a distinction between two major use cases:

1. tiddly fiddling
2. taking notes / authoring

For tiddly fiddling such as coding or working on a website etc, it is OK with intricate constructions and looking up commands etc.

For note taking or topic-focused authoring it is not reasonable to force the author interrupt his topical flow with "system things". It is this latter case that I'm concerned about.

The complexity of things have to "take place" somewhere. The difference between the two use cases is that #1 can have complexity at front and be exposed to it but for #2 it MUST be hidden. IMO your prevous demo with syntax

´.i.r.j.c.cp

...is "pretty close to good" for user #2: Now, I'm assuming he can create custom classes (when he eventually switches over to fiddling). When taking notes or authroing you only need a few recurring classes, so they can be directly named e.g "details" and "summary" etc.

BUT for user #2 the indicator (´) has to be as easy to type as most other things. I guess tick is OK but having to use a sepate tool for it is IMO a no-go because it totally hijacks your attention. SO what are the options for indicators? I've asked if a single period (.) could work but I take the silence to mean "no". How about a period AND some other standard character, even a letter or a word, e.g:

.D My text

-or-

.DETAILS My text

This make things very clear both when authoring and when reading the code. It is fairly close to markdown. And the specific indicator can itself bring default styling! In other words, there would be multiple indicators, but one would likely only need very few. One could potentially add actual style classes to it like so:

.DETAILS.red My text

The first period doesn't mean anything by itself. The second period means the same as the periods in your .c.cp.foo cases. ()

Again, this is very clear and there's minimal hijacking of brain compared to defining pragmas, clicking buttons, or adding multiple classes.

As for breaking at newline vs space-space-linebreak, if it is not already baked into the command, this could also be commanded here:

.DETAILS.NEWLINE 

vs

.DETAILS.PARAGRAPH

(or some abbreviations)

The user must take care to not define class names that overlap with these "command names". One could argue for using some other prefixing symbol than the period, so to not confuse the commands with the classes BUT, again, an author or note-taker is only likely to use a few such commands and there is less distraction precisely because it uses the very same character, i.e the period. The author should not spend brain power on thinking about such technical distinctions.

Thoughts?

<:-)

[@TiddlyTweeter]

Ciao Mario

Looking very good on v .5. Using the \ticktext (pragma?) example I can see how the approach allows enormous flexibility. Clever & neat.

I'll try it practically over next few days & give proper feedback.

Best wishes

TT

[@TiddlyTweeter]

Mat wrote:

For tiddly fiddling such as coding or working on a website etc, it is OK with intricate constructions and looking up commands etc.

 

For note taking or topic-focused authoring it is not reasonable to force the author interrupt his topical flow with "system things". It is this latter case that I'm concerned about.

Right. But looking at Marios extant solution it supports BOTH approaches.

In the case of Joe Get-On-With-It Writer pre-created consolidated classes, probably one with a proper name, could be supplied for common writing situations.

The more complex approaches could be used by developers and technical minded writers. 

BUT for user #2 the indicator (´) has to be as easy to type as most other things. I guess tick is OK but having to use a sepate tool for it is IMO a no-go because it totally hijacks your attention. 

"." in earlier discussions was put aside because, I believe, even if you could get it to work, there could be confusion with class naming.

I too would prefer a character found on all Western keyboards. I do like ".", partly because its a not uncommon line starter in various types of markup. That said I'm not sure its optimal for TW. Not sure.

Even though "acute accent" is not on my keyboard I'm not adverse to it. I'd just initially create lines of the full code I want to preface a line with in the STAMP TOOL.

The thinking here is that actually you would often/usually(?) add more than a character (UNLIKE Markdown), but a trigger character Plus a class?

Finally, on that, could the character default to  acute accent but option to use another? Maybe breaks portability?

 How about a period AND some other standard character, even a letter or a word, e.g:
.D My text
-or-
.DETAILS My text
This make things very clear both when authoring and when reading the code.

Ermmm. Actually I think that is potentially confusing as .D is not necessarily a style per se, but a trigger.

Marios cases so far cover "single non alphabet character" trigger with or without classes AND richer "pragma"(ish) very flexible approach. 

I like both. But need work a while to get really clear about issues in actual writing.

But for your case #2 I think it is most consistent with extant WikiText to use a single "glyph/symbol" rather that bringing letters into it.

Thoughts,

TT

[PMario]

On Wednesday, September 2, 2020 at 5:48:12 PM UTC+2, Mat wrote:

We need to make a distinction between two major use cases:

1. tiddly fiddling
2. taking notes / authoring

That's right, but we are at alpha stage at the moment.

 

´.i.r.j.c.cp

you can open the CSS class definitions and you can see: j .. stands for text-align: justify.

So if you change the CSS to

/* Text alignment */

.j, .justify { text-align: justify; }

You can use both. .. the string would be something like:

`.justify.indent1.right-margin.cbox.cbox-primary your text goes here.

I personally like the short versions more, because they are compact and much less to type.

That's pretty close the "Tailwind" approach, that you brought up here in the group. ...

 

BUT for user #2 the indicator (´) has to be as easy to type as most other things. I guess tick is OK but having to use a sepate tool for it is IMO a no-go because it totally hijacks your attention. SO what are the options for indicators? I've asked if a single period (.) could work but I take the silence to mean "no". How about a period AND some other standard character, even a letter or a word, e.g:

I did probably write it 2 times here. The DOT is _not_ possible. It will clash with tiddlers tagged $:/tags/Stylesheets ... Every class name starts with a dot. If users would start their stylesheets with:

\rules only filteredtranscludeinline transcludeinline macrodef macrocallinline

Which is done by most TW core CSS definitions. It would be OK. BUT have you ever seen a user stylesheet, that started with the string above? ... I didn't and I personally don't use this string either, but it would be the only thing a dot at the start of the line wouldn't break users wikis.

So that's why we CAN'T use dots at the beginning. We could use <dot><space> ... But that is super ugly and super error prone.

.D My text

-or-

.DETAILS My text

We have to use "angel" brackets » for standard users and / or the "tick" ´  for "advanced" users. I did create buttons and there will be keyboard shortcuts. .. So it should be simple to type them.

 

This make things very clear both when authoring and when reading the code. It is fairly close to markdown. And the specific indicator can itself bring default styling! In other words, there would be multiple indicators, but one would likely only need very few. One could potentially add actual style classes to it like so:

 

.DETAILS.red My text

The class names are just a convention. You can make them as long or short as you wish. See my example above.

 

The first period doesn't mean anything by itself.

.. It does mean something. Otherwise you could remove it without a problem. TW pars needs a "special" character, so it can recognize that something "special" needs to happen.

 

The second period means the same as the periods in your .c.cp.foo cases. ()

That's right.

 

Again, this is very clear and there's minimal hijacking of brain compared to defining pragmas, clicking buttons, or adding multiple classes.

You have to define the pragmas, otherwise nobody would know what you want to do. The next version will hopefully be able to import pragmas from tiddlers.

 

As for breaking at newline vs space-space-linebreak, if it is not already baked into the command, this could also be commanded here:

.DETAILS.NEWLINE 

vs

.DETAILS.PARAGRAPH

(or some abbreviations)

space-space-newline will be a separate plugin. If you use ´.h or ´.hl you can do almost the same thing without the need for the plugin.

eg:

».h line 1

line 2

line 3

It uses these CSS settings: https://wikilabs.github.io/editions/tick-text/#nl-is-hard-linebreak-css

For me the above looks much nicer then the existing code. ... _And_ it can do much much more

"""

line 1

line 2

line 3

"""

 

The user must take care to not define class names that overlap with these "command names". One could argue for using some other prefixing symbol than the period, so to not confuse the commands with the classes BUT, again, an author or note-taker is only likely to use a few such commands and there is less distraction precisely because it uses the very same character, i.e the period. The author should not spend brain power on thinking about such technical distinctions.

As I wrote. You can make your commands as long / short as you want.

BUT

You have to start the line with a "tick" or an "angel" quote, except someone comes up with a better character that we don't use already! The parser needs it. The planned end result will hopefully look like this:

configTiddlerDetailsHTML

\ticktext tick="d" tag="details" params=".notop.cbox.cbox-primary.hl" endString="---" open mode=block

\ticktext tick="s" tag="summary" params=".-m"

\ticktext tick alias="´.d ´.s"

Usage tiddler 

\importpragmas configTiddlerDetailsHTML

´ Summary Text

line 1

line 2

-------

And you can have as many <details><summary> elements in 1 tiddler as you like. All of them start with a tick.

As you can see the configTiddler has completely redefined the meaning of the "tick" char.

If you want to have different behavior you have to give it a unique identifier. eg

´.d or ´.details or ´.aside or ´.a or ´.paragraph or ´.p or ´.p.i for and indented paragraph with some special styling.

... And please don't tell me that

´ Summary Text

line 1

line 2

-------

or

´.details Summary Text

line 1

line 2

-------

is complicated to write for a user. BUT they have to know, what to import, and we have to provide them with some basic config, that works out of the box. ... Without any CSS name clashes.

have fun!

mario

[PMario]

Hi,

The keyboard definitions are definitely a problem.

I personally would like to get an E2 keyboard as described in https://de.wikipedia.org/wiki/Tastaturbelegung#Tastaturbelegung_E2. That would be cool.

I will try to create a configuration for windows 10 for my existing one, but I'm not sure, how the new "level 2" chars (the red ones) will work. We will see. 

-mario

[Mat]

PMario wrote:

You have to start the line with a "tick" or an "angel" quote, except someone comes up with a better character that we don't use already! The parser needs it.

My point was not to use dot as the indicator but instead use the full string (that includes the dot) as indicator. And it doesn't have to be a dot prefix, it can be some other keyboard-accessible prefix (maybe _ or - ). The point with the prefix character is ONLY to make it "stick out" so the user (not the parser) doesn't mistake it for regular text. In other words, the indicator would not be one indicator but several indicators such as

_D or _DETAILS or _details

_S or _SUMMARY or _summary

...or, for that matter...

-§

These indicator strings would bring with them, i.e cause, a default styling (which, if I understand it right, the tick char or angle quote do not, by themselves). The default styles can be overwritten by the user, just like any other styles. Only a few such indicators are needed assuming they trigger a styling which can also be user customized. But I guess it is also neat if one can chain on additional suffixing classes like in your examples. The simple case though, comparable to adding a bullet, is only a single "_D" or "-§" indicator because these are directly available on everyones keyboard.

Do I misunderstand something? Is this not possible? You have to agree this would be superiorly simple to use.

<:-)

[TonyM]

Mario et al

We seem in different timezones, So a lot of water goes under the bridge while I am sleeping.

I like the look of your work and you are really extending it to meet all those fanciful ideas we discussed, so I am very impressed.

I am however getting a little confused because you are taking this so far, if you could make a summary of the state of play or more the current end game I would appreciate it. Then I can do through testing and review. If you can do this keep it short but list any inter dependencies if they exist (But I think you are avoiding those anyway)

As an Author

I have some real world demands to produce authored content right now so these "facilities" - Shortcuts, utility and custom CSS and new wiki text characters are not only fantastic but I can robustly test it as an author rather than a designer / hacker.

Keyboard shortcuts

I was looking at shortcut for tick and angle braces and Found some on the QWERTY keyboard that would suit me and every one

• alt-> for angle braces (Actually alt-period)
• alt-' for tick (alt single quote, In shift would be " quotes)

This highlights that such shortcuts may vary with keyboards and languages so although we may provide some defaults people should be encouraged to build there own.

Actually we build them and they can change the keystrokes.

These would be very quick to learn, the shortcuts only result in the special characters being entered at the cursor and need only be active in the editor. They can be documented in the Editor toolbar popups as well along with triggering the edit tool bar items.

Defaults and extensibility

Here is a quick description as I see users / authors may see it in future - intentionally leaving out the details

This solution provides the author of wiki text to use additional wiki text characters similar to the existing * # ! etc.. on any line in your wiki text, Editor toolbar buttons are provides to prefix one or more lines at a click with this additional wikitext symbols. To avoid clashes these characters are not available on all keyboards so and alt-keyname alternative is also provided to enter one of these new wikitext characters.

Depending on which new character you use, the line it prefixes will be transformed into a html div or p paragraph.

• But now on any line, in your text, you can follow the "special character" with .classname or even multiple .classname1.clasname2 (As with any existing wiki text character) and the classnames CSS will be applied to that line and than line only.
• A small set of CSS classes have being provided to get you started but to can delete, rename and add you own.

What this means for the author

As you type your content it is possible to quickly trigger the current line, or set of lines to be rendered as a HTML div or paragraph at render time, with one or more custom styles applied, for appearance of your layout. If you have a preferred style you wish to apply you can create your own class to apply. 

• For example you may want the class "q" to represent quotes from people. simply add a <tick>.q at the beginning or a line and at render it could be rendered in Italics with large Quote icons, indented from the left and right with the text justified and a grey background

For example on a given line, or range of lines, you could provide the class .i (indent) and .r (right-indent) ".i.r ", which would indent the line from the left and the right.

This means with the included examples or a little css knowledge, the Author can quickly create what is in effect custom markup for their text, all of which can be quickly entered at the keyboard. Who needs WYSIWYG?

Now?

Is it now complicated by defining your ow rule/special character?

Should we have a minimum viable product before we open tiddlywiki down another wonderful but infinite path?

Regards

Tony

[@TiddlyTweeter]

PMario wrote:

The keyboard definitions are definitely a problem. 

Absolutely agree. But I think that is not, or should not, get you bogged down. Its a very complicated issue entering characters not on a keyboard with LOTS of solutions, both specific to TW and more general OS/hardware setuos. The issue is finding, ideally, One Universal Approach that is cross-platform & cross-cultural, mobile, tablet & desktop. Despite lots of work on this over long time for TW a common path for all has not yet been fully laid out. Maybe for a different thread to explore?

FWIW, so far your v .5 on Windows  10 tablet (with either on screen keyboard or a type-cover keyboard) works well using either the buttons or the defined keyboard shortcuts (ctrl-0 & ctrl-9). But I think to get it working on all platforms might need more thought later?

Best wishes

TT

[@TiddlyTweeter]

PMario wrote:

New test-version will be uploaded today (hopefully). .. It can do crazy stuff. ... but it also can create RSODs if parameters are missing or wrong :/ ...  so some more testing is needed. eg:

\ticktext tick="d" tag="details" params=".notop.c.cl" endString="---" mode=block
\ticktext tick="s" tag="summary" params=".-m"

´.d ´.s Details - Summay
line 1  
line 2  
adsf
---

Will give this html code:

<details class="notop c cl wltc-l1">
  <summary class=" -m wltc-l1 wltc">Details - Summay</summary>
  <p>line 1<br>line 2<br>adsf </p>
</details>

Very impressive. Very useful proof. Though to make these may need the user to be more than a newbie I can already see that they could be used in a framework (global macros?/importable "pragma"?) where the user only needs to enter minimal "WikiText-like" code to achieve the effect. If that is so, ultimately, Mat & Tony's concern about user type #1 v type #2 should be minimal.

Enormously useful. Especially where you need to write documents that contain HTML that currently has to be manually entered. Supports good structure.

An example would be things written following academic style manuals for preparing texts where HTML like abbr, article, section, details etc are optimal.

Best wishes

TT

[Mat]

Adding to my post above (containing the clarification to make the indicator be a string rather than a character)

PMario wrote:

`.justify.indent1.right-margin.cbox.cbox-primary your text goes here.

That's pretty close the "Tailwind" approach, that you brought up here in the group. ...

In deed, and I like this possibility to chain atomic styles very much. Of course, if one authors e.g a book or other coherent text, there will probably be a very limited set that is needed (hence my point about a few ready made indicators that each bring their own style).

 

I did probably write it 2 times here. The DOT is _not_ possible. It will clash with tiddlers tagged $:/tags/Stylesheets ... Every class name starts with a dot.

Thanks, I missed this. I'm surprised though because I assumed the stylesheets tag was a prerequisite for the dot-classname to be interpreted as class names by the system - and if there was no stylesheet tag then this syntax didn't mean anything special...

<:-) 

[TonyM]

Mat,

I can confirm this "chain atomic styles" already works 

Create a stylesheet on tiddlywiki.com with the below CSS

and this works

:.q This is a quote
:.q.b This is a quote

Tiddler tagged $:/tags/Stylesheet

.b  { font-weight: bold; }


.i  { margin-left: 3em;}
.ii  { margin-left: 6em;}
.iii  { margin-left: 9em;}

.r  { margin-right: 3em;}
.rr  { margin-right: 6em;}
.rrr  { margin-right: 9em;}




.j { text-align: justify; text-justify: auto; }


.u { text-decoration: underline; }


.q { font-style: italic; }


.q::before {
  content: "“"; /* Insert content that looks to do */
  padding-left: 4px;
}
.q::after {
  content: "”"; /* Insert content that looks to do */
  padding-right: 4px;
}

In this example the .iii is obsolete because you can use .i.i.i 

However note the gap we are addressing here is allowing such cascaded classnames to be placed at the front of any line

Of note;

Font awesome and other CSS frameworks provide a lot of class names that can be used this way as well,

Many of Mohammad's classes in Shiraz can be used this way as well. 

• Perhaps Mohammad can document the classes to use this way rather than via macros.

Post script:

I privately messaged Mohammad who I had not heard much of lately and he is fine and well and not isolated by global Politics.

Regards

Tony

[Mat]

TonyM wrote:

I can confirm this "chain atomic styles" already works 

I did not realize this worked beyond @@ in native TW. Thank you!

However note the gap we are addressing here is allowing such cascaded classnames to be placed at the front of any line

Yes, I have to assume we're all clear on that point. My main point, in the latter posts, are that if the "indicator" can be a distinctive string rather than only a single character, then we don't need ticks or angle quotes. My interpretation is that the system can deal with multi-character indicators such as @@.

Possibly relevant is that tags in HTML5 can be arbitrary e.g <pretty> which is then styled like other tags, i.e no prefixing dot, e.g

pretty {background:red}

 ...and my interpretation is that TW converts e.g an asterisk * into <li> which in turn applies natively defined styling ...so shouldn't it be possible to turn, say, "_P" or "_PRETTY" into <pretty> which can apply other styling? I.e we don't have to adapt to the limited set of predefined HTML tags.

<:-)

[PMario]

On Friday, September 4, 2020 at 2:52:37 PM UTC+2, Mat wrote:

...

[...] My main point, in the latter posts, are that if the "indicator" can be a distinctive string rather than only a single character, then we don't need ticks or angle quotes. My interpretation is that the system can deal with multi-character indicators such as @@.

The problem is, that "distinctive stings" need to be part of the js code. So they are hardcoded. What if we don't provide the right "distinctive strings" It's not only 10 of them. Users will probably create combinations, we can't even think of.

You are right. The parser needs some "standardized" characters, so it can detect special behaviour.

Starting a line with PRETTY has absolutely no indication, that a user wants to create a new HTML element. It can be meant as prose text. Using elements like this, will give us way to many "false" indicators. We need to use something, that is _not_ common at the start of the line.

Due to the lack of available chars, that are not "aggressive" like @@ I did use "tick" and the "angel qoute"

Possibly relevant is that tags in HTML5 can be arbitrary e.g <pretty> which is then styled like other tags, i.e no prefixing dot, e.g

You can define <pretty class="">, which imo makes more sense then applying a default style to a new element. ... Browser specific default settings for HTML elements only caused problems in the past. ... That's the reason why TW uses a "normalize.css" as a "reset" to normalize the CSS for all browsers.

 

pretty {background:red}

Why would I only want a red background for the PRETTY element. I also want to style my <dangerous> element with a red background. Do I need to duplicate CSS code?

.pretty ... IMO does the job much better.

 

 ...and my interpretation is that TW converts e.g an asterisk * into <li> which in turn applies natively defined styling ...so shouldn't it be possible to turn, say, "_P" or "_PRETTY" into <pretty> which can apply other styling? I.e we don't have to adapt to the limited set of predefined HTML tags.

As above. That's not flexible enough. There is a reason, why everyone uses classes to style UIs.

Defining new elements with short names will probably cause problems in the future. If you have a closer look at WebComponents, you'll see, that they need to use very long TAG names, to avoid naming clashes.

With TW I personally would want to go with the standard HTML tags. They are standardized, and everyone knows what to expect. New elements only cause support requests, because nobody knows them. .. eg: Screen readers are probably not aware of them. ...

-mario

[TonyM]

Mario and Mat

I think perhaps we should consider generalising this now!

Here is a detailed and comprehensive solution I would like to see coming from this recent work.

[...] My main point, in the latter posts, are that if the "indicator" can be a distinctive string rather than only a single character, then we don't need ticks or angle quotes. My interpretation is that the system can deal with multi-character indicators such as @@.

Fair enough, but I find @@ for one, too distracting when editing, why use two characters (or is that four to close @@?)  when you can use one? 

 

The problem is, that "distinctive stings" need to be part of the js code. So they are hardcoded. What if we don't provide the right "distinctive strings" It's not only 10 of them. Users will probably create combinations, we can't even think of.

You are right. The parser needs some "standardized" characters, so it can detect special behaviour.

My approach feeding of both your ideas. 

If you had only one appropriate "escape" character you can code multiple behaviours by what you provide after that. An escape character is more reliable if people cant normally enter it via the keyboard, but a custom shortcut can insert any character and editor toolbar buttons can simplify this. 

• Perhaps not with the proposed tick and angle brackets, I would like to see the ability to
• escape character, provide html tag name (any name eg; div, p, even PRETTY) then allow a one or more .classnames 
• Eg using the aforementioned §
• §htmltag.classname.classname<space>
  
• Or if no tag is provided default to div (because p is a trivial alternative)
• §.classname.classname<space>
  
• §<space> would wrap from beginning of line to \n in a div
  
• §p<space> would wrap from beginning of line to \n in a p
  
• This would allow ANY special html and CSS markup to be added to any "line"
• Remember any html tag can already have css assigned to it, including made up ones, even use sophisticated conditionals eg the first pretty within a div, so more often than not just §htmltag<space> will be needed.
• To keep the solution comprehensive and consistent
• We also need a way to do this inline something §span.classname something else<space>§<space> and something else.
• Perhaps close at \n if places at the beginning of the line, if not at the beginning of a line ie inline, then close when you see § OR the \n which ever comes first. or use ".§" which closes and add a period, then only § need be placed after an existing sentence to end, and there will be less false positives.
• The above examples automatically close the html tag when it reaches \n
• We need a way to wrap a block of multiple lines and close the tag when a close indicator appears.
• Perhaps an option to close when it reaches \n\n only could be an option
• 
  
• This is not too transparent because you can actually see the html tag that has being chosen, even if the class name is not in front of you but in a stylesheet.
• Finally as Mario has already done, adding a default class (special-tagname) to the also has its advantages so §tagname.classname will result in <tagname class=".classname special-tagname"> Selected line/ text </tagname>

I hope this is as valuable suggestion to you as I think it is?

Post script.

With the above solution we can also;

Use the css content and psudo classes like the class "e" for errors

.e::after {

  content:" !";

}

Perhaps one day we could somehow use 

§a.classname https://tiddlwiki.com tiddlywiki.com to result in <a href="https://tiddlyiki.com">tiddlywiki.com</a>

to look like tiddlywiki.com ie feed content into the html tags attributes.

Regards

Tony

 

[@TiddlyTweeter]

Very, very useful thread!

I make a few comments.

PMario wrote:

Mat: 

 ... shouldn't it be possible to turn, say, "_P" or "_PRETTY" into <pretty> which can apply other styling? I.e we don't have to adapt to the limited set of predefined HTML tags.

Sure. Could be done. But WHY? I'd need to see example app that utilises bespoke HTML for a new purpose to be convinced of any value in that.

PMario

New elements only cause support requests, because nobody knows them. .. eg: Screen readers are probably not aware of them. ... 

Right. Also its obviously not portable. Whilst doing it through CSS of extant HTML elements would remain so. 

TT 

[@TiddlyTweeter]

TonyM wrote:

If you had only one appropriate "escape" character you can code multiple behaviours by what you provide after that. An escape character is more reliable if people cant normally enter it via the keyboard, but a custom shortcut can insert any character and editor toolbar buttons can simplify this. 

There are a lot of things packed into your suggestions :-) The core idea, though, looks very good to me! 

 

§htmltag.classname.classname<space>

... is neat in that § (or whatever glyph chosen) is consistent in terms of use with existing WikiText ... so ...

§<space>Text

... does something already to apply any defined CSS to default element inserted by § ... and this ...

§.offset.hilite<space>Text

... applies additional classes to default element for § ... and ... this ...

§aside.offset<space>Text

... creates a specific HTML tag (aside) and applies classes.

So far so good! Its (a) readable; (b) extends WikiText in a logical way; uses ONE  special character to provide full extensibility allowing HTML to be entered.

However, IMO the distinction between BLOCK elements & INLINE elements should maybe respected. So, maybe, one glyph for blocks (e.g. §) and another for inline?

BTW, one thing not commented yet is that it could be used in cases where you need to start a line with a WikiText glyph as straight text, for instance ...

# extant Wikitext OL/LI element rendered starting "1"

§ # -- this element's content starts with literal "#"

I will comment separately on the issue of the "scope" (block/inline/\n v. \n\n). I'm aware there are potentially quite complex things going on PMario would have to deal with.

But, overall, Tony, I thought your basic "markup" approach good for usage. 

Best wishes

TT

[Mat]

With the insight I got from Tonys earlier reply that our existing indicators can already be concatenated with further classes, I'm starting to wonder if this whole idea/discussion might be unnecessary, i.e:

Why is tick or angle quote better than merely using for example the :  i.e a colon, the <dd> element? This particular element is both pretty and totally accessible and only styled by the browser (right?) into:

display: block

margin-inline-start: 40px; 

We can instead write an explict class to override these values (to set identical values) but so that an end user easily can locate and modify them.

Just like with tick or angle quote, concatenating further classes to colon requires "dot-class-space" - so what would the advantage be with tick or angle quote?

Two things that tick/anglequote nor colon cannot do:

1) It doesn't work in the middle of a sentence. The @@ can. 

2) Do more than merely styling, like for example the pipe characters do to build tables.

So maybe the aim should be to address this instead?

<:-)

[Mat]

By the way - of possible interest:

https://mathiasbynens.be/demo/crazy-class

<:-)

[@TiddlyTweeter]

Mat wrote:

With the insight I got from Tonys earlier reply that our existing indicators can already be concatenated with further classes, I'm starting to wonder if this whole idea/discussion might be unnecessary

No. It isn't. :-) Because the thread is also concerned with inserting HTML too. Its the combination of insertion of HTML elements and classes where it really adds to WikiText IMO.

If all you need is class application then, yes I guess you (post Tony's post) don't need this thread. But if you interested in better leveraging HTML too this is a great thread.

BTW, it was a real surprise to me too, though, when Tony showed behavior already that ... from ...

;.big.b Data Term

:.s-caps Data Definition

... makes ...

<dl><dt class="Big b">Data Term</dt><dd class="s-caps">Data Definition</dd></dl>

The shock to me was: why I can't find anywhere in standard docs this is documented!

Q: is there is any reason it appears UNdocumented? Or I just looked in wrong place?

TT

[@TiddlyTweeter]

Mat wrote:

By the way - of possible interest:

https://mathiasbynens.be/demo/crazy-class

It IS interesting to think with. I'll comment on using Unicode characters (not for classes, but as WikiText markers), in a separate note.

Best wishes

TT

[@TiddlyTweeter]

TonyM wrote:

Perhaps one day we could somehow use 

§a.classname https://tiddlwiki.com tiddlywiki.com to result in <a href="https://tiddlyiki.com">tiddlywiki.com</a>

Footnote ...

Maybe. I think the issue here is whether the complexity of the WikiText for providing needed attributes to a parser could get so complex its no more efficient than directly entering the HTML. WikiText is readable shorthand that should follow a consistent patterning. You example looks like it could makes coding for <a> tags pretty complex--which [[site|target-address]] pretty much handles already??

Best wishes

TT

. 

[Mat]

@TiddlyTweeter wrote:

No. It isn't. :-) Because the thread is also concerned with inserting HTML too. Its the combination of insertion of HTML elements and classes where it really adds to WikiText IMO.

Which additional html elements do you need inserted? I.e beyond the ones inserted already by existing wikitext markup.

What would additional html elements enable in wikitext that you can't do already?

<:-)

[@TiddlyTweeter]

@TiddlyTweeter wrote:

... it was a real surprise to me too, though, when Tony showed behavior already that ... from ...

;.big.b Data Term

:.s-caps Data Definition

... makes ...

<dl><dt class="Big b">Data Term</dt><dd class="s-caps">Data Definition</dd></dl>

The shock to me was: why I can't find anywhere in standard docs this is documented!

Q: is there is any reason it appears UNdocumented? Or I just looked in wrong place?

UPDATE. It IS documented IMPLICITLY. See, for instance for blockquotes,  https://tiddlywiki.com/#Block%20Quotes%20in%20WikiText where its shown ...

<<<.myClass.another-class

Operating systems are like a brick wall for our minds

<<< Nobody

... renders ...

<blockquote class="tc-quote myClass another-class"><p>Operating systems are like a brick wall for our minds
</p><cite>Nobody</cite></blockquote>

But I see nowhere (yet) docs EXPLICITLY mentions that approach generalises.

Comment

TT

[@TiddlyTweeter]

THAT example also shows that there are ESOTERIC processes going on in TW parsing, a bit like going down a rabbit-hole :-). On blockquotes ...

<<<Alice

CREATES html for <cite> ...

<blockquote class="tc-quote"><cite>Alice</cite></blockquote>

Comment

TT

[@TiddlyTweeter]

Mat:

 What would additional html elements enable in wikitext that you can't do already?

For example, writing structured articles these elements work well...

main

article 

header

section (repeated for each section)

footer

aside

I can also see using the tool to create different ways to style existing elements. For instance (imagined, not anything agreed, where § opens section, --- closes it, ^encloses^ element I want to force through CSS to become inline)...

§section ^h2.sec Answer to Mat^ ---

Best wishes

TT

[Mat]

@TiddlyTweeter wrote:

Mat:

 What would additional html elements enable in wikitext that you can't do already?

For example, writing structured articles these elements work well...

Help me understand:

If you're going to write HTML-structured articles why would you use wikitext to begin with? Is the idea to somehow export the text after the wiki markup is converted into html tags? Then why not use the actual html tags?

What you ask for would require one special wikitext indicator per html-tag, right?, but your list is a totally arbitrary fraction of all html tags. Why does it not make more sense to, as I noted, just use the existing TW markdown and concatenate classes to achieve the styles of "main, article, header, etc"? Possibly introduce indicators for, div and span, but nothing else. Beyond that... why?

<:-)

[@TiddlyTweeter]

Mat wrote:

Mat:

 What would additional html elements enable in wikitext that you can't do already?

 

@TiddlyTweeter wrote: 

For example, writing structured articles these elements work well...

 

Help me understand:

If you're going to write HTML-structured articles why would you use wikitext to begin with?

Because its compact to write with. Its far less noisy than HTML. The usual reason.

 

Is the idea to somehow export the text after the wiki markup is converted into html tags? Then why not use the actual html tags?

Right. By using the conventions of standard HTML is creates documents that can be transferred well to other contexts. 

FYI, all I do is capture rendered HTML code. A button press to get it on clipboard and post to a context. The CSS is modularised so that I can inline it for the specific document if needed.

What you ask for would require one special wikitext indicator per html-tag, right?, but your list is a totally arbitrary fraction of all html tags.

Its just a sub-set illustrating items I'd use for ONE purpose. That is what you asked for. But potential insertion of any HTML tag is what I'd hope for.

NO. Hopefully no need for zillions of special WikiText characters! IF PMario finds TonyM's suggestion usable you'd only need one that could insert any tag (but there is an issue on closing tags that would need thinking through). Remember this is speculative, not yet fully doable. See my comment to TonyM here that illustrates the general idea https://groups.google.com/forum/#!msg/tiddlywikidev/bj_2E9ifYkw/9VYBKzrPAAAJ

Why does it not make more sense to, as I noted, just use the existing TW markdown and concatenate classes to achieve the styles of "main, article, header, etc"? Possibly introduce indicators for, div and span, but nothing else. Beyond that... why?

Mat, its a perfectly valid way of thinking to use CSS for everything. But I happen to like to use appropriate HTML to handle content division. That is what HTML is for too! It makes great sense for structured writing. I want to edit in TW in a way that I don't need to get swamped in HTML code! Simple, usual reason.

Hope that is clearer!

Best wishes

TT

[@TiddlyTweeter]

Eeek! The link I posted in last post went to the wrong place!

The link to my comments on TonyM's post, that suggests a "syntax" for universal HTML/Class insertion is here: https://groups.google.com/d/msg/tiddlywikidev/bj_2E9ifYkw/9VYBKzrPAAAJ

Best wishes

TT

On Sunday, 6 September 2020 08:59:21 UTC+2, @TiddlyTweeter wrote:

Mat wrote:

Mat:

 What would additional html elements enable in wikitext that you can't do already?

 

@TiddlyTweeter wrote: 

For example, writing structured articles these elements work well...

 

Help me understand:

If you're going to write HTML-structured articles why would you use wikitext to begin with?

Because its compact to write with. Its far less noisy than HTML. The usual reason.

 

Is the idea to somehow export the text after the wiki markup is converted into html tags? Then why not use the actual html tags?

Right. By using the conventions of standard HTML is creates documents that can be transferred well to other contexts. 

FYI, all I do is capture rendered HTML code. A button press to get it on clipboard and post to a context. The CSS is modularised so that I can inline it for the specific document if needed.

What you ask for would require one special wikitext indicator per html-tag, right?, but your list is a totally arbitrary fraction of all html tags.

Its just a sub-set illustrating items I'd use for ONE purpose. That is what you asked for. But potential insertion of any HTML tag is what I'd hope for.

NO. Hopefully no need for zillions of special WikiText characters! IF PMario finds TonyM's suggestion usable you'd only need one that could insert any tag (but there is an issue on closing tags that would need thinking through). Remember this is speculative, not yet fully doable. See my comment to TonyM here that illustrates the general idea https://groups.google.com/d/msg/tiddlywiki/GHbwtMIrA3I/eJyRkqyKAQAJ

[PMario]

On Saturday, September 5, 2020 at 11:58:02 AM UTC+2, Mat wrote:

Why is tick or angle quote better than merely using for example the :  i.e a colon, the <dd> element? This particular element is both pretty and totally accessible and only styled by the browser (right?) into:

If you use

: prose text that should be in a paragraph

to indent a paragraph, you are completely misusing the DD element, just because it visually fits.

This can completely mess up screen readers

The "angle quote" will allow you to fix this.

see: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dl for the real purpose of the DD element

and: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dd  ... see implicite ARIA role. .. definition

-mario

[PMario]

On Saturday, September 5, 2020 at 11:58:02 AM UTC+2, Mat wrote:

...

Two things that tick/anglequote nor colon cannot do:

1) It doesn't work in the middle of a sentence. The @@ can. 

Till now. I was thinking about the possibility to create a "tick-tick" start: ´´and end-marker´´. I think they are much prettier to read in plain text then @@

 

2) Do more than merely styling, like for example the pipe characters do to build tables.

Building tables in wikitext is THE most complicated parser logic in TW. I'm not sure, if the tick definitions can handle it. .. But I'll have a closer look. .. It will be a nice experiment. It probably could look like

´.table ´.caption Some caption text

».row

´.th.text-align-center header 1

´.th.tac header 2

´.th.tac header 3

».row

´.td.text-align-right cell 1 text

´.td cell 2 text

´.td cell 3 text

».row

´.td cell 1 text

´.td.text-align-xx cell 2 text

´.td cell 3 text

----

I need to test this. It should already work with my code base.

-mario

[PMario]

Hi,

If you copy this code:

\ticktext tick=table tag=table endString="---" mode=block
\ticktext tick=caption tag=caption
\ticktext tick=row tag=tr mode=block endString="-"
\ticktext tick=th tag=th
\ticktext tick=td tag=td

´.table ´.caption Some caption text
´.row

´.th.ac header 1
´.th.ac header 2
´.th.ac header 3
-
´.row

´.td.text-align-right cell 1 text
´.td cell 2 text
´.td cell 3 text

----

to https://wikilabs.github.io/editions/tick-text/ it works already with V0.0.5 \o/

[Mat]

PMario wrote:

... misusing the DD element .... can completely mess up screen readers 

The "angle quote" will allow you to fix this. 

OK... if it was only a more accessible character. The tick is OK (with my keyboard)... but the anglequote and toolbarbuttons etc... not good IMO... Can't instead ; and : be redefined into divs with the current dt/dd default styling - but so that they can also be user customized freely?

1) It doesn't work in the middle of a sentence. The @@ can. 

Till now. I was thinking about the possibility to create a "tick-tick" start: ´´and end-marker´´. I think they are much prettier to read in plain text then @@

I agree that's pretty. Cool with mid-sentence possibility!

2) Do more than merely styling, like for example the pipe characters do to build tables.

Building tables in wikitext is THE most complicated parser logic in TW. I'm not sure, if the tick definitions can handle it. .. But I'll have a closer look.

My mention of tables/pipechars was ONLY to give a concrete example of wikitext markup that does more than mere styling. What I'm after is a general ability to trigger "functionality" (macros? js?) via markup to operate on the text, i.e something that does more than mere applying of a html tag and styles.

So, as I now comment on your table idea, please don't forget that my mention of markup tables was only an example.

´.table ´.caption Some caption text
».row
´.th.text-align-center header 1
´.th.tac header 2
´.th.tac header 3

1)

Pipe characters are very pretty but also very intuitive for tables. This is missed out here.

2)

I guess your variant would solve this issue: https://github.com/Jermolene/TiddlyWiki5/issues/2941 

 

3)

Could it be possible to use the fact that 

´.table
...
\n\n

is a "micro environment" so that you don't need more ticks inside there? I.e .row without anglequote and .td without tick. The environment already makes it clear what it is. I guess this means that ´.table would need to be parsed as a predefined unit.

<:-)

[TonyM]

All

Thanks for the support and debate.

On my mobile now I have to enter desktop mode just to reply.

I will make a few quick comments and reply in detail with any gaps.

1st mat. The key need for a special character it to use it on "any other line".

Any line for which you do not have a wiki text character.

We need an escape character to do this without confusing it with existing markup.

You can apply smart classes and multiples where every you want.

So go for it. I allready do on * ; and : all the time.

I like this

*.done item here

*.do second item here

.done gets a css prefix of a checked check box

.do gets a green line with a css prefix unchecked check box

In text add "ne" to "do" to get "done", I like it!

Mario knew multiple .classname.classname2 was available. Thank him.

The original project Mario and I was on was to get a dot paragraph.

Ie start a sentence with a do and it treats until \n as a paragraph.

It took some time already to establish tick may be needed.

then together we came to a similar position to what you see now.

I hope Mario knows this argument now but we can still proceed.

My most recent position argues why define a tick paragraph when

you can use ticktagname.classname.class name2

Or the dot paragraph or dot div become

Tickp.classname.classname2

Tickdiv.classname.classname2

This opens up the whole method to an author doing what ever they want.

Of course they risk less transferable wiki text unless the share the class definitions

But that has always being the case and style sheets are often packaged with tiddlers

The thing is you can now design your own markup which ultimately helps any

Text get rendered the way you want. You can prefix any line either manually

By editor toolbar buttons or other automation

e.g. splitregex[\n] then out put with a prefic with no need to close.

Amongst my own wikis or where I publish my content or bundles I create

I will have full extensibility and what ever shorthand I want.

Later if the tick is in core plugins or core no class defined will be ignored and rendered as expected

With any html tag (including arbitary named html tags)

I have no time Personaly for the table pipe I use full html instead which won't be necessary

If I can tickth.w20 where w20 is a class with width:20%

Regards all

Love your participation.

Tones

[PMario]

A little bit of background

On Sunday, September 6, 2020 at 5:54:57 PM UTC+2, TonyM wrote:

The original project Mario and I was on was to get a dot paragraph.

Ie start a sentence with a do and it treats until \n as a paragraph.

Tony and I did hijack a thread in the GG, where Tony requested a possibility to style "copy pasted" content ... fast!

The initial idea was to start a line with a dot -> search the end of the line -> make it a paragraph. ...

After a little back and forth, I did create a new thread: (long thread warning) new parser rule proposed: dot-paragraph, where the idea was developed a little bit further.

Some code was created. .. A lot of misunderstanding was going on ...

In the end the project stalled for some time. ...

At the 26.Aug. I did PM Tony, to start the discussion again. I did have some more ideas and I didn't want to throw the code away. I thought, the ideas have some potential.

On 27th.Aug you (Mat) started this thread here and I thought it would be a fit. ... Not a 100% fit, but a fit.

And here we are. ... hijacking an other thread ;)

-mario

PS: I've updated to V 0.0.7 at: https://wikilabs.github.io/editions/tick-text/ - No docs yet - sorry - I'm starting it now. 

[Mat]

PMario wrote:

And here we are. ... hijacking an other thread ;) 

Haha, things are definitely on topic.

PS: I've updated to V 0.0.7 at: https://wikilabs.github.io/editions/tick-text/ - No docs yet - sorry - I'm starting it now. 

Maybe it'll clarify once there are docs but I'm testing the double tick you mentioned, attempting to get ´´.mid sentence styling´´ but I don't succeed in producing any.

<:-)

[PMario]

On Sunday, September 6, 2020 at 9:51:59 PM UTC+2, Mat wrote:

...

Maybe it'll clarify once there are docs but I'm testing the double tick you mentioned, attempting to get ´´.mid sentence styling´´ but I don't succeed in producing any.

That's not there yet. ... I'm still thinking about it. .. The problem is, how I want to deal with ´´.mid

-m

[PMario]

@Mat

V 0.0.8 contains a tick-inlie rule. ... BUT it will only work within text. It breaks at the start of the line.

See example. I'm pretty sure, this will cause problems.

-m

[PMario]

On Saturday, September 5, 2020 at 7:16:00 AM UTC+2, TonyM wrote:

...

My approach feeding of both your ideas. 

If you had only one appropriate "escape" character you can code multiple behaviours by what you provide after that. An escape character is more reliable if people cant normally enter it via the keyboard, but a custom shortcut can insert any character and editor toolbar buttons can simplify this. 

• Perhaps not with the proposed tick and angle brackets, I would like to see the ability to
• escape character, provide html tag name (any name eg; div, p, even PRETTY) then allow a one or more .classnames 
• Eg using the aforementioned §
• §htmltag.classname.classname<space>
  
• Or if no tag is provided default to div (because p is a trivial alternative)
• §.classname.classname<space>
  
• §<space> would wrap from beginning of line to \n in a div
  
• §p<space> would wrap from beginning of line to \n in a p
  

Hi folks,

It is possible to create names like this. ... BUT it's not implemented that way atm.

At the moment I'm using:

#1

´.name.classname.classname Text can directly start here ... or

´Text can start here.

Which is a little bit inconsistent. I know.

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

IF we use:

#2

´name.classname.classname There has to be a space after the indicator and class definitions.

´ Like so. Even if there is no name there has to be a space, otherwise the "Like" will be "eaten"

What do you think?  #1 or #2?

-mario

[Mat]

I need to sleep so can't test it today but wonderful that you're working on it!

What do you think?  #1 or #2?

Assuming the text in red here: ´name.classname does not refer to a classname, then #2 for sure. IMO the dot should only be before classnames here. Also, starting to type next to a classname without a space, like in #1, is weird and possibly error-prone.

Thank you PMario!

<:-)

[@TiddlyTweeter]

Though still early I wanted to comment on advantages of what PMario is working on (still in principle, but shaping well) that show the importance of this innovation ...

1 - Provides a general method to extend WikiText to insert any HTML tag & style it. ++++

2 - Gets around some of the strictures of standard WikiText using. For instance all existing  WikiText constructs that involve Nesting (the list & table tags particularly) though excellently designed have limits that PMario's "WikiText Extension" to can (in principle) handle to provide more functionality. +++

3 - Is a godsend where you to need switch off pragma because of use case. Why? Example: probably the worst pragma to switch-off is the Block Parse Rule for "list" because it disables ALL forms of list construct (*#:;). Example use case: Wiki concerned with posting to social networks where "#" is used all the time you need to switch off processing of "#". The "WikiText Extension" re-enables list constructs (not as elegantly as the Standard WikiText but a lot more useable than raw HTML). +++

That is three reasons already.

More?

TT

[@TiddlyTweeter]

Ciao PMario

One of the more interesting technical issues in what you doing on this is CLOSURES. That seems like a central issue in the possible variant cases?

I wanted to mention it, for example, because the Standard inline construct @@ ... @@ prohibits nesting. Its understandable as its <span>. But once you can insert different HTML nesting becomes doable inline. Is there a way to easily in a WikiText indicate nested scope inline?

Just a comment, not a demand.

The basic point is this: Elegant Tag Closure looks less than trivial in your Extended WikiText Tool than for Standard WikiText BUT seems very important to markup style?

I guess the issue is related to the final constructs (are one? two? three?) ... Its not easy thinking through user entry code patterns that is compact, yet not too limited.

Yes?

Best wishes

TT

[PMario]

On Monday, September 7, 2020 at 10:51:23 AM UTC+2, @TiddlyTweeter wrote:

3 - Is a godsend where you to need switch off pragma because of use case. Why? Example: probably the worst pragma to switch-off is the Block Parse Rule for "list" because it disables ALL forms of list construct (*#:;). Example use case: Wiki concerned with posting to social networks where "#" is used all the time you need to switch of processing of "#". The "WikiText Extension" re-enables list constructs (not as elegantly as the Standard WikiText but a lot more useable than raw HTML). +++

That's a strong argument, but I think it should be fixed in the core. +1 this issue https://github.com/Jermolene/TiddlyWiki5/issues/4841

-mario

[@TiddlyTweeter]

Ciao PMario

Agreed. But one can champion your solution UNTIL its fixed in core?

Happy my comment prompted you to post: https://github.com/Jermolene/TiddlyWiki5/issues/4841

TT

[@TiddlyTweeter]

Mat:

The tick is OK (with my keyboard)... but the anglequote and toolbarbuttons etc... not good IMO...

PMario:

For my own keyboard I need to compile custom windows settings without "dead" keys to get "ticks", "backticks" and others in a convenient way.

TonyM:

... shortcuts may vary with keyboards and languages ...

TT: § is on Italian keyboard on touchscreen PC for Windows. But not for  either English or Extended English. The PMario tick isn't on any of them. 

Background. (1) Smallest screen size has changed since MarkDown & WikiText were invented (result: different "quote" characters are a problem READING on a small screen); (2) Available characters have changed with the vast expansion of font support for the even vaster Unicode expansion; (3) Most keyboards are now onscreen (Android); (4) These developments SHIFT focus from "what does the user's keyboard support?" to "__what do the user's fonts support?__" (i.e. a lot of the time a usable glyph CANNOT be accessed through a simple keyboard but only through fetching it via a program); (5) Most characters from old USA/European keyboard approach are eaten-up for markup, WikiText is struggling to find the remainders.

Okay. That is a lot of contentions. But I think broadly right.

SO how to choose workable markup characters for PMario's WikiText Extension? I'll write about my experience next.

Best wishes,

TT

[PMario]

Hi TT,

Be aware of the 5 new toolbar buttons. ... They should help a little bit.

The existing stamp tool may help too!

-m

[@TiddlyTweeter]

Absolutely right. We can deliver markup via TW itself via BUTTON and STAMP to everyone. And to desktop users using KEYBOARD utility for editor keys (with a bit of tuition).

The point I wanted to make strongly was that we can no longer ever assume the old keyboard method has relevance. It doesn't.

TT

[@TiddlyTweeter]

Ciao PMario

Since you understood what I was getting at I can "cut to the chase" ...

The problem with "tick" is most obvious on Android. I think adding yet another "quote like mark" to WikiText is asking for trouble on Android. :-).

The thing is that differentiating such marks on a screen a quarter the size of a cheese sandwich  is too much of a challenge :-) Putting this in context ...

` - backtick

' - singlequote (straight)

’ - singlequote (curled)

´ - tick (acute accent)

Now look at that on a mobile phone :-)

Logically I think its fine & works fine. Visually it should be avoided if at all possible? TBH "small screen" render needs to matter as that is what many people use.

I'll comment on markup for your great innovation later.

Best wishes

TT

On Monday, 7 September 2020 13:12:15 UTC+2, PMario wrote:

[TonyM]

Tt

With characters not on scrren a kbd short cut should do. As stated elsewhere using alt > which is actualy alt period is suffecient for the angle bracket and alt single quote for tick. We could have awhole set of alt existing characters that are similer to the special character we want. On mobiles  a ket board with alt keys is needed but i can acess via the tool bar instead.

Mario, kind of intresting if i use alt . To use angle brakets because alt-. P would almost be back to to our original working title og dot paragraph ;)

Tony

[@TiddlyTweeter]

TonyM

I think the issue with this is brought out on Android. I'm assuming we want a solution that will work out-of-the-box cross platform?

Your comment here is, I think ADDITIVE, in a good way. But is it for all platforms natively?

Just asking

TT 

[PMario]

On Monday, September 7, 2020 at 1:50:02 PM UTC+2, @TiddlyTweeter wrote:

...

` - backtick

' - singlequote (straight)

’ - singlequote (curled)

´ - tick (acute accent)

Now look at that on a mobile phone :-)

I don't have a big problem zu see the difference. .. There is a double qoute / single qoute combination "' ... which is a no-go on Android.

I don't have the "curled" single qoute on my Android keyboard. I don't have tick, backtick and other stuff. ... But honestly I don't use them on android anyway. I do write prose text only, since anything else is way to clumsy.

I need to create several more buttons now. I do have ´´.class some text´´ now, which needs its own button.

The behaviour _and_ the pragma names will be changed in the _next_ version V0.1.0. As you can see it will be _incompatible_ with the existing version.

´name.class.class<space> Is the new format for the "tick" now

»name.class.clasee<space> too

»»»»<space> ... Is still possible to indent a pragraph

´´´´<space>> ... Is _not_ possible anymore. There will be only 1 tick

´.i.i.i<space> ... will be used for indentation

As you can see <space> between the "symbol" and the text is mandatory now!!

´´Tick inline will work now at the start of the line´´ some more text

´´.class works already´´

\ticktext will be renamed to \tickblock

\tickdebug all / tick / angel ... no changes

\importpragmas ... no changes

\tickinline will be new .... may be with 0.1.1

´´name.class for tick-inline´´ will be new with 0.1.1 .. hopefully.

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

I'm open to suggestions for new names. _But_ It needs to be consistent ... See text below!!!!

plugin-name: tick-text

´ -> tick

» -> angel

\tickblock tick="xx"

\tickblock angel="xx"

\tickinline tick="xx" tag="span" ... SPAN will be the default .. xx is the symbol

\tickblock tick= tag= endString= mode= use= ... will be all the parameters

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

I'm not sure, if \tickblock should be able to call macros ... But I'm thinking ;)

-mario

[PMario]

As I wrote, my keyboard layout will soon look like this [1]. ... So I should be able to comfy work with almost any indicator proposed here ;)

[1] https://de.wikipedia.org/wiki/Tastaturbelegung#Tastaturbelegung_E2

have fun!

mario

[@TiddlyTweeter]

PMario wrote:

@TiddlyTweeter wrote:

...

` - backtick

' - singlequote (straight)

’ - singlequote (curled)

´ - tick (acute accent)

Now look at that on a mobile phone :-)

I don't have a big problem zu see the difference. .. There is a double qoute / single qoute combination "' ... which is a no-go on Android. 

Honestly PMario for such a great innovation a character that can be differentiated on glance from a puny quote mark is the proper solution.

We need a decent height for it for Android.

I'm still thinking but will comment as soon as I can before this is set forever.

Best wishes

TT

[PMario]

On Monday, September 7, 2020 at 4:52:58 PM UTC+2, @TiddlyTweeter wrote:

...

Honestly PMario for such a great innovation a character that can be differentiated on glance from a puny quote mark is the proper solution.

As I wrote ... I'll be happy to change it, if someone has a good idea.

 

We need a decent height for it for Android.

I could live with

° ... degree sign. It's easy to find on my phone and it shouldn't be at the start of the line in prose text.

I don't know about it as an °°inline°° indicator .. not sure.

 

I'm still thinking but will comment as soon as I can before this is set forever.

IMO it's open for discussion, till the docs is finished. ... ;)

-m