<div class="markdown">
<p dir="auto">Sorry about the long technical reply, but you might find it interesting.</p>

<p dir="auto">On 16 Feb 2015, at 1:03, Allie Martin wrote:</p>

<blockquote>
<p dir="auto">On 15 Feb 2015, at 15:06, Shoshanna Green wrote:</p>

<blockquote>
<p dir="auto">I'm currently trying out MailMate; though I can't switch to it until it has a "correspondent" column,</p>
</blockquote>

<p dir="auto">I'm wondering what I'm missing here. :)  I've found useful features by simple exploration.  However, the help is not being very helpful on exactly what a 'correspondent' is in the context of received messages or threads.</p>
</blockquote>

<p dir="auto">It's not documented except for what I wrote in the release notes when I released r5056 as a test version.</p>

<p dir="auto">The “Correspondent” feature was requested by Shoshanna and I implemented it, because it was an interesting generalization of what MailMate can already do. Internally, MailMate has a system of “specifiers”. It's based on regular expressions and it's what allows you to match on a specific part of a header. For example:</p>

<pre><code>To ▸ Domain
</code></pre>

<p dir="auto">The above is actually an abbreviated form. The “real” specifiers in use are:</p>

<pre><code>To ▸ Split ▸ Address ▸ Domain
</code></pre>

<p dir="auto">This is all defined in a text file within the application bundle named <code>specifiers.plist</code>. (Hardcore users can define more specifiers in a file in the app support folder although I don't make any promises that I won't change how this works some day.)</p>

<p dir="auto">The limitation of the above is that it cannot use information unrelated to the header name/value. For example, it cannot change behaviour depending on whether or not a given address is a user identity. This is what I changed with the introduction of the “Correspondent” and “Identity” specifiers. These are <strong>hardcoded</strong> functions which can be applied to various address related headers. For example, given this header,</p>

<pre><code>To: someoneelse@example.com, me@example.org
</code></pre>

<p dir="auto">the various specifiers would result in these values:</p>

<pre><code>To ▸ Domain:                  example.com, example.org
To ≫ Identity ▸ Domain:       example.org
To ≫ Correspondent ▸ Domain:  example.com
</code></pre>

<p dir="auto">Most importantly, these function specifiers can be used to separate email addresses into user identities and correspondents. This allows a message list column which only lists the correspondent when both sent and received messages are present in the current (smart) mailbox. This also requires (the already existing) feature of the specifier system which allows matching on multiple headers. In <code>specifiers.plist</code> it looks like this:</p>

<pre><code>"#any-address" = {
        specifiers = ( "from", "to.split", "cc.split", "bcc.split" );
};
</code></pre>

<p dir="auto">Given the features above, the configuration file for message list columns (<code>outlineColumns.plist</code>) defines a “Correspondent” column which uses the following format string:</p>

<pre><code>formatString = "${from.#identity:?➜ :}${#any-address.#correspondent.name:${#any-address.#correspondent.address}}";
</code></pre>

<p dir="auto">In English: If the from header is an identity address then prefix “➜ ”. This is followed by the first name of an address found in from/to/cc/bcc which is a correspondent. (The name is preferred, but if it doesn't exist then the email address is used instead).</p>

<p dir="auto">I wrote “if the from header is an identity address”, but it's really more like “if a from value exists after the from header has been filtered through the identity function”.</p>

<p dir="auto">This feature can also be useful when searching for messages to be able to do things like “To ≫ Identity does not exist”. This limits the search to messages not sent directly to a known identity of the user.</p>

<p dir="auto">Finally, this feature might be most useful when used with the “Submailboxes” feature in the mailbox editor. If both received and sent messages exist in a mailbox then it might make more sense to partition messages based on Correspondent or Identity than to do it based on any specific address header.</p>

<p dir="auto">Sorry if this turned into an explanation of how it works instead of how it is supposed to be used :-)</p>

<p dir="auto">(Since I have just implemented this feature I do not claim it works exactly as explained above, but let me know if it doesn't.)</p>

<p dir="auto">-- <br>
Benny</p>

</div>