Parameterize the IMAP folder path

[kurahaupo]

(This follows on from implementing multi-SIM.)

Allow tokens to be included in the Gmail label/IMAP folder, such as:

• %{device_name} this phone's name
• %{slot} the SIM slot number in this phone.
• %{slot_id} the IMEI of (the SIM slot in) this phone
• %{sim_id} the SIM's serial number (ICCID or IMSI)
• %{sim_phone} the SIM's phone number (MSISDN)
• %{phone} the other party's phone number (MSISDN or E.123 format if possible)
• %{name} name of the other party (from Google Contacts; same as used for the subject line now)
• %{kind} (a token such as SMS, MMS, RCS)

[kurahaupo]

The %{slot} notation could be expanded to allow %{slot+char} where char is any printable unicode character, indicating the first slot. The default would be +1 giving 1/2/3.

Other possibilities include:

• 0/1/2
• A/B/C
• ₁/₂/₃
• ❶/❷/❸
• Ⅰ/Ⅱ/Ⅲ.
• α/β/γ

[kurahaupo]

It may then also make sense to use these same tokens for configuring the RFC2822 headers in the saved messages, rather than having specialized code in each case.

To that end, it may also be useful to recognize

• %{time}, %{senttime}, %{recvtime}, %{now}, etc, with optional modifiers:
  • %{time±timezone}, where ±timezone is either
  • a numeric offset (+hh, -hh, +hhmm or -hhmm), or
  • + and a known timezone label to convert from UTC to that timezone, or
  • - and a known timezone label to convert from that timezone to UTC; multiple offsets can be given, in particular to convert from one timezone, to UTC, to another timezone. Timezone label local refers to the current primary timezone of the device.
  • %{time~format} where format is usable by strftime or similar.
• %{my_email} the email address associated with the IMAP or Gmail account;
• %{my_name} the name associated with the Gmail account;
• %{my_phone} as an alias for (or replacement of) %{sim_phone} (above);

[kurahaupo]

I have in mind a generic parsing mechanism that would work through a string and pick out each token of the form %{…}, then from that take the first "C" identifier (matching /\<[[:alpha:]_][[:alnum:]]*\>/) and look that up to determine the precise function. The result from that function would replace the token in the initial string.

Modifiers could be introduced by any sensible punctuation, such as

• parameters and type-specific modifiers:
  • +char after a numeric value such as slot
  • +number or -number after a numeric or time value
  • ~format as per strftime or sprintf
• generic modifiers, as :modifier-function
  • :uc convert to uppercase
  • :lc convert to lowercase
  • :tc convert to titlecase
  • :lookup{value1|value2|value3|…}

Any number of generic modifiers may be given after any specific ones, as they apply to whatever result is returned by the lookup and previous modifiers.

NB: this implies that the matching of %{ to } must take nested brackets into account.

[kurahaupo]

If anyone has any preferences for the start and end symbols, please say so now...