[Remind-Fans] Avoid type errors when using trigdatetime in msgprefix

[Dianne Skoll]

n 2020-03-31 16:34, Juan F. Meleiro wrote:

> That was just an update. The real issue is the following: I use the
> function msgprefix() as a way to add indentation and markers to
> reminders. It adds three spaces of indentation, the middle of which
> is substituted by '*' or '>' if the event is happening *now* or
> later today. So it may show something like:

>       12:00 Lunch
>     * 16:00 That class you should be attending
>     > 18:00 That thing you'll do later

> The problem is that doing that involves calling the function
> trigdatetime() for every reminder, and making a comparison to a
> DATETIME. That causes an error if the reminders does not have an
> AT-part, and so the whole functions evaluates to nothing (I
> should've read the man-page with more attention).

Hmm, this is tricky.  Unfortunately, Remind does not have
short-circuit logical operators, so you can't avoid evaluation of the
problematic comparison.  I can't see an easy way around this.

> Is there a way to accomplish this? Alternatively, is there another function to
> add prefixes that I won't be missusing? Finally, if nothing else is possible,
> would it be too hard to fix it myself with a patch?

I can't think of a way around it... but what sort of patch do you have
in mind?  I have a couple of thoughts:

1) For a timed reminder, if msgprefix_timed / msgsuffix_timed exist, call
those instead of msgprefix / msgsuffix (but fall back on the old functions
if the _timed variants don't exist, for backward-compatibility.)

2) Add an argument to trigdatetime() that makes it *always* return a DATETIME
object, setting the time component to 00:00 if there was no AT clause.

3) Adding short-circuit logical operators to Remind's expression evaluator.
If you have read expr.c, you'll know that (a) it was written before I knew
what the heck I was doing, and (b) short-circuit operators can't happen
without a major rewrite. :)

I think either (1) or (2) would be OK; I have no strong preference.

Regards,

Dianne.