On Mon, Feb 02, 2004 at 12:27:14AM +0100, Nicolas Rachinsky wrote: > * Lionel Elie Mamane <lionel@xxxxxxxxx> [2004-02-01 23:32 +0100]: >> By reading the code, I found out about <tag-prefix-cond> and >> <end-cond>. These don't seem to be documented anywhere (except the >> ChangeLog). > http://www.rachinsky.de/nicolas/mutt.html I meant "in the mutt tarball", obviously. :) I hadn't noticed that the code is new code, though: 1.5.5! >> 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. > 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. In fact, I think quite the contrary: My first reaction was "Wow, mutt will never cease to amaze me; it is even more powerful than I thought". The problem is that <end-cond> doesn't work as it should. For example (\047 is the code of '): ######## 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>" 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. 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'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. -- Lionel
Attachment:
signature.asc
Description: Digital signature