Ongoing questions.
There’s a tiddler that’s all about Beaker, but not the Beaker-saver tiddler. I’m not sure it’s even currently accurate. It has no tags. Where would this external material go?
To me, all the language icons should go under languages or under languages/icons (new dir). Thoughts?
What to do about multids? For instance, all the tiddlers with prefix tree-macro-example- belong to the same multid. Not sure how routing would work for that.
I have been thinking about that as well. I am not sure that the filter paths mechanism knows how to handle multids. So perhaps we just ignore it for now which should mean that it stays where it is. I don’t think you can edit that from node.js anyway, can we?
Agreed.
Worth keeping in mind that tiddlers that don’t match any filters will stay where they are. So perhaps this is a tiddler that needs to be flagged for content review before we decide if it is even relevant at present.
.multids can’t be edited from the wiki.
All the filters so far have been one-tag, one path.
Can there be filters that use more than one tag?
For instance, the language icon tiddlers have tags “Language” and “Icons”. So if there was a filter that came before tag[Language] and looked for tag[Language]tag[Icons] then there would be no need for a slightly redundant tag “Language Icons”.
But I didn’t know if there was a policy behind the one-tag/one-path system.
Anything that is a valid filter expression should be OK to use.
Prefixes too? Or too uncertain?
In terms of what is supported technically, any filter expression will work.
However, I personally think we should avoid using prefixes, from the point of view that it will be much easier for people writing documentation to know that the path depends on the tags without having to take other criteria into account.
It appears that I can’t use a cascade inside a cascade. The inner cascade wins. Of course I might not be doing it right.
My objective was to add filters that would pare the list down without having to change Saq’s code and without losing track of things that have to be reviewed later. But also without creating dozens of single-entry filters. Being able to omit my own bundles of tiddlers seemed like a good organizing mechanism.
New demo that updates with latest tw-com content at least once an hour (though I will need to wake up and check that actually has been running as anticipated): TiddlyWiki — a non-linear personal web notebook
This was a real rush job so hopefully it all works and I have not broken anything.
It looks like you’re not pulling from the tiddlywiki-com branch.
@Mark_S could you please explain why you think that is the case?
A quick glance at the Recent tab shows all the latest changes from tiddlywiki-com reflected in the demo.
Note that you may need to update the pathFilters to include your latest work.
Maybe branching isn’t the problem, but your file doesn’t reflect recent changes.
See ““Dynamic Tables” by Jed Carty” which is incorrect on TW.com paths — 5.2.1-prerelease but was corrected 3 days ago, merged, and shows correctly at TiddlyWiki.com.
Mark note that I posted a new URL for the new test wiki:
https://saqimtiaz.github.io/sq-tw/temp/tw5paths-testing/
I did not want to overwrite the previous one without being sure the new one was working properly.
Ah, good. I was worried I had misunderstood the nature of the task.
The filters don’t seem to be up-to-date. For instance, items tagged “Demonstration” were showing up. There’s been a lot of new filters added and a lot of tags updated in the last 36 hours 
Thanks!
No worries. I set that up bleary eyed after a 16 hour day of work… so I tried to do the bare minimum to help you keep making progress. I will update the filters when I get the chance but I expect you will need to keep copy and pasting over new ones as you work.
My worry was that someone else would assume that the filters are up-to-date and attempt changes accordingly.
Thanks!
As you can see from the table below, all but two of the items tagged “TableOfContents” follow the pattern where the path name is the same as the tiddler name only in lower case.
So I’m thinking that a filter could be used that follows the “name in lowercase”, but that the two exceptions will be placed first, and hard-coded. Since this is the only path group that would be calculated this way, I thought I’d check if this seemed like a reasonable approach.
| Tiddler | Old Path | Computed |
|---|---|---|
| HelloThere | hellothere | hellothere |
| Learning | learning | learning |
| Working with TiddlyWiki | workingwithtw | workingwithtiddlywiki |
| Customise TiddlyWiki | customising | customisetiddlywiki |
| Features | features | features |
| Languages | languages | languages |
| Editions | editions | editions |
| Plugins | plugins | plugins |
| Platforms | platforms | platforms |
| Reference | reference | reference |
| Community | community | community |
| About | about | about |
I think the problem with a filter that uses the name in lowercase will be that it will match every tiddler not matched by another filter. If we use a tag qualifier in the filter that should be OK but see below for why it might not be needed.
These tiddlers are the ones that describe a “category” and then there are other tiddlers in those directories with that tag. We could just leave them as they are. If I remember how the mechanism works correctly, existing tiddlers that do not match a filter should retain their original path (though we should confirm that).
I think our bigger worry is going to be tiddlers that are routed to the correct directory, but the filter mechanism generates a different filename. Editing any of those tiddlers via node.js will change the filename.
@Mark_S Instead of workingwithtiddlywiki I would prefer working-with-tw. IMO it’s much more readable and less to type if you create tiddlers with an external code editor.
I would like to have all paths the are currentyonewordwhichnobodycanread to be currently-one-word-which-nobody-can-read … IMO it would also make typos much more visible.
If I understand Saq correctly, then at the moment we’ll just leave these where they are.