When reports want to render amounts without commmodity symbols,
they must now use AmountDisplayOpts' new displayCommodity flag.
(Previously it was a side effect of setting displayCommodityOrder.)
This and the preceding commits were "work in progress" that got out of control.
There's more to do, but this one brings these precision-related improvements
(at least):
When "infinite decimals" arise, they are now generally shown with
8 decimal digits rather than 255.
print and prices no longer add trailing decimal zeros unnecessarily.
Some code has been refactored or given more debug output.
All tests have been updated to match the recent changes.
Changes to enable more control of "rounding" behaviour
(ie, choosing display precisions for amounts).
This reverts 1.31's change of asprecision, making it a non-Maybe
again, and adds a new asrounding field providing more control over how
a target display precision is applied to existing amounts (two options
for now, more later). Functionality is in an interim state (reports do
no rounding).
Add a flag --summary-only for multi-column balance reports, which does
not display the main date columns for a report, but only displays the
summary columns (--row-total, --average). This is useful when there are
many columns (a weekly summary over many years) where you're only
interested in the average (or some other summary).
This simplifies the code for styling amounts with or without precision.
But it complicates the semantics (Nothing is useful only when setting style).
Not sure if it's the best way.
This can be useful to override defaults in scripts.
These flags will now toggle when repeated on the command line:
--invert
--transpose
-r/--related
-%/--percent
-E/--empty
-N/--no-total
-T/--row-total
-A/--average
-S/--sort-amount
Boolean queries are now prefixed with an 'expr:' prefix, making them
completely separable from old queries and making the addition of them a
little more migration proof.
The tests are updated accordingly, changes made to the tests previously
are removed and extra cautious documentation is also removed.
This commit changes some of the functions in the Query module and
changes the overall way to parse queries. Instead of using the words''
split function, this commit starts to fully parse the query, as it's
seen as a type of expression.
AND, OR, NOT, and space operators can be used. The space operator
simulates the behaviour from before, leaving a minimal amount of tests
that need to be adjusted to comply to the new behaviour.
Eg, where previously -p 'monthly from 1/15' or -M -b 1/15 would always
adjust the report start date to 1/1,
unless you used the special -p 'every 15th day of month from 1/15' form,
now the start date will not be adjusted. (It is still adjusted if
the report date is not specified explicitly, eg inferred from the journal).
This keeps behaviour consistent between report periods and periodic transactions.
'in' period expressions, like 'in 2023-01', are a grey area; they
do specify a start date (2023-01-01), although they look a bit implicit.
So previously, -p 'weekly in 2023-01' would adjust the start date to
the preceding monday (2022-12-26), but now it will start exactly on
2023-01-01 (a sunday, which also causes ugly verbose column headings).
To ensure monday based weeks and simple report headings here,
you would have to explicitly specific a start date that is a monday,
eg -p 'weekly from 2022-12-26 to 2023-02'.
This replaces the old journal*AccountQuery with the new Type query. This
enables uniform treatment of account type, and fixes a subtle bug
(#1921).
Note that cbcsubreportquery no longer takes Journal as an argument.
This results in big speedups in cases when we have many transaction prices, like in examples/10000x1000x10.journal. This can be disabled with the show_costs_ option in ReportOpts.
This requires checking parent accounts for any new accounts introduced by auto postings which do not exist in the original journal.
Also refactor journalFinalise to only call journalPostingsAddAccountTags once, and use fewer intermediate variables.
type:TYPES, where TYPES is any of the (case insensitive) letters
ALERXCV, matches accounts by their declared or inferred type.
(See https://hledger.org/hledger.html#account-types.)
This should work with most commands, eg:
hledger bal type:al
hledger reg type:x
API changes:
Journal has a new jaccounttypes map.
The journalAccountType lookup function makes it easy to check an account's type.
The journalTags and journalInheritedTags functions look up an account's tags.
Functions like journalFilterPostings and journalFilterTransactions,
and new matching functions matchesAccountExtra, matchesPostingExtra
and matchesTransactionExtra, use these to allow more powerful matching
that is aware of account types and tags.
Accounts, postings, and transactions can now all be filtered by the
tags in an account's declaration. In particular it's now possible to
more reliably select accounts by type, using their type: tag rather
than their name:
account myasset ; type:Asset
account myliability ; type:Liability
$ hledger accounts tag:type=^a
myasset
Accounts inherit tags from their parents.
API changes:
A finalised Journal has a new jdeclaredaccounttags field
for easy lookup of account tags.
Query.matchesTaggedAccount is a tag-aware version of matchesAccount.
