[Remind-Fans] Every Thursday except...

[Dianne Skoll]

On 2020-09-19 17:46, Ed Blackman wrote:

> On Sat, Sep 19, 2020 at 12:46:18PM -0500, Tim Chase wrote:

>> On 2020-09-18 17:10, Ed Blackman wrote:

>>> I also want to send myself a reminder the previous Friday when
>>> there's an event on one of those Thursdays.  That was trickier, but
>>> this is what I came up with:

>> you might be able to set a variable to the most recent trigdate() and
>> then do some math on it to create the other event.  Something like

>>   OMIT Nov 26 2020 # Thanksgiving
>>   REM Thu SKIP SATISFY [$Td < 3 || $Td > 9] MSG Thursday thing
>>   IF trigvalid()
>>     SET meeting $T
>>     REM [meeting-6] RUN send_email -s "Send mail for [meeting]"
>>   ENDIF

Generally speeking, doing arithmetic based on one trigger date to
calculate another trigger date is fraught with peril because of how
the Remind algorithm works.  I would do all the arithmetic in the
SATISFY clause as in:

OMIT 26 Nov 2020
REM Thu SKIP SATISFY [$Td<3 || $Td > 9] MSG Thursday thing
SET meeting $T
REM Fri SATISFY [(day($T+6)<3 || day($T+6)>9) && !isomitted($T+6)] MSG Mail for
[meeting]

> One last question: what is the scope of variables in remind?

Most variables have global scope.  The only exceptions are function
arguments; in:

FSET square(x) x*x

the scope of the variable x is the function body.

Most variables have one-day lifetimes; this only matters in calendar
mode or if you use '*N' on the command line.  However if you PRESERVE
a variable, its lifetime is the lifetime of the Remind process.

> Is that correct?  A quick test shows that "meeting" is still set outside
> the IF block if I don't UNSET it, so it's not block scope, but I haven't
> used variables before so there might be some complexity I'm missing, or
> just no scopes/only global scope.

There's no need to UNSET the variable afterwards.  It doesn't
hurt to let it live on.

Regards,

Dianne.