Proposed adjustment of Mailing Lists sub format string

Thanks for the huge effort in pushing this feature to the limit while also documenting it so well!

That said, I'm a bit hesitant with regard to making it the default since the mailbox doesn't really work well for most users. It kind of belongs in the Examples folder, but I'm also considering removing the Examples mailbox and find a completely different way to provide examples/templates for new smart mailboxes, e.g., simply offer them as “templates” when creating a new smart mailbox (when using “New Smart Mailbox”).

Also, the name of the mailbox is only half of the problem. You'll still get a series of identically named mailboxes when the List-ID is misused. We can use this ticket to discuss solutions to that problem:

What is needed is a better “specifier” than the current “List-ID > Identifier”. This is probably very hard or impossible to do with the current specifier system. The solution could be to hardcode support for a virtual header doing the work of your format string, but I don't like hardcoded solutions :)

So, here's an idea. The specifiers.plist file should support providing a format string to define a virtual header similar to the current shorthands. Something like:

"#smart-list-id" = {
    formatString = "\"${...get a name for the list...}\" <${...get a unique id for the list...}>";
};

The identifier specifier should then be extended to also work for #smart-list-id.

The “Mailing List” smart mailbox should be changed to be based on “Smart-List-Id > Identifier” with a very simple format string using the description when available and otherwise the identifier.

The user would still be able to provide a different format strin using their own specifiers.plist.

This general feature might have other uses in the future.

Any comments?

I absolutely agree on all points. As a temporary hack to cope with mailing list gibberish names, I find the proposed format string useful, but it's not a good long term solution.

I actually looked at the specifiers.plist prior to submitting the format string as I also wanted to deal with the actual list-identification more "upstream" than just the naming.

Love the idea of the #smart-list-id approach becoming a generalized feature applicable to smart list specifiers.

Please let me know if there is any way I can further contribute (besides testing development builds).

@Ethan: You can certainly help me by trying out this feature and adapting your regex to work with it. You need to create this file if you do not already have it:

~/Library/Application\ Support/MailMate/Resources/specifiers.plist

It needs to look like this:

{
    parsers = {
        shorthands =
        {
            "#smart-list-id" = {
                "formatString" = "...";
            };
        };
    };
}

The default value is currently based on your string:

"formatString" = "<${list-id.description:?${list-id.description/^[a-z]*\d.*/${subject.blob:?${subject.blob:/capitalize}:${from.name:${list-id.identifier.final-level:?${list-id.identifier.final-level:/capitalize}:${from.address}}}}/}:${subject.blob:?${subject.blob:/capitalize}:${from.name:${list-id.identifier.final-level:?${list-id.identifier.final-level:/capitalize}:${from.address}}}}}>";

But that doesn't work well. We need something like "Name of list" <list-id.foo.bar>, that is, the address-part should be unique and is used for the grouping. This is the important part. The name part doesn't really need to be unique. MailMate will just pick the first one for the name part of the smart mailbox. The mailbox then needs to be based on Smart-List-Id > Address and the format string should be ${#smart-list-id.name}.

Here's the latest update: MailMate r5815.

Benny, just confirming I've got this plist set up and am testing/playing around with it.

The presence of specifiers plist causes a crash on any build after 5898 for me. I had to remove the specifiers.plist to enable upgrade.

@Ethan: Could you send me your file using “Help > Send Feedback” and I'll see if I can reproduce/fix the issue.