[Marc Mutz]:
Come on. I thought we agreed that writing to system variables is a
bad idea...
I don't agree that ${year} is a system variable.
> I think an explicit action to set them is easier to handle
> than a multitude of variables which can change as side-effects.
But they _do_ change as side effects. You can't go and pretend
they don't.
I wouldn't say it's a side effect, SETDATE is quite explicit. nothing
else will change the variables.
> we've already seen that this is a tricky issue with the match
> back references. there the gain for easy access seems great
> enough to be worth it. SETDATE can be seen as a macro for
>
> SET "hour" "${_internal_startup_hour}";
> SET "minute" "${_internal_startup_minute}";
> SET "second" "${_internal_startup_second}";
> ...
>
> pretty straightforward to analyse, IMO.
So what should ${_internal_startup_hour} be other than a system
variable?
${_internal_startup_hour} doesn't exist...
> what actions can influence ${_imapflags}? how will its value
> change?
${#imapflags} is (if resolved) a space-separated list of imap
flags. The order of flags in ${#imapflags} is undefined (it's
conceptually a set).
so
if string :matches "${#imapflags}" "*\\Answered*\\Flagged*" {
...
}
may or may not match even if both flags are set. (easily fixed, just
specify lexical sorting of the "set" at all times.)
addflag
- adds the flags given as arg to #imapflags then
- removes all duplicates.
removeflag
- removes all flags given as arg from #imapflags
wouldn't it be better to make generic functions for this?
addflag "flag" "\\Flagged";
changes ${flag}. you'd now use
keep :flags "${flag}";
rather than
keep :globalflags;
and
keep :flags "${flag} \\Flagged";
instead of
keep :globalflags_plus "\\Flagged";
some scripts may become more verbose, but the complexity of the
IMAPFLAGS is decreased, IMO. (ADDFLAG and REMOVEFLAG could move to a
separate extension.)
setflag
- clears #imapflags
- executes addflag <args>
what would SETFLAG "${#imapflags}" do? just one of those things which
need to be clarified.
mark
- equivalent to addflag "\\Flagged"
unmark
- equivalent to removeflag "\\Flagged"
what is the rationale for MARK and UNMARK? according to the draft
these actions are _not_ equivalent to ADDFLAG "\\Flagged".
Summary:
There are two issues, let's separate them:
1. Should set be allowed to act on system variables?
I hope to have made it clear that that's a bad idea.
I strongly agree!
2. Should system variables be prefixed?
Well, why _not_? If it makes set's job easier to determine if
something is read-only or not? If it makes system variable
references more explicit?
I don't want to introduce system variables at all. I haven't seen a
compelling case for adding them.
--
Kjetil T.