How do I count and get numbers for the instances that call a macro within a Tiddler/Within the storyriver.

[Jan]

Hej,
I am trying to do a footnote plugin, for scientific work it would be
great to have automatic numbers for the footnotes.
How do I count and get numbers for the instances that call a macro
within a Tiddler/Within the storyriver.

Is it possible to do something like <$list
filter=[[currentTiddler]]>filter="""[<tid>get[text]]""<$list
filter=[[splitbefore[HERE ( how to do this????)]><$list $count
filter="<ref"><<count>> </$list></$list></$list>?
I know thie syntax aint correct at all, just as an idea...

Is ther a plugin to do something lie this.


Thanks
Jan

[Mark S.]

I'm having trouble understanding what you're trying to accomplish.

I think you are looking for instances where a macro is invoked inside tiddlers that are part of the current story list.

So:

Tiddler1: Today is a great day <<cite "great">>
Tiddler2: Just a bunch of text
Tiddler3: Today is an historic day <<cite "historic">>
Tiddler4 through Tiddler6: Comments on penguins
Tiddler7: All days are equal <<cite "equal>>

Then a listing might generate something like:

Footnotes:
1. Tiddler1
2. Tiddler3
7. Tiddler4

Is that what you are looking for?

Mark

[Tobias Beer]

Hi Jan,

I would say Tiddlywiki lacks some core functions
that allow us to traverse a parseTree as we would have previously traversed the DOM.

What do I mean?

A generic query language that allows us to say something like:

• from where I am, find the outer tiddler (identified somehow
• e.g. "class => contains => tc-tiddler-frame")
  
• possibly that's the wrong approach, as it looks DOM-centric
• return all parseTreeNodes of type foo where property bar contains baz

Then a plugin could do some magick with that output,
if only to count the number and return, well, the next. ;-)

Or, you could create a kind of summary at the bottom, of footnotes.

Possibly some TraversePlugin could cater for that.

Best wishes,

Tobias. 

[Thomas Elmiger]

Hej Jan,

I think I know where you are coming from (I read your thoughts here: http://slidesnstories.tiddlyspot.com/#TextStretch%20by%20Thomas%20Elminger) and I think it would be interesting to develop a concept for scientific documents authored using TW5.

Tobias points towards something that is critical for my CSS numbering solution: it works DOM-oriented and thus – as for now – on a per tiddler base. It is based on presentation and agnostic of content and structure. For scientific work I am afraid this is not enough. Important features of TiddlyWiki are transclusion, lists and filters … I think a scientific authoring tool should be able to deal with that. So a broader concept is needed. Let me explain some thoughts: In a perfect world, …

1. Authors would write chapters or sub-chapters as tiddlers and collect them in chapters and publications (books). A book usually is built up in a traditional structure like

•     Title
•     Contents Overview
•     Foreword
•     Chapter 1
•     Sub-chapter 1.1
•     and so on 1.1.1
•     <<ref "see chapter 2.1">>
•     term definition 1.1.1.1
•     Chapter 2
•     and so on 2.1
•     reference to term definition 1.1.1.1: <<ref "{{term definition}}">>
•     Conclusion
•     Indexes

2. Publishers would ask for one document with all the content to reformat it for other publication channels like printed books, e-books and the like. What would this master document be? A story river?

3. Schools would possibly put the book on a server (in a DB like Danielo’s here? or in a TWederation Wiki?) where teachers/students can download/connect to it.

4. Teachers would collect chapters from several books as readings for their students. Can they use TW for this? How would this affect numbering of chapters and references?

5. Students would make their own annotations or cite excerpts in their own works.

A fool-proof authoring system would offer solutions and/or guidelines to use cases like these. To make a relevant contribution for scientific authors we should at least have a concept for 1. and 2. How should an author structure his/her work? What do we use single tiddlers for? How many levels of (nested) transclusion are acceptable? And so on …

Do you have a concept, Jan, or a real-world example wiki, we could use for this? It could be very helpful to develop and test even small contributions against such a reference project. 


Kind regards, 
Thomas


[Thomas Elmiger]

Oh! And keep an eye on Mat’s interesting concept of Article Tiddlers: https://groups.google.com/forum/m/#!topic/tiddlywiki/IWJJpx6L6O4

Cheers, Thomas

[Jan]

Hej Thomas, Hey Tobias (so happy to see you back here!)

>>it works DOM-oriented and thus – as for now – on a per tiddler base.

As far as I found out, your numbering counts through the storyriver, wich is fine for endnotes...

>>A generic query language that allows us to say something like:

• from where I am, find the outer tiddler (identified somehow, e.g. "class > contains > tc-tiddler-frame")
  

• return all parseTreeNodes of type foo where property bar contains baz

Mat has achieved what something like that in quite brute force way in the cherrypicker.tiddlyspot.com. The problem ist that it has trouble dealing with Wiki-Code-Expressions, that is to say I have trouble doing this.
Perhaps it would be smarter to do something like that in js...

Jan

Am 28.08.2016 um 17:11 schrieb Thomas Elmiger:

Hej Jan,

I think I know where you are coming from (I read your thoughts here: http://slidesnstories.tiddlyspot.com/#TextStretch%20by%20Thomas%20Elminger) and I think it would be interesting to develop a concept for scientific documents authored using TW5.

Tobias points towards something that is critical for my CSS numbering solution:  It is based on presentation and agnostic of content and structure. For scientific work I am afraid this is not enough. Important features of TiddlyWiki are transclusion, lists and filters … I think a scientific authoring tool should be able to deal with that. So a broader concept is needed. Let me explain some thoughts: In a perfect world, …

1. Authors would write chapters or sub-chapters as tiddlers and collect them in chapters and publications (books). A book usually is built up in a traditional structure like

•     Title
•     Contents Overview
•     Foreword
•     Chapter 1
•     Sub-chapter 1.1
•     and so on 1.1.1
•     <<ref "see chapter 2.1">>
•     term definition 1.1.1.1
•     Chapter 2
•     and so on 2.1
•     reference to term definition 1.1.1.1: <<ref "{{term definition}}">>
•     Conclusion
•     Indexes

2. Publishers would ask for one document with all the content to reformat it for other publication channels like printed books, e-books and the like. What would this master document be? A story river?

3. Schools would possibly put the book on a server (in a DB like Danielo’s here? or in a TWederation Wiki?) where teachers/students can download/connect to it.

4. Teachers would collect chapters from several books as readings for their students. Can they use TW for this? How would this affect numbering of chapters and references?

5. Students would make their own annotations or cite excerpts in their own works.

A fool-proof authoring system would offer solutions and/or guidelines to use cases like these. To make a relevant contribution for scientific authors we should at least have a concept for 1. and 2. How should an author structure his/her work? What do we use single tiddlers for? How many levels of (nested) transclusion are acceptable? And so on …

Do you have a concept, Jan, or a real-world example wiki, we could use for this? It could be very helpful to develop and test even small contributions against such a reference project. 


Kind regards, 
Thomas


--
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 https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/66ad8007-2dfb-4c8b-8092-0b8d8401fc5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Elmiger]

Hi Jan

>>it works DOM-oriented and thus – as for now – on a per tiddler base.
As far as I found out, your numbering counts through the storyriver, wich is fine for endnotes...

That was an error – and I just changed it in my new version 0.8.3 (see http://tid.li/tw5/hacks.html#TextStretch%20Versions for comments). When you opened another tiddler on the top of the story river, all numbers in allready open tiddlers changed – not very consistent. So each tiddler starts at number 1 now. I have been thinking about numbering them 1.1 … 2.1 with an additional tiddler-number prefix. Of course I can give you the old behaviour back if you prefer … maybe we could have separate classes for tiddlernumbers and rivernumbers so authors can choose.

Oh: and links do work in my tests (both internal and external). Please provide examples if you have problems.

Good night!

[Jan]

Hi Thomas,
nice that both numbering-behaviours are possible.
Numbering throughout the storyriver would be fine for print/pdf export. I think "eternal-"consitency is not the problem, even in Word the footnotenumbers change if you add one in front.
For comments and reading of course the new tiddlerwise numbers of course are better, because they are smaller.
I would think a button to switch between two stylesheets would be a good solution. It could be an element of the endnotetiddler (which we know is science-fiction so far...;-).

Cheers
Jan

Am 29.08.2016 um 00:33 schrieb Thomas Elmiger:

Hi Jan

>>it works DOM-oriented and thus – as for now – on a per tiddler base.
As far as I found out, your numbering counts through the storyriver, wich is fine for endnotes...

That was an error – and I just changed it in my new version 0.8.3 (see http://tid.li/tw5/hacks.html#TextStretch%20Versions for comments). When you opened another tiddler on the top of the story river, all numbers in allready open tiddlers changed – not very consistent. So each tiddler starts at number 1 now. I have been thinking about numbering them 1.1 … 2.1 with an additional tiddler-number prefix. Of course I can give you the old behaviour back if you prefer … maybe we could have separate classes for tiddlernumbers and rivernumbers so authors can choose.

Good night!

--
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 https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a9dc6a38-7838-4c49-b777-e687ad5910cd%40googlegroups.com.

[Thomas Elmiger]

Hi Jan – an update is online, we now have the classes "numbers" for within tiddler counting and "storynumbers" to count throughout the story. I would recommend you put your styles in a stylesheet of your own so they don’t get overwritten in case of updates.

Cheers, Thomas

(When I find the time I will have a look at that cherrypicker again, but not the next days, I am afraid.)

2016-08-29 11:58 GMT+02:00 Jan <lasjo...@gmail.com>:

Hi Thomas,
nice that both numbering-behaviours are possible.
Numbering throughout the storyriver would be fine for print/pdf export. I think "eternal-"consitency is not the problem, even in Word the footnotenumbers change if you add one in front.
For comments and reading of course the new tiddlerwise numbers of course are better, because they are smaller.
I would think a button to switch between two stylesheets would be a good solution. It could be an element of the endnotetiddler (which we know is science-fiction so far...;-).

Cheers
Jan



Am 29.08.2016 um 00:33 schrieb Thomas Elmiger:

Hi Jan

>>it works DOM-oriented and thus – as for now – on a per tiddler base.
As far as I found out, your numbering counts through the storyriver, wich is fine for endnotes...

That was an error – and I just changed it in my new version 0.8.3 (see http://tid.li/tw5/hacks.html#TextStretch%20Versions for comments). When you opened another tiddler on the top of the story river, all numbers in allready open tiddlers changed – not very consistent. So each tiddler starts at number 1 now. I have been thinking about numbering them 1.1 … 2.1 with an additional tiddler-number prefix. Of course I can give you the old behaviour back if you prefer … maybe we could have separate classes for tiddlernumbers and rivernumbers so authors can choose.

Good night!

--
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+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/a9dc6a38-7838-4c49-b777-e687ad5910cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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/d2bpFwTXggI/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/57C4074A.4030307%40googlemail.com.

[Tobias Beer]

Hi Jan,

 

Mat has achieved what something like that in quite brute force way in the cherrypicker.tiddlyspot.com. The problem ist that it has trouble dealing with Wiki-Code-Expressions, that is to say I have trouble doing this.
Perhaps it would be smarter to do something like that in js...

This is precisely what I meant: core JavaScript functions
that enable devs to do traversals and queries whereby as a dev
I would be able to implement them in some widget and then show stuff

based on the parseTreeNodes returned by the traversal query.

Makes sense? Or Chinese. :D

Best wishes,

Tobias.

[Jan]

Hi Tobias,
To parseTreeNodes sounds a little chinese for me...but I think I understand.
If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter  collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera

I think we would all be very happy.

Jan

--
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 https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c391eed9-eff4-4aa9-8c8e-354672d41c49%40googlegroups.com.

[Tobias Beer]

Hi Jan

 

To parseTreeNodes sounds a little chinese for me...but I think I understand.

Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily.

Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext.

However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index.

So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc...

 

If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera

So, that's the thing: you would need to be able to tell the TiddlyWiki core:

• that right there is my "tiddler" in the widget tree
• and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such
• eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items
  

However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always try and work with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately.

To conclude with a much more practical example, let me put it this way:
if you turned your footnotes into actual tiddlers, e.g. as

• $:/fn/the related tiddler/foo
  
• $:/fn/the related tiddler/bar
  

and then retrieved it as:

<<fn foo>>

and perhaps a simplistic...

<<fn-index>>

in the context of the related tiddler, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most.

Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own.

However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be:

• $:/some-unique-id-12345/foo
  
• $:/another-uniqueid-54321/bar
  

With the eventual tiddler being:

title: some related tiddler

id: some-unique-id-12345

Refer to <<fn foo>>.

Am I making sense?

Best wishes,

Tobias.

[Jan]

Hi Tobi,
Sorry for the latency, I needed to read your explications about the architecture several times, and yet I do not fully understand everything.

Some thoughts though:
I would  rather like footnotes to be macros than tiddlers. On the one hand something tells me that it is smaller and reduces the number of total tiddlers. On the other hand I would like a footnote to disappear when its anchor is deleted, and not to be accidentally deleted when cleaning up. I wonder whether a unique id could change something about this.
The question I have is how could one search for the content of a macro in wikitext when the searching macro would have to use the same strings as the pattern we look for.
Like <<collect filter="[list[$:/storyList]]" start=`<<ref "` end=`"`>>

Yours  Jan

Am 31.08.2016 um 07:34 schrieb Tobias Beer:

Hi Jan

 

To parseTreeNodes sounds a little chinese for me...but I think I understand.

Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily.

Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext.

However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index.

So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc...

 

If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter  collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera

So, that's the thing: you would need to be able to tell the TiddlyWiki core:

• that right there is my "tiddler" in the widget tree
• and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such
• eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items
  

However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always work try and with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately.

To conclude with a much more practical example, let me put it this way:
if you turned your footnotes into actual tiddlers, e.g. as

$:/fn/the related tiddler/foo

$:/fn/the related tiddler/bar

and then retrieved it as:

<<fn foo>>

in the context of the related tiddler, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most.

Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own.

However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be:

$:/some-unique-id-12345/foo

$:/another-uniqueid-54321/bar

With the eventual tiddler being:

title: some related tiddler

id: some-unique-id-12345

Refer to <<fn foo>>.

Am I making sense?

Best wishes,

Tobias.

--
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 https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e7f95d27-4dcc-4fab-bdce-eb968c8c07cf%40googlegroups.com.

[Jan]

Hi Tobi,
Sorry for the latency, I needed to read your explications about the architecture several times, and yet I do not fully understand everything.

Some thoughts though:
I would  rather like footnotes to be macros than tiddlers. On the one hand something tells me that it is smaller and reduces the number of total tiddlers. On the other hand I would like a footnote to disappear when its anchor is deleted, and not to be accidentally deleted when cleaning up. I wonder whether a unique id could change something about this.
The question I have is how could one search for the content of a macro in wikitext when the searching macro would have to use the same strings as the pattern we look for.
Like <<collect filter="[list[$:/storyList]]" start=`<<ref "` end=`"`>>

Yours  Jan

Am 31.08.2016 um 07:34 schrieb Tobias Beer:

Hi Jan

 

To parseTreeNodes sounds a little chinese for me...but I think I understand.

Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily.

Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext.

However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index.

So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc...

 

If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter  collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera

So, that's the thing: you would need to be able to tell the TiddlyWiki core:

• that right there is my "tiddler" in the widget tree
• and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such
• eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items
  

However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always work try and with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately.

To conclude with a much more practical example, let me put it this way:
if you turned your footnotes into actual tiddlers, e.g. as

$:/fn/the related tiddler/foo

$:/fn/the related tiddler/bar

and then retrieved it as:

<<fn foo>>

in the context of the related tiddler, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most.

Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own.

However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be:

$:/some-unique-id-12345/foo

$:/another-uniqueid-54321/bar

With the eventual tiddler being:

title: some related tiddler

id: some-unique-id-12345

Refer to <<fn foo>>.

Am I making sense?

Best wishes,

Tobias.

--
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 https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e7f95d27-4dcc-4fab-bdce-eb968c8c07cf%40googlegroups.com.

[Jan]

Hi Tobi,
are you still on this issue or did I entirely misunderstand what you  described?
I think something like this would be extremely valuable.

Yours Jan

Sorry for the latency, I needed to read your explications about the architecture several times, and yet I do not fully understand everything.

Some thoughts though:
I would  rather like footnotes to be macros than tiddlers. On the one hand something tells me that it is smaller and reduces the number of total tiddlers. On the other hand I would like a footnote to disappear when its anchor is deleted, and not to be accidentally deleted when cleaning up. I wonder whether a unique id could change something about this.
The question I have is how could one search for the content of a macro in wikitext when the searching macro would have to use the same strings as the pattern we look for.
Like <<collect filter="[list[$:/storyList]]" start=`<<ref "` end=`"`>>

Yours  Jan

Am 31.08.2016 um 07:34 schrieb Tobias Beer:

Hi Jan

 

To parseTreeNodes sounds a little chinese for me...but I think I understand.

Yes, it takes some getting used to terminology. Think of it like that: You have wikitext and that is parsed by the TiddlyWiki core into a parseTree and then a widget tree subsequently constructed from that, which in turn eventually generates DOM elements for the browser to display, but not necessarily.

Since TiddlyWiki does away with the focus on manipulating DOM elements directly, operating on a widgets architecture, there is a bit of a gap. With TiddlyWiki classic it was easy to do DOM traversal and manipulation with jQuery and so we could do all kinds of fancy stuff after the fact, meaning, after TiddlyWiki did its default thing with the wikitext.

However, with the new architecture, we're a bit lacking on a general interface for developers to traverse the widget-tree-representation of your wiki text, e.g. so as to say "find that list and give me its list elements". Such a traversal may not even be desirable owed to the transient, stateless nature of widgets... which doesn't mean that they do not actually have a state, but that they can be trashed and recreated at any given moment... so if you have some other output that would depend on the current widget representation, there's a chance it would not notice that the thing it references and relies on to do further stuff actually changed from the first time it was created, e.g. that footnote index.

So, with TiddlyWiki classic there were HTML / DOM elements like ULs and LIs (which we still have, of course) for which we could use simple jQuery selectors to address them. However, now we would need some simplistic equivalent to address the underlying list widget, so as to be able to then do magick with a possibly much safer and much more powerful encapsulation in the form of a widget, that provides well defined interfaces for actually handling it, e.g. when to refresh or recompute the state of that widget, etc...

 

If it is what Ithink it would put us all a big deal forward and could be the basis for many things I try to build.
- a filter  collecting Footnotes
- a way of transcluding/navigating to parts of Tiddlers
... and thus new possibilities to present information stored in TWs for example in Slideshows et cetera

So, that's the thing: you would need to be able to tell the TiddlyWiki core:

• that right there is my "tiddler" in the widget tree
• and in that thing being the "tiddler" rendered from that wikitext, go find elements matching this or that pattern, e.g. all list widget where some attribute is such and such
• eventually return the corresponding widgets so that I can do fancy stuff based on what I'm given, e.g. with the list items ...presuming I know all about list widgets and how to get from the list itself to the items
  

However, one core paradigm is that widgets are transient things by nature, especially their representation in the DOM. So, in general the philosophy would be to always work try and with the underlying wikitext first. And if that proves difficult, chances are you simply haven't sliced and diced your wikitext just enough for you to be able to address every single chunk of concern separately.

To conclude with a much more practical example, let me put it this way:
if you turned your footnotes into actual tiddlers, e.g. as

$:/fn/the related tiddler/foo

$:/fn/the related tiddler/bar

and then retrieved it as:

<<fn foo>>

in the context of the related tiddler, then you could do all kinds of magick with those footnotes ...and all that would be missing is some simplistic plugin that, instead of using some markup in the tiddler, would go create those "under-the-hood"-related system tiddlers being the footnotes... which it would be most trivial to later on list with whatever eye-candy you fancy most.

Based on a given list of chapter tiddlers being rendered each with their individual, related footnotes tiddlers you could as well easily generate one big list of footnotes. All you need is for your footnotes to be actual tiddlers. Hence system tiddlers since you may not actually want them to be searchable on their own.

However, you could easily run into problems with the above approach if you ever chose to rename those titles. So, one crucial missing piece to safely model stuff like this, is that eventually TiddlyWiki will bring core support for every single (non-system) tiddler to have an auto-generated unique id, so it would be:

$:/some-unique-id-12345/foo

$:/another-uniqueid-54321/bar

With the eventual tiddler being:

title: some related tiddler

id: some-unique-id-12345

Refer to <<fn foo>>.

Am I making sense?

Best wishes,

Tobias.

--
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 https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e7f95d27-4dcc-4fab-bdce-eb968c8c07cf%40googlegroups.com.