[MlMt] Bundle input types other than canonical

Brett Terpstra me at brettterpstra.com
Fri Apr 18 12:28:39 EDT 2014


Ok, I'll play with the types listed and see if they do what I expect. I 
guessed around last night and hit some of those, but wasn't seeing what 
I thought I would. I'll let you know. Other answers inline.

On 18 Apr 2014, at 9:41, Benny Kjær Nielsen wrote:

> 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 ;-)

Consider it asked.

>
>> 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).

What I want to do is run my own custom html2text on the output and save 
it to a text file (for nvALT import purposes). The output I was getting 
from canonical was already "markdownified" in most cases, and it seemed 
that with html, there were cases where it would send nothing at all 
(assumed it was because there was no html section). If decoded provides 
the Content-Type boundaries, I can parse that...

>> 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.

Any chance that when there's a selection and the current view type is 
HTML, it could send the raw selected HTML to the output? As in, 
MM_SELECTED_TEXT instead of just a range?

-Brett

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


More information about the mailmate mailing list