* Add "format_raw_length" global configuration option to allow the user to
toggle between human-readable (default) or raw formatting of track durations.
* Modify library.Item in order to have length formatted as H:MM instead of the
raw number of seconds by using a types.Float subclass (DurationType).
* Add library.DurationType, with custom format() and parse() methods that
handle the conversion.
* Add dbcore.query.DurationQuery as a NumericQuery subclass that _convert()s
the ranges specified by the user to floats, delegating the rest of the
functionality in the parent NumericQuery class.
* Add ui.raw_seconds_short() as the reverse of human_seconds_short(). This
function uses a regular expression in order to allow any number of minutes, and
always required SS to have two digits.
* Make emitters produce a pair (dict, Item), in order to preserve the output
at print_data (dict is used if no custom format is specified, Item otherwise).
* Simplify the handling of the paths, printed at the top of print_data. The
path key is removed from the dict entirely and fetched from the Item.
* Add custom output formatting via a format string to InfoPlugin. The command
accepts a formatting string via the "-f" parameter, which is handled by its
CommonOptionsParser and applied during print_data().
* Modify the emitters in order to include an Item into the list of fields, that
is formatted according to the format string if specified.
* Add an argument to allow the user to choose if track lengths are displayed as
raw floats or using a human-readable form (mm:ss), defaulting to human-readable
form.
Should fix#1433. The problem now was that we were freeing the string memory
that Python expected to be managing in a string object held by the `uri`
variable. Now, we do a silly dance to copy the memory out of the buffer
returned by the library and return that instead.
- Use a marginally more realistic example in the changelog.
- The -- convention is actually not the purview of shells; it's just a de
facto standard for command-line parsers. Fortunately, argparse supports it
out of the box.
* Add changelog and query.rst documentation entries for the usage of negated
queries.
* Cleanup NotQuery class as suggested during code review (PEP conforming
docstring, clarification on empty clause match behaviour).
* Revise the NotQuery syntax, replacing the '¬' character with '^'. Fix tests
to conform to this change, and cleanup the PARSE_QUERY_PART_REGEX.
* Modify parse_query_part() docstring to mention the negate parameter on the
returned tuple, and added an example.
* Add tests to NotQueryTest for testing the results of using queries with
negation.
* Fix issue on test_dbcore due to the modifications on the tuple returned by
parse_query_part (the number of elements was changed from 3 to 4).
* Update the negation query sintax so that the negation prefix ("-" or "¬") is
always the first part of a query, instead of after the ":" separator.
* Modify queryparse, so that the detection of the negation is done inside
parse_query_part() (using the modified PARSE_QUERY_PART_REGEX, and returning
the negation flag) instead of construct_query_part.
* Revert the prefixes dict on beets.library to the original dict (only one item,
with the RegexpQuery prefix).
* Modify NotQuery so it subclasses Query instead of MutableCollectionQuery.
* Update instances where NotQuery objects are created on tests and queryparse,
as NotQuery expects a single Query as a parameter to the constructor instead of
a list of Queries.
* Add support for user friendly "not" operator in queries without requiring to
use regular expressions, via adding NotQuery to beets.dbcore.query.
* Update the prefix list at library.parse_query_parts() and the query parsing
mechanisms in order to create a NotQuery when the prefix is found.
* Add two TestCases, NotQueryMatchTest as the negated version of MatchTest, and
the more generic NotQueryTest for testing the integration of the NotQuery with
the rest of the existing Query subclasses.
