Randall Gellens wrote:
All actions described in this specification (setflag, addflag,
removeflag,
mark, unmark) operate on an internal variable that contains the set of
[IMAP] flags
associated with the message being delivered. When the interpreter starts
executing
a script this variable contains an empty set. The 'addflag' action adds
flags
to the existing set. The 'removeflag' action removes flags from the
existing
set.
The 'setflag' action replaces the existing set of flags with a new set.
Whenever the interpreter encounters a 'fileinto' or 'keep' action it
files
the message with the current set of flags.
I'm not comfortable with the specification of an internal variable.
I'd prefer that the draft stick to the semantics of the operations. As I
see it, the actions added by this extension modify IMAP flags on the
message being processed. If the message is eventually kept or filed, the
flags go with it. If the message is deleted, the flags are meaningless.
'setflags' undoes any previous flag actions and causes the specified flags
to be set.
'addflag' sets the specified flags.
'removeflag' cancels the specified flags from being set.
So you like the idea, but you don't like the wording (more precisely the
explanation).
Also, I think the descriptions of 'mark' and 'unmark' are unclear. They
should specify exactly what is to happen, and not have so many MAY do this
or that statements.
Barry originally said that draft is too tied to IMAP. mark/unmark allows to
specify
importance of the message without enforcing the way how it is implemented.
I like the idea of setting flags independently of 'fileinto' or
'keep'. I'd really much rather not have 'fileinto'/'keep' be a way of
setting flags.
As I've heard voices from both sides (from people who want to use separate
commands
or to use tagged arguments) I can't make judgment which way is preferred.
I will have both in next draft and hopefully I will hear more comments.
I think the wording on 'reject' is too strong. What's wrong with making it
a no-op to set flags on a message which is then rejected or discarded? A
script editor can always warn "this has no effect" to the user, but that's
its business.
Sure. I can relax wording.
Alexey