don't parse fields starting with '
this disables the ability to directly apply […] to '…' literals,
but that's not really useful anyway and can still be done with _lit
'O' would get the *current* local UTC offset and apply it to all
'datetime' objects it gets applied to.
This would result in a wrong offset if the current offset includes
DST and the target 'datetime' does not or vice-versa.
'O' now determines the correct local UTC offset while respecting DST for
each individual 'datetime'.
this allows using a slice operator alongside other (special) format
specifiers like J, to first join list elements to a string and then
trimming that with a slice.
{tags:J, /[:50]}
- either {_lit[foo]} or {'foo'}
- useful as alternative for empty metadata fields: {title|'no title'}
- due to using '_string.formatter_field_name_split()' to parse format
strings, using certain characters will result in an error: [].:!
To be able to parse any string into a 'datetime' object
and format it as necessary.
Example:
{created_at:D%Y-%m-%dT%H:%M:%S%z}
->
"2010-01-01 00:00:00"
{created_at:D%Y-%m-%dT%H:%M:%S%z/%b %d %Y %I:%M %p}
->
"Jan 01 2010 12:00 AM"
with 'created_at' == "2010-01-01T01:00:00+0100"
Starting a format string with '\f<Type> ' allows to set a different
format string type than the default. Available ones are
- T: A template file containing the actual format string
"\fT ~/.templates/booru.txt
- E: An arbitrary Python expression
"\fE title.upper().replace(' ', '-')"
- M: Name of a Python module followed by a function name inside it.
This function gets called with the current metadata dict as
argument and should return a string.
"\fM my_module:generate_text"
'\f' was chosen since it is highly unlikely that a regular format string
would start with it, but that character could be changed to for example
'\\' or '/' etc.
Mike Fährmann