Thanks Mohammad,
I am not sure how I can contribute given the depth into the core. However I can add a little to the issues below;
I am trying to be helpful and share another view.
- Would it hurt providing a feature in the export templates to help with static html, after all the templates are bespoke for exporting static html anyway. eg remove wayward paragraph tags.
- Aspects of this have raised their head many times but various approaches have being developed to address them. For one the idea of the dot paragraph which has resulted in the paused but live custom wiki-text plugin with Mario, this could possible help at least with a class of these issues if not all.
- I am currently investigating the idea that the text field is just that, some text. and looking at applying custom templates basically because the view templates application of $:/core/ui/ViewTemplate/body is actually just a transclusion (without templates).
- Recent talk about programmatic way of hiding the body text has led me to play with ideas stemming from The quickest and easiest ever todolist in tiddlywiki ? Requires 5.2.0 - #2 by TW_Tones in that case I interpret the text differently - ie each line without wiki markup is a todo Item and can be made into a field or tiddler. Although it also depends on wiki markup and its peculiarities, I just apply a specific set to suit the outcome I want. Basically I redefine what the text field means. I could see someone writing other viewTemplates that transform the text into any desirable form.
- A the very same time with the ability to edit the current tiddler in 5.2.0 I can see how we could apply alternatives such as for form handling, whist you can just build a sophisticated view template, you could just apply a different form or hand made parsing regime. Then the only code needed can come from that interpretation of the text field.
- Just a final note, when dealing with this the core internals plugin is a great help using the html preview. Because you can get immediate feedback on what the parser generates.
Remember I try to be a supper user who does not resort to javascript and core changes, from my perspective we could easily accommodate different results, all that remains is to get the various shorthand transclusions to detect an alternate template is available and use that when transcluding one tiddler from another. This can be done manually already.
One other final approach may be to open up or extend the existing type field to accept user types. Detecting when they are not also mime types, or creating new mime types. For example using this for other markups.
It seems to me we could add features rather than risk the core changes.
