HC, Thanks for starting this discussion - it really helps both learning and development to run such threads.
I would find a limit on the tags would inevitably confuse me and possibly result in my creating new tags of a similar name. Personally I just quickly type a number of characters to quickly limit the choices, perhaps a small delay rather than a character limit would allow you to do the same rather than limit it to three characters, or a setting like for search that sets the minimum number and the delay time. I have a different perspective" To me tags are a quick to use ad hoc method for selecting/categorising tiddlers. This extends to tags that group tags like "status" could tag new, inprogress and done, but they need to be removed as well as added. This is one case where a single value in a field works better. Personally I try and avoid tags and use fields instead because I try not to "pollute" the tag space. I may even use tags initially then migrate all tiddlers so tagged to all tiddlers with a given field/value. Not withstanding my alternate approach what would I do if I had too many tags. first I would find a way to divide them into subsets, the simplest being tags with a given tag, or tiddler vs system tiddler. It is only once you find a way to group your tags can you build something to view a subset of tags. I would tend to keep the default drop down or tag search and build another restricted in some way by a filter. For example every status tag could have the field status and have a method to select a tag only from the status tags etc... The selection of status tag may only appear on tiddlers with an field object-type with the value task, object-type[task]. However for a really intense user of tags marios alttags/gentags plugin allows you define multiple tag fields, and the available tags in each alternative tag group are only search for within the existing tags used in that tag field. In the longer term I would like to see us developing more list fields like tags and provide a method to migrate tags to these alternatives. Tags are a wonderful free method of "tagging" but more often that not we actually use tags as keyword list, a status of which a tiddler can only have one at a time, or primary categories where only one category can be assigned and/or multiple category fields. Another is a keyword field that one adds search terms you want found but that do not necessarily appear in the tiddler. In the world of data/knowledge and Information management there are a set of well known concepts such as tags and categories (subjects/Domains/Genra are others), for which I would like to see a mechanisium to define and use these as part of the Standard distribution. To me these would mitigate the need to deal with large numbers of tags. Not withstanding my different approach I see no reason not to enable a filtered tag selector to help in your case. Let me know if you would like one developed. I think a tag pill style that allowed to to tag from its dropdown according to a filter would be nice. Regards Tony On Friday, February 7, 2020 at 11:06:26 PM UTC+11, HC Haase wrote: > > > *TLDR:* > *Problem:* the tag dropdown slows down when you use to many tags > *Proposal:* 1. only show e.g. first 10 hits and cycle through pages or > 2. require min. 3 characters before showing results (like the search) > > *Problem* > I see it mentioned more and more here on the forum, and I am beginning to > experience it in my own wiki. When the tag space gets big, the dropdown > tag-picker slows down a lot (in edit and in view mode). It is especially a > problem on mobile/android where it can make the hole wiki unresponsive for > a long time, but it also happens on my desktop now. > > If you use the journal button hand have a journal tag, it quickly becomes > impossible to press that tag pill > > I am also wondering what is the point of the tag pick drop-down? For me, > it is to quickly choose a tag. But if I get 50 tag suggestion, that will > not help me find what I am looking for. So I type instead to limit the > relevant suggestions. So why have all tags shown in the tag-picker to begin > with? It would make more sense to only see a limited number of hits. > > Some might say that one should avoid to many tags to solve this. But that > is not a solution IMO. Tags are what makes wiki'ng great, and they are > visible unlike custom fields. In TW tags are both network/categories and > hierarchy. Therefore, we need a lot of tags (the strength becomes the > weakness). > > *Proposal* > I see two possible solutions to this. The first I think would be the best. > > 1. > Limit the tag-picker to the first 10 hits and have button to cycle to next > 10 (maybe have a setting where you can change the number of hits from 10 to > whatever) > > 2. > In edit mode, require 3 character in the input before showing results > (like for search) > > > *Discussion* > I like the first solution best because this will show you tag suggestions > whit out any input and it* solves the problem for both edit and view mode* > tag-picker. > > > I also think that whatever solution for this, should be a part of the > core. As the problem with too many tags is a fundamental scaling problem > that can hit everyone. > > > What do you think? > Do you have a better idea for a solution? > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1f4f8965-5613-4d62-9d3e-fb1c1629943b%40googlegroups.com.
