On Mon, Feb 02, 2004 at 03:08:27AM +0100, Nicolas Rachinsky wrote: > * 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). The difference is that <tag-prefix> doesn't have a corresponding end-marker. > IMVHO should this be handled by your patch in the same way as > <tag-prefix>. That's what I tried to do at first. But when I realised that there was no way to sanely skip until <end-cond> marker with the current mutt parser, I abandoned. >>> 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. Oh yes, that's an idea: We keep <tag-prefix-cond>, but ditch <end-cond>. Yes, this would be safe, I believe. 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>. >> 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. Yes, the mutt parser / pure keyboard macro concept is the root of the problem. >> ######## 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. > (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. >> 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. >> 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>. Yes, sure. But this thing is particularly nasty with its current behaviour. >> 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. <grin> -- Lionel
Attachment:
signature.asc
Description: Digital signature