This “Only Exact Tag Matches” feature primarily falls short when multiple tags of the same type are applied to a single item. Legend “works” best when only one tag of any type is used per item. Most “item properties” can only be applied this way – priority, star, complete, and dates can only be put on a single item once. But +tags and #tags allow multiple tags per item.

In over 4 years with Legend I’ve always tried to respect the (unofficial) “one tag per item” rule, but my application simply requires more than two “dimensions” (+contact and #tag) to some items. I have a rough new “system” running now and it’s substantially better than any predecessor – because I finally broke the rule. I know this is not unusual because other users are asking for “hierarchial tags” which tells me they have similar needs – they are also using #tags to mean multiple things. The problem is that breaking the rule makes filtering more finicky and Group-By Panes kinda falls apart when these doubled tags come into play. That’s wher this “only exact tag matches” button comes in.

My ideal solution would be to add more types of discrete tags (with their own styles and trigger prefixes). @tags, $tags, %tags, etc. One could be used for each distinct “dimension” the user needs. I’m basically doing this already by assigning #_ tags, #$ tags, and #@ tags. It’d be a good ‘pro’-tier feature. This would not only obviate the need for a “tag manager” but also make Legend way more powerful. But I suspect this will not happen soon (if at all).

An interim solution would come from simply fixing the function of this button. Everybody who is using “hierarchial tags” would immediately get more use out of the Group-By Panetypes. It just needs a little tweak to its definition: instead of “only exact tag matches” how about “groups only for matching tags”?

This isn’t a huge change but I think it describes the desired functionality well. That is to say:

Start with unfiltered Document.
Apply filter to Document.
Check if user’s filter contains a string with “#” or “+” (depending on panetype)?
If so, then generate the Tag/Contact Groups based only on tags that match the filter string.

There is an alternative approach, too. It might be harder but it could be applied to ALL the group-by Panetypes – and that could be valuable. That would be a separate filter for the groups themselves. This would work exactly as I describe above except the string to match the groups against would be specified explicitly rather than extracted from the Pane’s filter string. This would be a bit more flexible and possibly more explicit than simply making the current button behave as-desired.

@Jay: This is one of many adjustments to the “less common” Panetypes that I have cataloged, which I feel are really holding back their usability. I primarily use Outline and List panes in my Boards because they are most predictable. Agenda is a bit troublesome but very useFUL so I employ that, too. The group-by Panes are immensely powerful in concept but hard to apply – especially at higher complexities – so I often try them but have to abandon them and revert to a filtered, ungrouped Pane. GB-tag and GB-contact are the best…GB-date panes are almost unusable in all but the simplest cases. I don’t know where this fits in your development plan, but if you were interested in doing a big “Panetypes Overhaul” like you recently did with filters, I would be happy to compile my observations (along with some suggestions, as you would imagine). I think Legend could be dramatically improved by making a refinement pass through these Panetypes – no NEW features, just rounding out the existing ones.