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

Re: use current folder name as argument to abitrary command



* Cameron Simpson <cs@xxxxxxxxxx> [2009-05-26 18:20 -0500]:
> On 25May2009 22:30, David J. Weller-Fahy 
> <dave-lists-mutt-users@xxxxxxxxxxxxxxx> wrote:
[ ... snips ... ]
> | Brought a tear to my eye!  I just spent ~30 minutes trying to trim
> | away the macro, but I have not been able to yet.  I'm sure my
> | understanding of mutt's quoting levels is insufficient as of yet.
>
> You probably can't reduce it, given the order in which things need to
> happen.

Yep, I was coming to that conclusion.

[ ... snips ... ]
> | >   because we need to construct a mutt-level ""-quoted string, and
> | >   also it has to happen in the folder hook because we don't have
> | >   the folder name before then.
>
> It has to happen inside the folder-hooks because it needs to be
> re-applied if you switch folders. Also, (if you didn't want to update
> on a folder change) I think I established by experiment that the main
> muttrc is sourced before opening your first folder, so you can't ask
> for the folder name then.

I should have been more specific.  I understand why the folder-hook has
to be used, but don't quite get why the mutt-level ""-quoted string
can't come from something like the following (doesn't work).

#v+
folder-hook . 'push ":\\\`~/.mutt/listbox-to-email.pl\ $my_folder\\\`<enter>"'
#v-

I do not understand why the macro is required to force mutt to parse
that ""-quoted string, and now I'm wondering if there are any other
constructs which would allow the same level of parsing without defining
a macro... hrm.  Methinks I need to read more of the source, manual, and
wiki to understand, but that may have to wait until I get more
round-tuits.

> BTW, something I may raise in another thread: the output of
> cs-mutt-per-folder (or whatever command you put in backticks there)
> _must_ be a single line of text. Mutt reads just the first line and
> closes the pipe, producing a Broken Pipe signal in the script and
> discarding following lines. So the script should produce:
>
>   mutt-cmd; mutt-cmd; ...

That is odd, but workable.  Also I found something to watch out for when
using this method: Make sure your script *always* produces a command
recognizable to mutt when run, otherwise the lack of a command will
cause an error.  For example, when run in my =lists folder my particular
script does not emit anything.  As a result, I receive a ': unknown
command' message on the status bar.  No harm, but it can be prevented.
I used a "set wait_key\n" just to test, and it prevented the message.

Regardless, this works for me and I'll be using it from now on.

Thanks again!
-- 
dave [ please don't CC me ]