On Mon, Feb 02, 2004 at 10:02:50PM EST, parv wrote: > in message <20040203002605.GA77643@xxxxxxxxxxxx>, > wrote Nicolas Rachinsky thusly... > > * parv <parv@xxxxxxxx> [2004-02-02 19:18 -0500]: > > > in message <20040202080337.GA94274@xxxxxxxxxxxx>, > > > wrote Nicolas Rachinsky thusly... > > > I use do use 'end_cond'. If there would be some other similar > > > facility, i would be happy w/ that too/instead. > > > > How do you use it? Well, there are some other legitimate uses for end_cond that make sense (although my Mutt is patch-free with the sole exception of a patch which is now in the official source): macro index $ "<untag-pattern>~T\n<tag-pattern>~R\n<tag-prefix-cond><copy-message>=read_mail\n<untag-pattern>~T\n<end-cond><tag-pattern>~d>5d\n<tag-prefix-cond><copy-message>=old_mail\n<untag-pattern>~T\n<end-cond><shell-escape>make -C ~/.mutt muttrc\n<sync-mailbox>" "supercharged mailbox sync :-)" Now, without tag-prefix-cond, forget about trying to do that safely (unless you don't mind funny things happening when you've got no read or old messages). Without end-cond, the macro would do nothing (not even sync the **** mailbox!) in the absense of read messages, even if you have old messages. It's highly unfair to make you read at least one message every 5 days just so Mutt won't refuse to move your old mail away, IMHO ;-P Still, though, replacing tag-prefix-cond with if-tagged and if-ntagged allows for even cooler stuff to be done: macro index $ "<if-tagged><enter-command>You have messages tagged. Do something with them, dude!<end-cond><if-ntagged><tag-pattern>~R\n<tag-prefix-cond><copy-message>=read_mail\n<untag-pattern>~T\n<end-cond><tag-pattern>~d>5d\n<tag-prefix-cond><copy-message>=old_mail\n<untag-pattern>~T\n<end-cond><shell-escape>make -C ~/.mutt muttrc\n<sync-mailbox><end-cond>" "supercharged mailbox sync that lets you know if you forgot to deal with previously tagged messages rather than simply nuking your tags silently" As for literal <end-cond>s and other stuff like that, isn't it easiest to just add HTML/XML/SGML entity parsing to Mutt's parser? The escape character for it isn't generally used nearly as much as in most other programs, since mutt_bgrun is more likely to do The Right Thing (TM) in most cases, so impact on existing applications won't be that bad. (As further compatibility, the parser can interpret unrecognized entities literally, rather than bombing out with a parsing error.) That way, you can save a message to /tmp/<End><end-cond> with <copy-message>/tmp/<End><end-cond>\n ... and you also get as a free bonus an extra way to escape quotes not intended for parsing by Mutt (say, in a <pipe-message> or <shell-escape> embedded within a complex macro) :-) JMHO, - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpbFnVIUqOyw.pgp
Description: PGP signature