-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday, December 12 at 11:23 AM, quoth Noah Sheppard:
>> Your macro has an additional problem: it wouldn't work even if
>> my_curdir WAS correctly being set! You see, variable expansion is
>> evaluated at the time the macro is established!
> I figured that might be a problem. I switched to the folder-hook
> because I thought that might get reevaluated every time the hook was
> run. Is that true, or do I also need to escape variables in hooks as
> well?
You need to escape variables in hooks as well.
Think of it this way; if you have a shell script that looks like this:
my_curdir="one"
macrocontents="$my_curdir"
echo $macrocontents # aka evaluate the macro
my_curdir="two"
echo $macrocontents # aka evaluate the macro again
Does it make sense in that script that, rather than printing out "one
two", it will instead print out "one one"? This is essentially the
same thing you're doing in mutt. Actually, technically, it's more akin
to this:
my_curdir="one"
macrocontents="$my_curdir"
eval "echo $macrocontents" # aka evaluate the macro
my_curdir="two"
eval "echo $macrocontents" # aka evaluate the macro again
Now, how do you solve this? By escaping the variable:
my_curdir="one"
macrocontents="\$my_curdir" # see the difference?
eval "echo $macrocontents"
my_curdir="two"
eval "echo $macrocontents"
The same principle applies to mutt. When you do this:
set my_archdir=/foo
set my_curdir=/bar
macro index,pager S "<save-message>$my_archdir/$my_curdir<enter>"
...the macro stores the *resolved* string. It stores
"<save-message>/foo//bar<enter>", and that is the string that mutt
uses when it triggers the macro. (Okay, it's *slightly* more complex
than that, but this is accurate enough for this discussion.) Mutt
reinterprets the contents of the macro when it is triggered, but if
the stored string doesn't have unresolved variables in it, then
there's nothing to reinterpret! By escaping the variables, we prevent
them from being resolved when the macro is established. Thus, if we do
this:
set my_archdir=/foo
set my_curdir=/bar
macro index,pager S "<save-message>$my_archdir/\$my_curdir<enter>"
...then the string mutt stores with the macro is
"<save-message>/foo/$my_curdir<enter>".
Does that make sense?
Now the next observation you made is that mutt isn't re-interpret all
variables in the macro. That's absolutely correct - there's nothing
magical about variables in macros. A macro makes mutt behave (with one
exception) exactly as if you'd typed those characters in. And you
can't use variables when you're saving messages. If you try typing in
c$my_curdir
Mutt won't expand the variable.
Honestly, I forgot about that, so I gave you some bad advice at first.
IF you could get $my_curdir to work, you could get your wish by
constantly re-creating the macro. But that gives me an idea - here's
something that should work:
folder-hook . "set my_oldrecord=\$record"
folder-hook . "set record=^"
folder-hook . \
macro index,pager "<save-message>$my_archdir/$record<enter>"
folder-hook . "set record=\$my_oldrecord"
This way, we can use the "special" status of $record to force the ^ to
be expanded. First, we save the contents of $record into a temporary
variable (so we need to escape $record). Then we set $record to ^.
Then we rebind the macro so that it's got the correct contents (note
we don't want escaping here). Then we restore $record's original
value.
Nice, eh? ;)
> In general, how did you learn this stuff about which variables
> expect mailbox paths, which are just regular strings, when macro
> expansion happens, when stuff needs escaping, etc? I did not RT
> entire FM, but I did look through it and didn't find anything very
> helpful.
Experience. :) And the occasional code-dive.
~Kyle
- --
The best way to know God is to love many things.
-- Vincent Van Gogh
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iEYEARECAAYFAklCmGAACgkQBkIOoMqOI153TwCcCVY11Jz8BoxVLS2yMdsA6WGt
sGgAoLq4AaBaOnam/QQmVLjYAJHYLARV
=DJnB
-----END PGP SIGNATURE-----
