[Remind-Fans] Improvements to json output

[Dianne Skoll]

On Fri, 5 Aug 2022 08:58:33 +0200
Jochen Sprickerhof via Remind-fans <remind-fans at lists.skoll.ca> wrote:

> # Remove color and time information from "body"

Hmmm I can do that, but I'd prefer to add a new key with the stripped
information.  Otherwise, it will break backward compatibility with
existing back-ends.

[...]

> The color information in the "body" ("255 1 1") is already in r, g
> and b and should not be part of the displayed message. Obviously we
> don't want to show the rawbody either.
> Same for the "1:00am-3:00am", which is already available in time and 
> duration.
> Also duration and eventduration and date and eventstart seem
> duplicate.

THey can differ for durations longer than one day.

> # Provide calendar and non calendar message in separate keys

> Some time ago you added -pppq to get the full message instead of the 
> calendar version:

> $ echo 'REM MSG %"calendar%" additional text' | remind -pppq -
> [..]
>        {
>          "date": "2022-08-31",
>          "filename": "-",
>          "lineno": 1,
>          "priority": 5000,
>          "body": "%\"calendar%\" additional text"
>        }

> It would be great if Remind would provide both parts in separated
> keys, say: {"summary": "calendar", "description": "additional text"},
> so consuming tools would not need to know about the Remind format.

OK, I'll look into that; it seems reasonable.

> # "d", "m" and "y" stay at event start

That's as designed.  d, m, and y are *NOT* the trigger date.  They
are the actual day, month and year components of the trigger.  This is so
TkRemind can edit reminders properly; it needs to know the original day,
month and year components of the reminder.

For the trigger date, you should *NEVER* look at d, m and y; you should
*ALWAYS* look at date.

> Last, there is a lot of boilerplate in the json where I'm not sure if
> it is useful:

That boilerplate is for localization; it lets back-ends know the day and
month names without having to be localized themselves.  The daysinmonth
and firstwkday keys are convenience entries so you can draw the calendar
without needing to know on which weekday a given month starts.

For example, if you're running Remind 04.00.02 and you put this at the
beginning of your reminder file:

    INCLUDE [$SysInclude]/lang/auto.rem

then Remind will use your locale settings to pick a language, if it
supports that language, and back-ends like TkRemind, rem2pdf and rem2html
will automatically localize month and day names as well.

> I guess that it makes some tools (tkremind?) easier but I don't think
> it should be part of the generic output as it can be computed in the
> tool.

The day names, etc. can't easily be computed by the back-ends unless they
are localized, and since Remind already knows all the localized names,
it might as well communicate them to the back-end.

> Just to repeat, I have no problem with working around all this so
> this is rather a wishlist and ideas collection.

To recap: I agree with adding a new key for the body without the color
components and time, and also new keys for the "calendar_body" and
"plain_body" or something, like this:

    "body": "255 255 0 1:00am-3:00am %\"calendar%\" additional text",
    "calendar_body": "calendar",
    "plain_body": "calendar additional text",

Does that seem reasonable?

Regards,

Dianne.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://dianne.skoll.ca/pipermail/remind-fans/attachments/20220805/48d66821/attachment.sig>