Issue: I'd like to talk about Markup---broadly

[@TiddlyTweeter]

It seems to me that TW's flex would support A THOUSAND MARKUP SYSTEMS.

But I think we need a debate to loosen the strictures. And also make clearer how TW parses.

To try open this up I want to comment that recently we had discussion of mediating imports to TW via Pandoc. Behind this is the idea of THE FORMATS. BIG sites we want to steal from in a renderable way via an intermediary.

All good.

I'm rather more interested directly in TiddlyWiki in advancing BESPOKE MARKUP. Markup systems that users invent for purposes directly in TW make typing content easier.

Does anyone know what I am talking about?

[PMario]

Hi,

As I wrote in the "What if?" thread, I think, it would be nice, if we (98%) adopt commonmark - markdown, and make the rest of the TW syntax (transclusions, widgets, ... ) a subset of the new syntax.

At the moment, the biggest problem of the TW parser is, that the "parse tree", that is created is _not_ lossless. So converting plain text to the internal AST looses the whitespace info.

So it's not possible to do:

TW syntax -> AST -> TW syntax, ...  with out loosing information. ... If we would have a lossles AST we could do the following:
TW syntax -> AST -> What If? syntax, ..... without transclusion, widgets, ...

If WhatIfMark would be a subset of TW syntax and TW syntax would be a subset of WhatIfMark we could do really crazy stuff.

The main downside is: That's completely incompatible, to everything that exists at the moment. So it would be a completely new system.

have fun!
mario

[Mat]

PMario wrote:

If WhatIfMark would be a subset of TW syntax and TW syntax would be a subset of WhatIfMark we could do really crazy stuff.

You're teasing us - what 'crazy stuff'? I'm too unknowledgeable in this area to understand.

 

The main downside is: That's completely incompatible, to everything that exists at the moment. So it would be a completely new system.

TWX... I long for the day. It should come at about the same time as the Singularity.

<:-)

[Joe Armstrong]

Just thinking out loud here ..

Tiddlers contain far more than markup. There's wiki text

with an embedded programming language and an implicit

environment (the DOM) to consider.

Some tiddlers are pure JS - which would make it difficult to port

to a non-JS system - some tiddlers with simple markup could be

transformed into other systems/language. But the

really beautiful ones would be tricky.

As I see it this is insanely powerful - you could interact

with graphics or the web audio API and do anything the browser could do

which make it a very difficult moving target to hit.

Having said that - a significant subset of tiddlers can be 

made with simple transclusion and filters - it might be nice to

have a portable subset of tiddlers that did not do anything too fancy.

Cheers

/Joe

[PMario]

On Saturday, March 10, 2018 at 11:37:04 PM UTC+1, Joe Armstrong wrote:

...

 

Having said that - a significant subset of tiddlers can be 

made with simple transclusion and filters - it might be nice to

have a portable subset of tiddlers that did not do anything too fancy.

That's right. One power of TW syntax is transclusions, widgets, macros ..., which don't exist in most other wikis. ...

But for example commonmark is defined in a way, that it only renders stuff that it understands.
A syntax, that it doesn't understand is just written as plain text.

So eg: **bold text,** <<macro-call>>    ....

In CM may be rendered as:   bold text, <<macro-call>>

Using TW it may be:  bold text, some more text.

The source code, is still human readable, and makes some sense. The rendered result is different, because the source contains some "fancyness"

If a tiddler content only uses syntax, that both systems can understand, it would be interchangeable without any visual differences.

-m

[@TiddlyTweeter]

from another thread, relevant here ...

Jeremy Ruston wrote:

... In retrospect I was far too influenced by Markdown back in 2011/12 when TW5 wikitext was first being defined.

Side note I want to make on just this point about Markdown. I remember when Markdown emerged (as an end-user / avid blogger) thinking "this is a godsend". But also, "this is likely to become a somewhat messy non-standard standard long-term" -- because its "just too easy." If you get what I mean?

Indeed the "floppiness" in implementations and the many mixed in add-ins to them (many platform dependent) I think shows that point.

IMO original Markdown really pushed forward an approach to being able to write and format in a way that still looked like normal writing.

But it wasn't on its own. There were several similar approaches already, but Gruber's philosophical take on it and his pragmatic understanding of normal writing conceits I think gave it great leverage and attention.

IMO, the longer term legacy is very messy.

And I'm in no way convinced that any Universal Salve (e.g. CommonMark), struggling with the variants for it, is going to work well enough to convince me there will ever be "one" workable universal approach to it. Indeed, I think Gruber's main point was "to be pragmatic" in the mess.

My question is this: HOW in TW, now, do we pragmatically, in the easiest way, best enable writers to write and format their texts in the ways THEY need?

Its completely nuts to think that writers should be limited to a good idea that emerged in 2011 when, now, we know a lot more and can do a lot more, EASILY.

Let's have an argument about this. :-)

Josiah

[@TiddlyTweeter]

As far as publicly documented wiki markup systems go TW is not much on the map.

It is NOT in the Babelmark Registry.

Nobody is bending to create convertors to it.

But TW's basic architecture is, in fact, VERY flexible.

In truth, its got an AGNOSTIC PARSER SYSTEM that could convert most anything to anything. This is unlike most other wiki systems which are far less modular or flexible.

IMO, we are under-selling TiddlyWiki's potential for variant markup.

In theory it would be possible to support many more markup systems than it currently does. And without major changes to its architecture.

Josiah

[@TiddlyTweeter]

Joe Armstrong wrote: Tiddlers contain far more than markup. There's wiki text with an embedded programming language and an implicit environment ...

Absolutely.

Part of the issue with discussing "Markup" is being clear what is what. Whilst stuff like the syntax for transclusions is another level than simple text substitution for html/css, in reality, for users it is empirically at the SAME level--its all about typing stuff into text that does stuff on render.

But much of the confusion/complication on conversion of different "Markup" systems stem from this--that at USER level there is one system of entry, but at programmatic level there can be several different things that are not so easy to "translate".

The originally stricter meanings of (narrow) "markup" & (programmatic) "syntax" have blurred.

Josiah

[@TiddlyTweeter]

One consequence of Markdown and other markups is its kinda, inadvertently, supporting an incorrect idea about writing and the nature of most documents.

The point is that most of them assume that we need to ADD EXPLICIT MARKUP in order to render texts correctly. The underlying idea is that "all documents are equally unstructured" so need markup help.

That is COMPLETELY INCORRECT.

Most documents folk write are within a TYPE that is already structured according to conventions. Parsers, given the correct document TYPE, can usually render a document correctly WITHOUT explicit markup. Markup ONLY being needed to force compliance when a section of text breaks the standard layout of the type.

A very good example of this is screenplays. Their plain text typed layout already mostly determines how (IMPLICITLY) they should be "marked up" for render. The Fountain Syntax for marking up screenplays is perhaps the best public example of a brilliant "Minimalist Markup"--mostly you need to add nothing explicit because the work is done simply by analysing the layout of the document.

Other examples would be most novels, much poetry and sophisticated legal documents.

These kinds of cases we should be able to support directly in TW quite easily, I think.

Thoughts
Josiah

[@TiddlyTweeter]

Its easy to forget that TiddlyWiki is NOT WikiPedia, it is NOT Github and it is NOT Reddit.

Rules of text layout for server based systems with SPECIFIC purposes make sense. All the big-name sites that use markup need ONE system. Its part of their function to have a consistent look and feel.

Not TiddlyWiki.

Whilst for its documentation and basic release its sensible to have one markup system, there is no need to be a slave to any specific markup methodology after that :-).

Just thoughts
Josiah

[Joe Armstrong]

Markdown solves the problem "make the input easy"

The problem(s) I want to solve are "make the output beautiful" 

and "make the output programmatically" when this makes sence

TW seems a pretty good compromise at these - For beautiful output

I'd have to turn TW in LaTeX of something - but I'll cross one

bridge at a time.

Cheers

/Joe

[Ste Wilson]

Overleaf.com had an article last month (month before..) about latex without latex using... Something...maybe python.. I'll admit it went over my head by could be worth a look.

[Ste Wilson]

Here we are.. Luatex
https://www.overleaf.com/blog/571-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different

[TonyM]

Josiah,

I agree with this argument, 

But I would like to add this nuance,  I do often want ways to ensure I have a consistent look and feel in a given solution.

Perhaps this is where people get confused, because they see having YAML yet another markup language as providing a consistent look and feel when all that is needed is some of our own personal standards.

Not withstanding the above, if we have tools available that help us provide consistent look and feel when we needed it, it can only be helpful. In some ways I rely on an understanding of TiddlyWikis standards to do this.

Tony

[PMario]

On Monday, March 12, 2018 at 5:16:00 PM UTC+1, @TiddlyTweeter wrote:

from another thread, relevant here ...

Jeremy Ruston wrote:

... In retrospect I was far too influenced by Markdown back in 2011/12 when TW5 wikitext was first being defined.

Side note I want to make on just this point about Markdown. I remember when Markdown emerged (as an end-user / avid blogger) thinking "this is a godsend". But also, "this is likely to become a somewhat messy non-standard standard long-term" -- because its "just too easy." If you get what I mean?

It actually is a standard type (since 2016) text/markdown (RFC 7763), and this makes it even stronger. The good thing, that markdown already had a lot of different dialects, as the standard was developed, they where also registered as markdown-variants (RFC 7764), which can be specified in the mime type. The variant servers as a hint for parser, what to do. .. If it doesn't know something, it just renders it as plain/text.

See: RFC 7764 - Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations

RFC 7764 also formalizes the registration process for MD-variants. ... So TW syntax, that is out of range in MD atm could be made a variant, imo without loosing functionality.

the mime type with a variant looks like this:

 Content-Type: text/markdown; charset=UTF-8; variant=Original

As you pointed out, there is a lot missing in "original" markdown, but now there is a formalized mechanism to register all kind of new very specific syntax additions. ... 
AND TW is _not_ one of them. So in the long run we will loose, if we don't do it right. 

As you pointed out. TW has the potential, to convert one syntax to an other (with some limitations). ... BUT ... not with the internal AST, that we use at the moment. 
See my first post. ATM we are loosing whitespace information. 

just some thoughts
mario

[@TiddlyTweeter]

This discussion is really interesting!

One thing is more clear to me, from the excellent, relevant replies, is how discussion of "Markup" quickly invokes multiple issues: amongst others, conversion, compliance standards, nice styling & working-practices.

I'm thinking about how to restate some of the issues I was trying to make originally a bit more clearly so I can answer some of the points raised in a way that is helpful. The fact its quite difficult to articulate them is, I think, part of the issue too. "Markup" ideas, I think, can be a conceptual trap that is limiting.

ONE thing that I don't see explicitly in the replies, apart from PMario's, a grasp of the fundamental open (unique?) structure of TW parsing. FWIW, I wouldn't have written those posts without that looming in my mind.

Best wishes
Josiah 

[@TiddlyTweeter]

Right

Recently Mark S. worked with Lua (inside Pandoc) to create a "proof of concept" converter WikiPedia -> TiddlyWiki. https://groups.google.com/d/msg/tiddlywiki/0Z4F7fBOBgQ/ebTapW6zBgAJ

Lua is interesting as both a convertor and a sophisticated support for complex formatting.

[@TiddlyTweeter]

I just want to add the footnote that its easy in TW to COMBINE a "personal markup system" with the standard markup it has. If you composite your own markup BEFORE the main parser runs then you can have the best of both as first it would deal with your markup and then standard TW markup. The downside is you'd need a "Content Type" that likely only your wiki would have. In many cases this would not matter.

[@TiddlyTweeter]

I'm kinda of the opinion that for some types of document structures that we can in TW "make input even easier than Markdown"

[@TiddlyTweeter]

This is an interesting issue. On the one hand we have markup for wikitext styling using, for instance, the @@ syntax. On the other hand one inevitably hits a contradiction in Markup systems that are meant to be human readable. That to get complex styling is not sane through "Markup", as Jermolene put it well recently: that would take us back to the same level of complexity as HTML itself.

This is precisely why I'm as much interested in styling for specific Document Types as in generic markup. Markup is a blunt instrument for specifics IMO. Document types provide a layout that is ITSELF the TEMPLATE for format. This allows sophisticated styling without any explicit markup at all.

I slightly exaggerate. But not much.

Joe Armstrong wrote:

[Joe Armstrong]

I woke up with the following thought:

I'm not so worried about the difference in markdown / wiki syntaxes

I think this is like language - there are many dialects of English

American, English, Australian and so on - they differ but we understand each other.

Then there is Swedish, Norwegian, Danish again different but in many ways similar.

What I wondered was about code to convert random HTML to TW code

and NOT the other way around.

I know how to convert TW to HTML - this is what the system does all the time.

It would be very nice to take any fragment of HTML and turn it into TW tiddlers

This would involve partitioning (splitting big pages into smaller tiddlers)

removing styling and guessing the structure

Has anybody thought about this????

Cheer

/Joe

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/NKOnq3hKryo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f14591a6-f08d-482e-a80e-f10953d57171%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[@TiddlyTweeter]

Yes. Jeremy made a careful Text-Slicer edition.

Personally I'd be in for reducing on one sweep all HTML.

There is something very satisfying in reducing carefully wrought HTML to ground zero markup.

Josiah

To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

[@TiddlyTweeter]

Ciao PMario

I really appreciate your concern over standards.

I have an observation. At 7764:3.4 they include Fountain.io syntax as a Markdown variant.

That is odd in a spec given that Fountain is, when it is working well, a non-visible markup. Its a brilliant minimalist FORMATTING system that uses Markup ONLY to FORCE compliance, otherwise you never see it.

In other words that "standard" is a handbag of approaches so diverse its a melange of discontinuity.

I can't see the merit when its accepting a non-visible markup system.

Josiah

[@TiddlyTweeter]

How important, in your opinion, PMario, are RFC's to TiddlyWiki's uptake?

I can't honestly say for myself that an RFC motivated me to do anything. At the same time I do understand they have a role. BUT is it *before* the fact or *after*?

In other words, for TW, WHAT exactly should we be promoting to it? And WHY?

Josiah

[TonyM]

Joe,

I had a similar waking idea a few weeks/months ago, make HTML the common language, but community members pointed out there is a potential loss of information HTML > TW given the degree of sophistication that can be added to HTML, also just think how more is moving into CSS now. Personally this would be fine to me, if the conversion process simplified the source HTML.

I agree with your suggestion

Tony

To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

[PMario]

Hi,

A little bit of history, from my point of view. ...

Markdown was first published in March 2004.
TiddlyWiki was first published in Sept. 2004

In 2007 there has been an attempt to standardize wiki syntax, with the wiki-creole spec. At this time TiddlyWiki sytax did influence the creole specification. ...
But the spec didn't take off. IMO because it didn't bring something new. I was "yet an other wiki syntax".

Tiddlywiki had a "high" in 2007, and MD stagnated till 2009. See google trends.

As Joe pointed out: >>"Markdown solves the problem "make the input easy"<<
I did write somewhere else. ... MD is "simple and good enough" to be useful ... and it doesn't interfere with the text source code. So the source is still human readable, without the need to render it.

MD took off, as github and others "re-discoved" it to create static html site-generators in 2010. Github used it first "to prettify" README files ...

Trends to compare TW with MD: from 2004 till now.
TW-MD-github: from 2004 till now.  ... Here we add github to the mix, which is a much, much more popular search term, which "dominates" the others.

But IMO we can see a clear relation between github and MD or to be more exact github flavored markdown (gfm).

On Tuesday, March 13, 2018 at 9:33:44 PM UTC+1, @TiddlyTweeter wrote:

How important, in your opinion, PMario, are RFC's to TiddlyWiki's uptake?

As written above, I don't think specs are the key to success. ... But success makes specs necessary!

The mime-type text/x-markdown has grown to the "de-facto standard" for static sites since 2010 ...
 

I can't honestly say for myself that an RFC motivated me to do anything. At the same time I do understand they have a role. BUT is it *before* the fact or *after*?

See the history.
 

In other words, for TW, WHAT exactly should we be promoting to it?

The initial markdown spec from 2004 had some flaws, which http://commonmark.org/ wanted to fix. ... BUT there are still some problems with the spec.

If you have a closer look, there is no "table" definition. .. It's missing.

AND they don't have an idea about transclusions, widgets, and other stuff that is essential for tiddlywiki. ... But as far as I can see it, at the moment they don't use syntax like <<>>, {{}}, {{{}}} or <$abc>

So it will be open for "variants"
 

And WHY?

To drive adoption.

have fun!
mario

[PMario]

edit:

MD took off, as github and others "re-discoved" it to create static html sites in 2010. Github used it first "to prettify" README files ...

to

[Jeremy Ruston]

Hi Joe

On 13 Mar 2018, at 19:15, Joe Armstrong <joe...@gmail.com> wrote:

This would involve partitioning (splitting big pages into smaller tiddlers)

removing styling and guessing the structure

Josiah already mentioned the Text-Slicer plugin. It can be installed from the official plugin library. The most recent updates are only to be found in the pre-release version (https://tiddlywiki.com/prerelease).

Text-Slicer takes a set of declarative rules for parsing XML/XHTML content into individual tiddlers, and there is some highly experimental initial support for converting XML/XHTML into wiki text markup.

I’ve been using it for slicing HTML documents and MS Word documents (which are XML these days).

You can see some example rulesets here:

https://github.com/Jermolene/TiddlyWiki5/tree/master/plugins/tiddlywiki/text-slicer/modules/rules

Best wishes

Jeremy.

[@TiddlyTweeter]

Ciao PMario

More than one reply to your great, long "Briefing" :-)

I love this kind of overview. Its extremely helpful. Even if someone disagree on points, it helps make clear what the "territory" is.

This is very important to decent decisions as its explicit.

Once its explicit its a lot easier for newcomers to grasp what the issues are that longer term users know implicitly.

"Dev" steps are never about code alone. They are as much about understanding issues in the context of previous history.

This is one area where we are currently weak, I think. Often the broader contextual framework for understanding the WHY of what we do? is missing.

I don't see many "Position Papers" on TW. Github I don't think is the right place for them. And here on GG certainly isn't. But BROAD contextualisation of major dev trends I do think need them. Also they are readable by people who are not programmers, but who can equally have grasp of the underlying issues and contribute.

I'll write about substantive issues I have on some points in your Briefing separately.

Finally: I hope you are archiving that post. It is VERY useful.

Best wishes
Josiah

PMario wrote a fab briefing on Markdown & TiddlyWiki...

[@TiddlyTweeter]

On CommonMark ...

PMario:

If you have a closer look, there is no "table" definition. .. It's missing.

AND they don't have an idea about transclusions, widgets, and other stuff that is essential for tiddlywiki. ... But as far as I can see it, at the moment they don't use syntax like <<>>, {{}}, {{{}}} or <$abc>

Frankly, I can't see how dynamically rendered "programmatic syntax" (i.e. markup that invokes functions specific to an implementation) could become any standard. As far as I understand it all the simple "markups" use HMTL/CSS substitution and it is THAT which allows inter-variant conversion. But for anything else: WHAT are they substituting?

Maybe a basic syntax for Transclusion could be? since the concept behind it is generalisable, but the issue would be WHAT is transcluded in specific instances that in the current systems are application specific in their realisation. If HTML more clearly embraced transclusion then maybe a "markup" could too? This is a quick way of pointing out that "convertible markup" is convertible BECAUSE its DERIVATIVE. Once its not derivative you no longer have any shared conversion reference point.

The lack of Table support in CommonMark is ridiculous for something that claims to be a mediating standard.

Best wishes
Josiah

[PMario]

On Thursday, March 15, 2018 at 3:33:56 PM UTC+1, @TiddlyTweeter wrote:

On CommonMark ...

PMario:

If you have a closer look, there is no "table" definition. .. It's missing.

AND they don't have an idea about transclusions, widgets, and other stuff that is essential for tiddlywiki. ... But as far as I can see it, at the moment they don't use syntax like <<>>, {{}}, {{{}}} or <$abc>

Frankly, I can't see how dynamically rendered "programmatic syntax" (i.e. markup that invokes functions specific to an implementation) could become any standard. As far as I understand it all the simple "markups" use HMTL/CSS substitution and it is THAT which allows inter-variant conversion. But for anything else: WHAT are they substituting?

That's not really the point I wanted to make. They could use those markers for different things in the standard, because they don't know the dynamic stuff. ... So the markers are basically blocked for variants. ... but if a variant defines those markers, they are "kind of blocked" for the default spec. ...

So who ever is first will win ...

-----

>The lack of Table support in CommonMark is ridiculous for something that claims to be a mediating standard.

Table markup is difficult and imo non of the existing mechanisms are very satisfying. ...

For me as a writer I don't want to mess with some ASCII art to get a table going.
eg:

+-----+-----+
| text | more text |
+-----+-----+

is CRAP --- I don't want to mess around fixing frames, after I did change the content. I would prefer a descriptive like
eg:

table-title: test
table-caption: bla bla
table-rows: 3
table-columns: 3
h1: header 1
h2: header 2
h3: header 3

a1:
As much text, as I want to write here

a2:
more text<br>
with a hard line break

b2:
column 2 row 2
b1 is empty

c1..c3:
Text that spans 3 columns

... and so on. So I can define content, without needing to mess with the formatting.

This is just an idea, nothing concrete and misses all the edge cases, we can do today with the existing syntax.

May be the new grid-css may give us better possibilities already. ...

-m

[@TiddlyTweeter]

Ha! Really interesting issue. Which I'm gonna riff off.

PMario..

I don't want to mess with some ASCII art to get a table going.

I guess the ASCII art of tables emerged with markups to VISUALLY present edit text to be readable before render. A central Gruber point on markup.

Your version is proto-code, NOT simple "visual markup". Its instructions, then content. It is NOT the thing Core Markup Ideas are into.

And therein is EXACTLY the limits I'm trying to talk about...

...That additive markup is often a BLUNT instrument. It is a very dumb (though useful) derivative replication of HTML/CSS code in shorthand. And nothing more. The conceit its "visually like writing" breaks down quickly. I think WikiText  tables are as about as far as you can go. And the mess on compatibility on them between markup systems testifies to the limits.

And so Markup struggles with HTML once you get beyond simple blocks or spans. ALL the conversion issues seem to stem from that.

When Markup starts to get clever, like you see in Fountain Markup, markup largely disappears from view. Which is exactly what is needed.

The hidden message of "markup" is ... you don't need any user markup at all IF the document has a readable pattern ... so, rather, parse the Layout Type. Give the editor even less to type.

As soon as you switch from thinking in terms of "Generic Markup" to "Layout Type" the issues change.

Your example is very interesting for illustrating the contradiction of "less visual markup and more instructions can be better." But its hardly "WikiText" as we know it.

I think its good to argue this through more.

Best wishes
Josiah

[Mark S.]

This may be a digression on tables and ascii.

The problem with drawing ascii tables is there's inevitably a cell which has contents that are too long and that when rendered will fold to a second line. Also drawing pipes "|" is a pain.  But a markup could have a table mode where
white space (double spaces, double line entry) are used for delimiters.

Then you could have:

.table
I am the egg    We all live    Imagine all
drop man        with a yellow  the tribbles
                baboon

Yesterday, tic  Hey Dude,      Feed the
tac toe was     don't make     squirrels
                a mess
.endtable

where it was easy to keep things aligned and still readable as ASCII.

-- Mark

[@TiddlyTweeter]

Ciao Mark S.

Provided the editor, or the edit section for tables, is mono-spaced I think its a better visual solution. Issues might be if you have a very wide table ("table-mode" a popout to address?).

J.

[TonyM]

Josiah,

On further thought and reading some of the below replies, I wonder if we are often confusing TiddlyWiki Features with Markups/Markdowns. 

I for one do everything I can to have only markdown in the text field of tiddlers I expect me or a user to read. I am quite content with TiddlyWikis standards although I do extend it with CSS or HTML tags some times.

The way I do this is to use the view template to include in the display of the tiddler thing such as lists, Menus, keeping macros out of text tiddlers as much as possible.

The tiddlers that use TiddlyWiki Features such as macros and widgets tend to be code tiddlers that produce a result and I am responsible for the look and feel at design time. The Look and Feel at user data entry time uses markdown only (as a Rule).

Regards

Tony

[@TiddlyTweeter]

Ciao TonyM

I agree that for writing text the plonking in of macros & pragma are somewhat in conflict with "human readable text". In practice I do think "markup" and "programmatic syntax" have somewhat blurred ... I think ordinary users can find them confusing to see at the top of an otherwise readable text.

On the other hand a new user to TW just using it to write is unlikely to ever see them until they wanted to use them--and then its acceptable to them as they will better know why they are there.

But I do think its an issue if you are authoring TW that others will use who aren't interested in the programmatic side.

Best wishes
Josiah

TonyM wrote:

On further thought and reading some of the below replies, I wonder if we are often confusing TiddlyWiki Features with Markups/Markdowns. 

 

I ... do everything I can to have only markdown in the text field of tiddlers I expect me or a user to read. I am quite content with TiddlyWikis standards although I do extend it with CSS or HTML tags some times...

 

The way I do this is to use the view template ... keeping macros out of text tiddlers as much as possible.

[@TiddlyTweeter]

PMario wrote:
... As you pointed out. TW has the potential, to convert one syntax to an other (with some limitations). ... BUT ... not with the internal AST, that we use at the moment...

Right. AST (the Abstract Syntax Tree, not the Azienda Siciliana Trasporti).

BUT, right now the other routes in TW markup/format options are somewhat mute.

Mainly, I think, because that both creating Content Types and the workings of the basic parser are (as far as I can see) not so well documented.

At the moment I think its looking harder than it actually is to achieve variant markup systems because of that.

Josiah