sorry what - hashtags? 
do you then have filters and etc kind of organisations tools using hashtags, that’s another whole dimension to this !
Have you adopted a solution to support these?
Wrapping such hastags to turn them into missing tiddler titles [[#hashtag]] would be a start.
I have “played” for altering the parser and the $link widget to detect #title in content and make it into a link
- Along with the above title method this makes hashtags visible as
links[]andbacklinks[]and missing tiddlers (if missing) in which caseprefix[#]allows you to list all “hash tags”.
The key advantages with turning hashtags into titles is opening them up to further use all without filling the tags fields up.
That is my default position, that “too many tags in the wiki is tag pollution”, however if a lot of tiddlers require a lot of tags, especially if the number of tags causes a new line in the list of tags on any given tiddler indicates the wiki is being “driven” by mostly tags only. I think it fair to consider this a different case of “Tag Pollution” or overuse.
A tool to find one or more hash tags in a tiddler text when viewing that tiddler would be helpful but if they are titles, even missing titles, then freelinks plugin can highlight them (unnecessary If the parser made them links)
somewhat related to the topic, you can create a tiddler icon cascade template to show the permalink-button icon to all tiddlers or specific ones that meet a filters criteria.
I used to do this, though I was a bit bummed by it not actually adding the tiddler title of the permalink-button to the icon field of the tiddler.
same can be applied by automatically coloring tiddlers.
I used to group my tiddlers based on ‘topic, category, status’ where every tiddler was a topic, if a tiddler was tagging any others, it would be a category, and some category tiddler tags were status categories, i.e. ‘topic > category > status’ and thus would apply colors and icons defined by this.
I don’t remember if manually adding a tiddler title to the icon field would override the Tiddler Icon cascade or not, but im sure if it doesnt you could just add a condition in the filter like [!blank[icon]then[....]] or something to that effect.
(sry, doing this from my phone, might be some typos)
The thread is about TW Tags, not #hashtaggery, so I will keep this short.
MY specific use of #hashtags in Tiddler body text is very simple.
It is the easy way to Find Content Without Complexity.
Example “#test” …
TT
almost like two tag types, or tiddler tags and hash tags. how many types of tags is too many though 
1 Like
I suppose it’s all in the name, tags are on the tiddler hashtags are in the content, if we wanted we could add features to tiddlywiki to turn hashtags into titles, these links allow you to open and see related hash tag, items but we could also divide tagging between tags and hash tags and even use the existence of a named hash tag within a tiddler to behave like a tag in the various cascades.
- perhaps even list hash tags in a tiddler bar like tags
- perhaps even click to navigate to a hash tags position in the text
This could go a long way to reducing standard tags field, tag pollution, while adding new features.
Keeping in mind it adds no more complexity, only features to how you use hash tags @TiddlyTitch
but wait, there is more, the steak knives 
If we return to the beginning of this topic we see the issue of naming tags with a prefix and the pros and cons. it comes to mind that when we use tags to construct a table of contents the titles are somewhat different and less likely to be the type of wordy title tags we would apply a prefix to, they tend to be existing tiddlers, that are not utility tags and tiddlers like @Springer speaks of. They, TOC tags would also tend to be only one on each tiddler, which indicates the parent.
- this makes me think once again there is another opportunity for innovation here.
for example what if TOC tags, typically a title in a specific tag hierarchy, could be selected from a specific tag heirachy but not appear in the standard tags dropdown, Thus not intefear by making that list much bigger.
- perhaps we use an alternative tags field for this but I think we could do better.
- what if we flag the top tiddler in the hierarchy as a root tiddler, it is also a tag tiddler, then the user can select from a list of root tags or any child below?
- this method could be used to replace the tag prefix idea
Similarly we could insert hashtags in text from a dropdown of existing hashtags from the editor toolbar or just type it of course.
all of these enhancements are achievable and not rocket science 
to implement, but most importantly once available, will be easy for users to understand and use, and to me that is compelling.
Okay.
Call in-text category markers preceded by “#” ‘Category Markers’ rather than “tags” 
My point was nothing special. “#hashtags” are simply text. Finding them is just text search.
They have a big, easy, relevance to Tiddler search.
But they do nothing other than be text.
TT
1 Like
It’s an interesting idea. I think at times it might work for me. But more often it wouldn’t work. I have numerous wikis similar to my SQL Playground or Periodic Table where the root of the TOC contains a mix of top-level information about the wiki and TagTiddlers that I will use in other places besides the TOC.
I know you have done a lot of work on alternatives to standard tagging. I’ve found little need for that myself. I find standard tags cover nearly everything I need for categorization and organization, except for one thing: in a number of scenarios, they are problematic for TOC’s. Tag-based TOC’s are simply not flexible enough for me in many cases. For my use-cases, the trick is not in updating tag handling but in using better TOC tools.
Agreed. And the one from @EricShulman is as well, both adding flexibility in different directions.
But my needs are sometimes still not covered. I’ve taken to writing custom TOCs for various wikis. I haven’t yet found enough commonality to consider attempting a generic solution for them… although I hope one day to be able to.
Just one example: RHAM Policy Manual. In this far-from-complete wiki, the TOC is generated almost entirely from the structure of the titles.
For instance Policy5113(HS)(I)(A) (usually known by its caption, “Excused Absences”) is a child of Policy5113(HS)(I) (“Classification of Absences”), which is a child of Policy5113(HS) (“Attendance Policy (High School)”), which is a child of Policy5113 (“Attendance Policy”), which, finally, is a child of Section5000 (“5000 - Student”).
All of this is handled by a custom TOC implementation, which is modeled after the one in the core, but uses the title structure instead of tags to calculate the hierarchy. The TOC should look like a standard one, but it’s a very different implementation.
This is a useful technique for wikis that are mostly hierarchical. But it would likely be entirely inappropriate for other wikis I maintain.
And now that I write this up, I can start to imagine a common implementation. I will try to think it through soon.
1 Like
I think that’s totally fair, for this special usecase. Our toc-macros have been written in a way, that they can be modified. It’s the recursion stuff that is hard to understand for new users. But if you dig into it, also customising the core TOCs is possible, without completely overwriting them.
There are a lot of “sub procedures” now, that can be locally ovewritten, without overwriting the global macro. The only thing missing here is more step-by-step examples
-m
Probably mainly because the docs is not finished yet. That’s totally my fault.
Right. The idea that’s starting to come to mind looks something like this:
<<my-toc
top-level <!-- filter yielding root elements -->
get-children-proc-name <!-- macro/procedure to get children of node -->
template <!-- (optional) template to display current node -->
config <!-- see below -->
>>
The recursion would be automatically handled, by calling the get-children proc at each node; it’s not clear if that would return a filter or a list of titles. But it would be one or the other, and the top-level parameter would do the same. The template determines how a node itself is displayed, without worrying about its children, or the chevrons, etc.
config would be a little different. I don’t see anything better than a JSON string, which isn’t as TW-friendly as I would like. I’d like to hear alternatives, if you have any. This would allow us to override various bits of configuration. I’m imagining things like:
{
"Customer": {
"sort": "[sortsub:string<-last-name-then-first>]"
},
"Order": {
"children": "[tag[LineItem]order-id{!!id}sort[row-number]]",
"template-name": "$:/my-app/templates/order-overview"
}
}
The various properties would come from the parameters or default values if not supplied here. And I would expect that most often users would be using defaults; even when not, only a few titles would have any overrides. But I would want the additional flexibility to be available.
So far, I’m just dreaming about it from a user perspective. I haven’t yet thought at all about the implementation.
Perhaps I can Help document it?
It is true if we documented recursion more with loop detection, it would be easier for many to write their own TOC’s and I think your “TOC by parsing compound hierarchical titles” will reoccur if not only occasionally. It may also be a good example of using compound titles for those that have them already.
other structure
With a view to presenting other organisational structures of tiddlers in a wiki I think of the simple ordered serial list a tag can represent, but also parent fields, dynamic filters within every tiddler describing its children etc… but also @Scott_Sauyet’s compound title model, It leads me to think about separating parts of a TOC macro,
- the list of items in the TOC
- the relationships displayed on screen and in navigation
So what if a flat list of titles was given to a procedure that was then able to use/discover the structure in which to display them?
My breakdown is a little different. I think we need
- A list of tiddlers to show at the root.
- A method to choose the direct children of a tiddler
With those two, we can derive the entire hierarchy. Note that we would work with either lists of tiddlers or filters. I’m guessing that the former would be simpler, but either should work.
My version is a quite a bit simpler than the core TOC model; using the titles the way I do, there is no need for duplicate checking, for one thing. Also, starting from scratch lets me avoid worrying about the many features included in the core TOC. To make this generally useful, we’d probably have to address a sizable subset of those.
I definitely wouldn’t know how to go about that, not in any generic manner.
Me neither, I was not thinking generically, only that we can obtain a list, perhaps from the taggingtree macro that iterates a hierarchical list according to a filter. The result is a list of tiddlers, a filter could reduce or change it in some ways. Then I was thinking are there opportunity’s to process that list and present it in different ways such as a graph, or hierarchical list etc… keeping in mind the need for appropriate structure information to be available on each tiddler and an additional filter perhaps.
I am trying to see if we can separate the list of titles from the structure, but recover that or use alternate structures in its listing.
- This allows other lists to be processed as well, perhaps discovering structures we did not see before hand. An example may be inferring the structure inherent in your compound title data.