Jeff King <peff@xxxxxxxx> writes: > Just to note some prior art, mutt's "<pipe-message>" faces a similar > problem. You might want the raw message (if you're going to poke at > headers, MIME parts, etc yourself) or you may want a decoded one (if you > just care about body text and don't want to deal with base64, qp, etc, > yourself). They provide a stateful config knob, but then you end up with > horrible macros that toggle the knob, like: > > :set pipe_decode=yes<enter><pipe-message>my-script<enter>:set pipe_decode=no<enter> > > I think having two separate commands for the two modes would be less > confusing. Yup, I have been suffering from its equivalent in Gnus/Emacs every day, where decoded version of multipart/signed messages look different enough from valid RFC2822 messages and break application with "git am", and there of course is "feed the undecoded original to pipe" option. But the need for both is pretty much known, and the real issue is that what the default should be. The default destination of the pipe being a pager, making the colored output the default is consistent with that, I would think. Thanks.
