* Cameron Simpson <c...@zip.com.au> [2009-05-02 23:19 -0500]:
> On 02May2009 14:55, David J. Weller-Fahy
> <dave-lists-mutt-us...@weller-fahy.com> wrote:
> | I get two results that I did not expect.
> | 1) I get the "any key" prompt after the shell command executes.
> | 2) my_revdir is not filled with the current folder name.
>
> Ok, you've got a few issues.
Always! ;)
> Mutt config commands _are_ executed in series, in the order in the
> config file.
>
> The keyboard input stream is not consulted until commmands have stopped.
[snips]
> So your wait_key shuffling runs to completion before anything you pushed
> is used. So "push" is not what you want, at least for what you're trying
> to use it for.
That matches exactly what I saw - it's good to get confirmation.
> I also suggest you utilise the `backtick` syntax. Like the shell, mutt
> will use shell output. For example:
[snips]
> So you can go:
>
> `muttecho.sh ...`
>
> in your muttrc. You'll have to escape a little to embed that in a
> folder hook. This avoids a lot of racy mucking around with temp files.
There's the rub, actually - I tried the backticks in an earlier
incarnation (they seemed to be a natural solution), but wasn't able to
get the variable to expand within the backticks. If you know a way to
do that I'll be all ears, but I've been unable to find a way of escaping
the variable which allows variable expansion to take place within the
backticks.
Here is what I tried:
#v+
folder-hook . 'set my_oldrecord=$record; set record=^; set my_folder=$record;
set record=$my_oldrecord'
folder-hook . `~/.mutt/muttecho.sh \$my_folder`
#v-
I then tried escaping the '\' before $my_folder (all the way up to six
'\' characters) with no luck. I tried surrounding the variable with
double-quotes (") with no luck.
I just had an idea, though, which could solve the problem, although it
wouldn't be useful to everyone (it would be dependent on their use of
wait_key). Instead of unsetting wait_key as part of the specific
solution, unset wait_key whenever I'm in my mailing list hierarchy, and
set it to yes whenever I'm not. That will avoid the "restoring saved
state" problem, and allow the shell to return without pausing for user
input.
The commands I tried follow.
#v+
folder-hook +lists* "set my_oldrecord=\$record; set record=^; set
my_folder=\$record; set record=\$my_oldrecord"
folder-hook +lists* "push <shell-escape>\"~/.mutt/listbox-to-email.pl
\$my_folder\"<enter>"
folder-hook +lists* "push <enter-command>\"source
~/.mutt/listbox-to-email.rc\"<enter>"
#v-
These commands did not work as I wanted, but they did work somewhat.
They worked for the first mailing list folder I entered, and then
consistently set from to the last mailing list folder entered prior to
the current folder. For example, if the mailing list folders I entered
(in order) were ml1, ml2, ml3, ml4, ml5; then the from address would be
set to ml1-email in ml1, ml1-email in ml2, ml2-email in ml3, ml3-email
in ml4, and ml4-email in ml5. Very strange, but indicates the
listbox-to-email.rc file is being loaded before being updated.
Some notes about why those particular commands (so I can be corrected):
1) I tried both the source and backtick method of the third folder-hook
with no success.
2) I tried using 'push <enter-command>' because I thought it would keep
the command being executed and reading the resulting file in
sequence (as I understand the order of execution).
> I'm trying to solve a similar problem to yours, so I'm somewhat
> interested in this discussion.
[snip clever use of folder-hook w/macro]
> The macro is done as a folder hook because it must run _after_ the
> folder-hook that sets $my_folder, and it must set the macro to a
> string that has the value of $my_folder in it. You'll notice that the
> macro does _not_ mention $my_folder:
[snip help text]
Indeed, I've used similar things in the past. I'd never looked into
exactly what sequence mutt processes the rc files, though, which is why
this particular problem had me confused for a bit. Thanks for clearing
it up (at least the confusion part).
So, really the only problem I need to solve to make everything work
without having to patch mutt is expanding a my_* variable (perhaps any
variable?) within backticks. As I have time I'm code-diving through the
sections of init.c dealing with backticks to gain a better understanding
of what happens, and hopefully I'll figure out what I need to do to get
variable expansion within backticks (or find out it is not possible).
Of course, regexp substitution within muttrc would be wonderful, but
isn't showing up any time soon. ;)
So, suggestions anyone?
Regards,
--
dave [ please don't CC me ]
