[TW5] [FR] section (heading) link

[RA]

Is it possible to create a link to a section? Is it a planned feature?

Kind of like  [[TiddlerName##SectionName]] in TWC (with SectionLinksPlugin I think)

Thanks

RA

[Albertononi]

I am also looking forward to see it implemented, but I think it is not yet.

[Stephan Hradek]

I don't know whether or not it is planned at all, I just know that the ## syntax is now used for accessing indexes in DataTiddlers. Check on http://tiddlywiki.com the tiddler "DataTiddlers".

[Jeremy Ruston]

I'm not planning to implement the ability to link to a section within a tiddler, nor am I planning to support TiddlyWiki classic's syntax for selecting the content of sections.

If we did, then each section within a tiddler would end up acting like a mini-tiddler, and would need to have the same characteristics: a unique title, the ability to scroll to it, the ability to transclude it. Before you know it, you've got two different implementations of a tiddler.

So, purposely, TiddlyWiki 5 tries to focus on the means for representing structure and relationships *between* tiddlers, with only a very few features concerned with structuring content *within* tiddlers.

In TW5, if you've got something that looks like a long complex tiddler, consider splitting it up into smaller chunks and recombining them with transclusion. That's really where the power of TiddlyWiki comes.

I understand the concerns about managing the proliferation of tiddlers that can result, but that's a UX problem we have anyway. An emerging technique is to add new lists to the sidebar that filter the content. For example, http://tesis.tiddlyspot.com/ uses custom sidebar tabs to hold lists of authors, articles, concepts, theories and notes.

Best wishes

Jeremy

Best wishes

Jeremy

On Thu, Jan 16, 2014 at 1:32 PM, Stephan Hradek <stephan...@gmail.com> wrote:

I don't know whether or not it is planned at all, I just know that the ## syntax is now used for accessing indexes in DataTiddlers. Check on http://tiddlywiki.com the tiddler "DataTiddlers".

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Julie]

I miss this function too (with ## or something else), but I knew the argument would be "a section could be a tiddler by itself".

However I wonder if, when you want to re-use only a couple of lines, a real tiddler does not take more place (in terms of file size) than a section ?

I've thought to use DataTiddler for a kind of Glossary, but I've been stopped by the impossibility to have spaces in the name part of the name:value couple, and I don't want a tiddler by word.


Because long lists (recent, alphabetic) are a pain to scroll throught, this approach also means that users will have to think a lot more at the structure they want for their TW (how to expose/hide main tiddlers and "utility" tiddlers, ...), where they could only focus on writing their notes. I don't say that there are no solutions: quite the reverse, there are a lot of possibilities, but they need some planning, uderstanding and tweakink.
That remind me that I think some people may miss the TWC MainMenu: it would have been useful to point the main tiddlers of a wiki, and it's quite different than the "DefaultTiddler" and the "Open" tab. Maybe a core-built "Menu" tab in the sidebar would be a good idea, where users could only list tiddlers or build something more complex as Albertononi has done?

Le mercredi 15 janvier 2014 23:56:59 UTC+1, RA a écrit :

[Jeremy Ruston]

Hi Julie

On Thu, Jan 16, 2014 at 3:09 PM, Julie <julie.st...@gmail.com> wrote:

I miss this function too (with ## or something else), but I knew the argument would be "a section could be a tiddler by itself".

However I wonder if, when you want to re-use only a couple of lines, a real tiddler does not take more place (in terms of file size) than a section ?

Yes, individual tiddlers are likely to take up more space. We don't do anything to optimise the filesize of saved wikis; in particular, fields (like type=text/vnd.tiddlywiki) will be repeated for each tiddler to which they apply. Anyhow, if filesize became an issue there is a lot we could do.

 

I've thought to use DataTiddler for a kind of Glossary, but I've been stopped by the impossibility to have spaces in the name part of the name:value couple, and I don't want a tiddler by word.

One of the possibilities that I've raised before is to provide an alternative syntax for creating plugins, in the same way that tiddler/x-dictionary is an alternative syntax for JSON tiddlers.

For example, a tiddler containing this:

---

modifier: JeremyRuston

--- HelloThere

modified: 201312310821

This is the text of HelloThere

--- GoodbyeNow

tags: gone

This is the text of GoodbyeNow

The idea is that the first line gives the separator that is being used, then "modifier: JeremyRuston" is applied to all tiddlers in the plugin. Each tiddler is marked with the separator, and a blank line between the fields and the body.

So, the above example would be treated as though it were an ordinary JSON tiddler like this:

{

    "tiddlers": {

        "HelloThere": {

            "text": "This is the text of HelloThere",

            "modified": "application/javascript",

            "modifier": "JeremyRuston"

        },

        "GoodbyeNow": {

            "text": "This is the text of GoodbyeNow",

            "tags": "gone",

            "modifier": "JeremyRuston"

        }

    }

}

The end result is that HelloThere and GoodbyeNow would be available as shadow tiddlers. Right now if we did this we'd have the issue that plugins are only unpacked at startup, but we can fix that.

Best wishes

Jeremy

 

Because long lists (recent, alphabetic) are a pain to scroll throught, this approach also means that users will have to think a lot more at the structure they want for their TW (how to expose/hide main tiddlers and "utility" tiddlers, ...), where they could only focus on writing their notes. I don't say that there are no solutions: quite the reverse, there are a lot of possibilities, but they need some planning, uderstanding and tweakink.
That remind me that I think some people may miss the TWC MainMenu: it would have been useful to point the main tiddlers of a wiki, and it's quite different than the "DefaultTiddler" and the "Open" tab. Maybe a core-built "Menu" tab in the sidebar would be a good idea, where users could only list tiddlers or build something more complex as Albertononi has done?

Le mercredi 15 janvier 2014 23:56:59 UTC+1, RA a écrit :

Is it possible to create a link to a section? Is it a planned feature?

Kind of like  [[TiddlerName##SectionName]] in TWC (with SectionLinksPlugin I think)

Thanks

RA

--

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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.

[PMario]

On Thursday, January 16, 2014 5:08:06 PM UTC+1, Jeremy Ruston wrote:

One of the possibilities that I've raised before is to provide an alternative syntax for creating plugins, in the same way that tiddler/x-dictionary is an alternative syntax for JSON tiddlers.

For example, a tiddler containing this:

---

modifier: JeremyRuston

--- HelloThere

modified: 201312310821

This is the text of HelloThere

--- GoodbyeNow

tags: gone

This is the text of GoodbyeNow

The idea is that the first line gives the separator that is being used, then "modifier: JeremyRuston" is applied to all tiddlers in the plugin. Each tiddler is marked with the separator, and a blank line between the fields and the body.

So, the above example would be treated as though it were an ordinary JSON tiddler like this:

{

    "tiddlers": {

        "HelloThere": {

            "text": "This is the text of HelloThere",

            "modified": "application/javascript",

            "modifier": "JeremyRuston"

        },

        "GoodbyeNow": {

            "text": "This is the text of GoodbyeNow",

            "tags": "gone",

            "modifier": "JeremyRuston"

        }

    }

}

The end result is that HelloThere and GoodbyeNow would be available as shadow tiddlers. Right now if we did this we'd have the issue that plugins are only unpacked at startup, but we can fix that.

I think this doesn't solve the a problem I have.
eg:

---
--- This should not be a shadow tiddler, since everyone should see it
modifier: pmario

! Latest Topics
{{HelloThere##Intro}}
{{GoodbyeNow##Intro}}

or

<$ list .... that links to the title and shows the "teaser" ##Intro text>
...

--- HelloThere
tag: story

! Main Heading
lorem ipsum ... lorem ipsum ...

!! Intro
3 lines of teaser text
teaser text
teaser text

!! heading
lorem ipsum ... lorem ipsum ...
lorem ipsum ... lorem ipsum ...

--- GoodbyeNow
tag: story

! Main Heading
lorem ipsum ... lorem ipsum ...

!! Intro
3 lines of teaser text

So HelloThere and GoodbyNow can't be splitted into smaller pices anymore.
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.

Would it be possible to access sections if a data tiddler would look like this?

{
    "tiddlers": {
        "HelloThere": {
            "text": {"sections" [{"heading1": "! heading 1\nsome text"},
                                 {"headingx": "!! heading x\nsome more text"]

            "modified": "application/javascript",
            "modifier": "JeremyRuston"
        },
}

If yes, than let's internally store all tiddlers that way in the browser memory. ...

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.

-mario


 

[Jeremy Ruston]

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