Nobody’s bad. Miscommunication happens all the time. Thank you for your efforts and for persevering.
I’m afraid you may be missing the point that this is working pretty well already. The plugin does what it’s supposed to do, and I think is getting pretty close to clean. I just want to make it somewhat more configurable by letting experienced users override the markup it generates.
This seems relevant:
Thank you. That makes sense. I will try to take it into account in the future and in the next clean-up of this code.
tags[]says list the titles of all tags on the current tiddlertag[Wizard]says for each title from above (the tags) test if that tag has the tag wizard.- Then you sort the titles (tags also tagged Wizard)
I may be wrong but perhaps you mean
[is[current]tag[Wizard]tags[]sort[]]if the current tiddler is tagged Wizard give me a list of all its tags (including Wizard).
No, that does just what I want it to do. The idea is that there are some linear paths through a subset of the tiddlers. My plugin is adding previous/next footers to these tiddlers. To designate a path, I use a TagTiddler, a tiddler with a name to be used to tag all the tiddlers in the path. That TagTiddler must itself be tagged “Wizard”.
Minor aside
In the actual code the name "Wizard" is abstracted into the text field of a tiddler named $:/plugins/ScottSauyet/WizardNav/config/TagName, to allow users to choose a different name than Wizard, useful for instance if their wiki is full of swords-and-sorcerers content. But calling it "Wizard" here simplifies things.
So that filter does exactly what its supposed to do: collects all the pathways that contain the current tiddler. I would expect that in most cases, a tiddler will only be a part of a single pathway, but I’ve already found exceptions in the project that spawned this plugin, so I must be able to handle it.
And I do handle it well enough. It works for me, and at some point I will certainly say that it’s good enough, whether or not I solve this issue. But if I can, I would like to do that extra refactoring in a way that makes overriding the markup clear.
I see you using
[enlist{tag!!list}]which means
- Create a title list from the content of the list field, in the tiddler named “tag”
- This does not sound right to me!
It’s doing what I would like it to. This was suggested by @EricShulman in response to an earlier question. The trick is that if the TagTiddler has a list field, then we should use it, but if it doesn’t, we still need to get all the items tagged with it.
If there’s a better way to do this, I would love to know.
I think you already understand that a lot of similar problems can be solved with nested lists. ie one list inside another. the first (outer) identified each title we want to use the second, inner list uses that title and does what we want to each found in the outer list.
No! That would solve my problems. Although I asked for a list of object-like entities, a list of lists would solve my problem just as well. Do you have a reference for this, or a short explanation? How would I create one? I think I can figure out the macro syntax if it gets a list of lists. This would be wonderful!
In this code
{{tag||$:/core/ui/TagTemplate}}are you intending to get a tag pill for the tag parameter?
Yes. I will probably eventually change that a bit, because I want to highlight the current step and ensure that the current step is in the current window if this scrolls too far. But that’s a much more minor concern to me now. If I can solve the other problems, I’ll get to this.
There’s a tendency when one comes from a programming background to lean on macros, because they look so much like the functions with which you are familiar. But they’re not functions – all they do is text substitution.
That’s probably true of me. But I think in the end, I’m planning on using them appropriately in this case. This overridable macro takes some input fields and creates some HTML/wikitext that will become footers for a collection of macros.
Probably the easiest way to see this is to look at the difference between one footer and multiple footers. If I were to refactor so that there is an overridable macro that handles the markup of the whole footer section, then how would I pass the data that macro needs to show one, two, or many footer blocks? My markup is a single table, with a row per title (“Tutorial” or “Pathway” here). But that means I can’t cleanly use a per-row macro, without also making them implement before and after markup? Creating <table> and </table>, for instance. But if I can pass the whole set at once, then I think I can make this clean enough. @TW_Tones says that there is a way to create a list of lists. That would do well enough for this case, and I’m going to go searching for that information after I have some dinner.
As always, thank you both for your help!