<<< Date Index >>>     <<< Thread Index >>>

Re: Patch for "tag-prefix and macros" bug



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/&lt;End&gt;&lt;end-cond&gt;\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