<<< Date Index >>>     <<< Thread Index >>>

Re: Patch for "tag-prefix and macros" bug



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