Conflicting labels cause weird bundling (with a couple suggestions)

[jakelauer]

If an email receives two labels, it will end up in two bundles at the same time. This causes some confusion for me, because my bundles have purposes - I may draw different conclusions about an email based on the bundle in which it appears.

For instance, if I have an email which gets marked as both "Newsletter" and "Important", I might archive it without thinking if I open up my Newsletter bundle first.

A couple ideas for avoiding this:

• Allow me to configure Simplify with a prioritized label list which I fill in.
  • If it's empty, or if I don't put both of the labels in the list, the behavior is the same as it is now. If one of the labels does appear in the list, the email goes into that bundle. If both labels appear in the list, the email goes into the highest-priority bundle
• Provide a simple toggle to choose between emails appearing in multiple bundles or just one
  • Feels like this could be problematic if an email has two labels, but only one of those has a bundle at a given time
• Show something in the UI to denote emails which are also inside another bundle
  • Seems like this would only be effective if it were accompanied by multiple ways of archiving:
    • Archive entire bundle
    • Archive this label only

Anyway, just some ideas!

---

Simplify v.3.1.3 configuration: aAX appNavOff avatarsInList avatarsZoom boldHighlight bundleInbox caA caI caL caS cfC cfO cfQ cfR cfU composeActions composeFab dateGroup defaultTheme fontList fontMsg fontNav gaArchive gaRemove groupHideFirst groupInbox groupOtherLists hideAds hideExtWarn hideFileIcons hideImportance hideInboxHideAllLink hideLabelChips hideListCount hideMsgCount hideMsgReactions hideMsgReplies hideNavLabels hideSignatures hideTabIcons importantBadge inInbox inList invertAddons invertCompose izBgDefault lightTheme listWidthXLg lowDensity maDone maLabel maMove maPin maTask matYou msgWidthSm nPane navOpen newNav newUI reminders rightImportance rightLabels rightStar sendLater simplify simplifyPrefsOpen unreadDot vPane1line- System: Mozilla/5.0 (Macintosh Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 - gmail.pinto-server_20240104.06_p1 - Window: 1728 x 972 (100pct zoom) - Language: en - Errors: / 11589:52: Uncaught TypeError: Cannot read properties of null (reading 'previousSibling')

[leggett]

This is definitely a tough situation to handle. I don't think the first two approaches are tenable. The first one is way too complicated. The second one is too unpredictable.

The third one could be made better if I add an option to hide the label for the expanded bundle. You would still need to expand the bundle to see what is in it but to your original scenario... You open the Newsletter bundle and instead of every message having a "Newsletter" label and one having a "Important" label (might be easy to miss), you would only see labels that aren't "Newsletter" making it more likely you see the "Important" label

There might be a way to hint at this in the collapsed bundle too (maybe I show other labels to the far right) but I'm not sure.

There are other things you might consider doing:

• Make the color of the Important label stronger so it stands out more
• Tell Simplify not to bundle anything with "Important" in which case it shouldn't be in the Newsletter bundle to begin with

[jakelauer]

I agree with everything you've said. I hoped against hope that the first one wasn't all that complex given that Simplify already provides a way to skip bundling for labels, but it sounds like they are different enough to be problematic.

Part of the reason this matters is because Gmail's filtering is honestly super rudimentary - there's no way to reorder filters without exporting them all, editing the XML file, and re-importing, and there's no way to stop processing filters. This makes it super tough to write filters to avoid multiple labels. I'm tempted to write a filter manager extension!

[leggett]

Sounds good. Do you think what I described would help your situation?

I hope to tackle filters at some point. It might even be what tips me into offering more functionality if you give me limited API access (I believe you can ask for API access to just filters).

[jakelauer]

The colors help a bit, since I know to look for it. I think that's kinda the crux of the issue - if you know to look for it, it's not so bad, but the whole point is that you might not look.

Filters could work well if managed appropriately. You could even implement a faux "stop processing" system for any filter thusly:

• Create a filter which applies a label (MyFilter) and checks the "stop processing" box
• Programmatically create a second filter with the same rules as the first, ordered immediately after it, which applies the filter-stop label
• Ensure all labels include a -{label:filter-stop} parameter
• If possible, remove the filter-stop label at the end.

The good news is I never gave a rat's ass about any of this until now because labels were pretty useless for me, but now that you've added Bundles, labels (and by extension, filters) are supercharged with value.

Does nesting labels affect this system at all?

[leggett]

Bundles work fine with nested labels. I don't truncate long label paths in the same way that Gmail does which makes them a little worse but I think I can fix that.