Hi Mario <snip> > I think your proposed format is cool, if I want to create a single file / > plugin that can be dragged into an other TW. If you drag it, you get all 3 > tiddlers -> nice > But imo it doesn't solve "the missing section" problem. >
I think you're raising two issues: * That tiddlers created in this way will be shadow tiddlers, and so won't show up in the ordinary lists * That the proposal still doesn't allow the extraction of subsets of the tiddler text In the case of the first, that's a feature: my proposal attempts to address two separate issues that have been raised: to reduce the number of tiddlers visible to casual users in the various lists, and to make a series of related tiddlers easier to type. > > Would it be possible to access sections if a data tiddler would look like > this? > If yes, than let's internally store all tiddlers that way in the browser > memory. ... > Well, changing the nice clearn, comprehensible data format that we have for tiddlers to one that is optimised for one particular use case isn't very appealing. Anyhow, something like the structure you are suggesting can be derived from the parse tree for the tiddler. It's easy to write code that reaches into the parse tree of a tiddler and extracts or locates information. That's what the link tracking stuff does: https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/wiki.js#L366 The problem is that that approach would only extract the section content that is directly stored in the tiddlers, and would ignore transcluded tiddlers. That probably wouldn't meet user expectations; It feels like I ought to be able to switch a sentence or a phrase from literal text to a transclusion without any change in the interpretation of that text. So, rather than working off the parse tree for the tiddler, we'd have to do the extraction based on the render tree. That has big implications in terms of performance: rendering is a slow process, and the results can't be cached because the action of rendering a chunk of wikitext depends on the context in which it is rendered. section names "heading1" and "headingx" could be md5 hases of "!any header > like this". Section name uniqueness is not needed. If someone uses the > exact same hading title 2 times, it is there fault. The parser can use the > first or the last one found. > MD5 hashes are pretty slow to compute, and they are actually going to be marginally less unique than the original text, so it probably would make sense just to use the existing text. To be clear, though, the reason I'm questioning section handling is not only because it's hard to implement the section extraction in the code. As noted above, the concern is that TiddlyWiki should be focussed on inter-tiddler operations, and that requirements that are expressed in terms of reaching into the structure of a tiddler can be equivalent to splitting that tiddler into separate tiddlers so that the ordinary inter-tiddler operations can be used. Best wishes Jeremy > > -mario > > > > -- Jeremy Ruston mailto:jeremy.rus...@gmail.com -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/groups/opt_out.
