[MlMt] Bundle input types other than canonical

[Benny Kjær Nielsen]

On 18 Apr 2014, at 4:46, Brett Terpstra wrote:

> Are there any input types available besides "canonical"?

Yes, the current input types are:

* none (the default)
	
	No input

* raw

	The message in its raw format. This is, for example, suitable for 
exporting messages to other email-capable applications.

* decoded

	MailMate decodes the body part if it is encoded using 
quoted-printable/base64. This is primarily useful if sending specific 
body parts to a command. For example, an image would be given to the 
command in its raw (original) binary format. This is not currently used 
by any of the included commands.

* canonical

	Text body parts of the message are decoded, deflowed (`format=flowed`), 
and converted to UTF-8 equivalent to what happens before displaying a 
non-HTML message.

* html

	Currently equivalent to what happens before MailMate displays a message 
in its Webview which means that even a plain text message is converted 
to HTML. This is probably mainly useful for display purposes.

* selection

	The currently selected text in the message view.

* formatted

	Requires an additional `formatString` key/value pair for the command. 
This is mainly useful for obtaining specific information from a large 
set of messages.

The last one is quite powerful (and fast) if you want to retrieve data 
for some kind of statistics. For example, retrieve all sender names of 
all selected messages like this:

	formatString = "${from.name:No name available}\n";

This is well suited for further handling, e.g., by standard UNIX 
commands. For example, a top 10 of senders could be done like this:

	sort -f | uniq -ic | sort --reverse --numeric-sort | head -10

If the receiving command can handle it then it's also fine to use the 
`formatString` to provide multiple values:

	formatString = "${from.name:No name available}\n${subject.body:No 
subject available}\n";

When/If event types are expanded then it'll be possible to change how 
MailMate displays messages by making, e.g., `canonical` -> `canonical or 
`html` -> `html` filters. Filtering before generating a reply is also 
going to be possible, e.g., to remove extraneous whitespace, reflowing, 
or automatically cut signatures.

I guess that makes part of commands semi-documented. You might want to 
ask about `output` types as well ;-)

> Is there a way to force HTML to the bundle if it exists,

I'd probably need to know your use case to know whether or not MailMate 
can do what you want. Using the `decoded` input type, the main problem 
is that you need some way to tell MailMate to use the HTML body part as 
the input for the command. This it tricky if not impossible (depending 
on what you are trying to do).

> regardless of preferences?

The commands are never affected by display preferences.

> Also, how does MM_SELECTED_RANGE work when the input to the command 
> isn't the same format as what was selected in the viewer?

In a sense it's never the same format since even a plain text message is 
displayed as HTML. To provide `MM_SELECTED_RANGE`, MailMate 
heuristically re-locates the selected text in the canonical text when a 
command is executed. This currently does not happen for the `html` input 
type.

-- 
Benny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20140418/39a6ca7b/attachment.html>