Re: Patch for "tag-prefix and macros" bug
* Lionel Elie Mamane <lionel@xxxxxxxxx> [2004-02-02 01:20 +0100]:
> On Mon, Feb 02, 2004 at 12:27:14AM +0100, Nicolas Rachinsky wrote:
> > * Lionel Elie Mamane <lionel@xxxxxxxxx> [2004-02-01 23:32 +0100]:
> >> The behaviour wasn't consistent: In
> >> "<tag-prefix-cond>ab<end-cond>c", if there are messages tagged,
> >> only a operates on them and b and c operate on the current message,
> >> but this sequence is equivalent to "c" when there are no messages
> >> tagged.
>
> > That's the intended behaviour. Why is this inconsistent?
>
> Because the part that is skipped (if nothing is tagged) is not equal
> to the part that operates on the tagged messages.
That's exactly the same way as with <tag-prefix>, it's neither
better nor worse (and equally inconsistent). IMVHO should this be
handled by your patch in the same way as <tag-prefix>.
> > The functionality is useful, since without it, you can't do many
> > things.
>
> I didn't say that such a functionality, if correctly working, is not
> useful.
Ok, <tag-prefix-cond> _is_ working correctly. Just don't put any
<end-cond> there, and all executing macros are aborted.
> The problem is that <end-cond> doesn't work as it should. For example
> (\047 is the code of '):
I must admit, I've never used it (except to test it). And I think the
problem is not a bug in <end-cond> but in the mutt parser.
> ######## 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
(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.
> 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. And I think, you know that <foo> is converted a long time
before <foo> is executed. So I agree with you, that there is a
problem, but I don't agree that it's <end-cond>'s fault.
> It is *not* the <end-cond>
> command that "finishes" the <tag-prefix-cond>. As it is implemented
> now, it is dangerous and *will* bite the users.
I'm quite sure that it's possible to construct dangerous macros doing
counter-intuitive things in inconsistent ways without using
<end-cond>.
> I'd love to have such a conditional construct, but I don't see how to
> do it in a _safe_ manner in mutt. Except the way I described:
>
> - <tag-prefix-cond> sets a global flag "don't act"
> - <end-cond> (and maybe end-of-macro) unset this flag
> - after an <tag-prefix-cond>, the mutt_menuLoop code (and the other
> one, too) continues unaffected. In this way, the arguments to the
> functions are indeed consumed.
> - Every action function (like e.g. mutt_pipe_message()) is modified
> to not do its action (e.g. pipe the message through its argument)
> when this global flag is set, but to still consume its arguments.
>
> This is quite more work than your approach.
That would be really much work.
I would document to not use <foo> in macros, except you want to
execute <foo> and add a way to quote <foo> to get literal <foo>.
Nicolas