Re: Patch for "tag-prefix and macros" bug
* Lionel Elie Mamane <lionel@xxxxxxxxx> [2004-02-02 07:56 +0100]:
> On Mon, Feb 02, 2004 at 03:08:27AM +0100, Nicolas Rachinsky wrote:
> > Ok, <tag-prefix-cond> _is_ working correctly. Just don't put any
> > <end-cond> there, and all executing macros are aborted.
>
> Oh yes, that's an idea: We keep <tag-prefix-cond>, but ditch
> <end-cond>. Yes, this would be safe, I believe.
I know there are some people using <tag-prefix-cond> (e.g. me, but I'm
not the only one). I don't know if anybody is actually using
<end-cond>, at least it wouldn't bother me if it's removed.
> What would you think about renaming it to <if-tagged> (or similar),
> and that it would have only the effect of aborting the macro if no
> message is tagged. The effect of <tag-prefix-cond> can then be reached
> by <if-tagged><tag-prefix-begin>.
Hm, that doesn't sound too bad. In fact, it sounds quite good.
> >> ######## DO NOT RUN THIS EXAMPLE ON A MAILBOX WITH REAL MAIL ########
> >> macro index \047 "D.\n$y" "delete all"
> >> macro index <F2> "<tag-prefix-cond><pipe-entry>echo
> >> '<end-cond>'\n<pipe-entry>echo foo\n" "Silly test of <end-cond>"
> > OK, I want to have a macro to copy a mail to /tmp/<End>, a perfectly
> > legal use (but not that sensible, of course). 'macro index
> > . "C/tmp/<End>\n"' seems the obvious solution, but try it
>
> Indeed, it doesn't work. Note that
>
> macro index . "C/tmp/<pipe-entry>\n"
>
> works as expected, though. I would have to look at the code to explain
> this in detail.
I noticed that, too, while constructing the demo macro. But I'm a bit
short of time at the moment, so I can't look in the code.
BTW: 'macro index . "C/tmp/<end-cond>\n"' works, too. Are you sure
your demo macro works as described? I have tried it, and it does not
sync the mailbox (but delete the message inside. really strange).
> > (it should be more harmless). If you have a solution to code a macro
> > to save mails to /tmp/<End>, then it should work for <end-cond>,
> > too.
>
> Hmm... I don't think so. The problem is different. My guess is that
> for <End>, the string <End> gets converted to the end key very soon in
> the parsing. For <end-cond>, the problem is seeing the
> function/argument structure of the macro.
IIRC all <foo> constructs are converted at the same time, but I'm not
very sure.
> >> Press F2 when no message is tagged, and whoups! No mail any
> >> more. What it should do, what the user expects, is that it does
> >> _nothing_, that the whole rest of the macro is "eaten". The string
> >> "<end-cond>" there is an argument to echo in the pipe-entry.
>
> > I don't think that mutt has the concept of an argument to a function
> > in macros.
>
> Yes, yes, that's the root of the problem. But that's how someone
> writing a macro thinks about it.
But then you have to fix the macro writers, or, since you can't do
this directly, the documentation.
> > That would be really much work.
>
> <grin>
What about my (deleted by you) proposal? <foo> to execute the command
foo, and e.g. <<foo> to get <foo>?
Nicolas