Also, I am strongly in favor of showing empty flags as [], not as NIL or
"". NIL is syntactically an identifier, and requires a grammar change;
"" is not a valid IMAP flag, but it looks like a string. I really hate
:flags "".
"Nigel Swinson" <Nigel(_at_)Swinson(_dot_)com> writes:
If they are I'd go for:
keep :globalflags :plus [...]
keep :globalflags :minus [...]
Which might even be better than :globalflags+ and definately
better than :globalflags_plus.
In this case it is better to have ":globalflags plus [...]" or
":globalflags minus [...]" (no colon in front of plus/minus),
because it is confusing (tagged argument that requires another
argument, hrrrrr ).
Ah yeah, it does say in the SIEVE spec:
- To simplify this specification, tagged arguments SHOULD NOT take
- tagged arguments as arguments.
Ok so the tagged optional argument "globalflags" may optionally take 2
arguments where both are positional. The first being "plus" /
"minus", the second being a list of flags. Yeah I'd be happy with
that.
:globalflags minus requires a grammar change. Syntactically, the bare
word "minus" (i.e., no quotes) is an identifier, and cannot occur as a
part of a command.
Personally, I'm opposed to global flags unless the mechanism used to
manipulate them is generic, applies to lists of strings, and the global
list of flags is just a global variable. We're going to have to end up
with variables, they're mostly going to need to be lists of strings, and
we're going to end up duplicating all of the functionality in the flags
document.
We're going to need remove-items and add-items. Because of the way
we'll probably end up adding variables (all string-lists can now be
variables) we're going to end up with all of this functionality
available to the flags extension, and duplicating it. :globalflags_plus
is basically contatination (but the items must be unique);
:globalflags_minus is removal.
How can I temporarily clear the global flags list, or temporarily and
conditionally modify it? Why is there only one global flags list?
I'm in favor of a very abridged flag mechanism: a ":flags" parameter
that takes a string-list as an argument. I'm pretty sure that given
basic list operations that variables will require, plus a likely
$global_flags variable, everything else will follow naturally from that.
(We'd need list contatination, addition, and removal, and we'd need to
make it non-destructive.)
Can someone give me a napkin drawing on how global flags are supposed to
look in a UI? Are we really sure this can't wait until we get some real
programming language features?
I would be glad to do the work to see this through after the base spec
is done.
Why does the global flags list have to be explicitally turned on? Would
leaving it on all the time and doing :noglobalflags be an improvement?
If we must have global flags in this document, leave out
:globalflags_plus, and do it instead with :globalflags :flags. This
violates part of section 4, but that can be easily fixed.
Can someone send an example for :globalflags_minus? I think it should
be left out entirely until we can do variables. If we have to have it,
we could call it :globalflagsexcept.
Also, the example
addflag "foo";
fileinto :flags "foo" :globalflags_minus "foo";
MUST store the flag "foo". (Explit "foo" stores the flag,
:globalflags_minus "foo" temporarily clears it from the globals list but
the explicit mention wins).
I like mark and unmark in principle, but because this is an IMAP-only
document, they should be dropped. How to do mark and unmark with IMAP
is basically well-known (:flags "\\Flagged"), and should be left for
some future "general" flags extension, if necessary. If \Flagged isn't
the right way to flag messages, then it's probably a client issue, and
the server probably doesn't know how to do it, either.
Tim