Like we used to in 1.30, but better (show all available decimal digits,
unless they're infinite in which case show 8, show trailing zeros,
show commodity symbol with zero).
Note the headErr/tailErr calls will print stack traces if they fail
(small ones: five lines, one of which is the useful location info),
which may or may not be best UX.
The code is a bit clearer, and it no longer discards amounts other
than the first when the running balance contains multiple costs.
(This bug was exposed by the fix for #2039).
Rationale:
To satisfy the recentassertions check I'm often filling in a bunch of
placeholder balance assertions, copy/pasting the correct amount from
the balance assertion failure messages. In this situation the
difference just repeats the amount in the line above, with opposite
sign, which makes it harder for me to interpret the message and to
copy-paste the right amount. And more generally I think showing the
difference isn't really necessary.
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.
Cost/value conversion now applies the standard display style, and
sets the display precision equal to the internal decimal precision
(or 8 if the decimal appears to be infinite).
This means value reports and especially `print -V` now show amounts
with more accurate and standard style and precision.
New tests have been added describing and explaining various
style/precision behaviours in print cost/value reports.
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).
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.
Transaction balancing is supposed to balance costs, but these were
being stripped when calculating balance assignments, causing us to
wrongly reject this transaction when the last amount is left implicit,
unlike Ledger:
2023-01-01
Assets AAA -1.1 @@ CCC 2
Assets BBB -1.2 @@ CCC 3
Expenses:Fees CCC 0.2
Assets = CCC 4.9
I'm not sure why costs were being stripped. I seem to have added it
in 2019 (to Journal.balanceNoAssignmentTransactionB in 3b47b58ae),
but this bug seems to be present even before that.
transaction prices.
When given --infer-costs, hledger will now separately infer transaction
prices for different prices. Given a pair of adjacent conversion
postings, hledger will check if there is a single posting with a
transaction price which matches both the amounts. If so, it associates
those conversion postings to that priced post.
If it can't find any transaction price postings which match, it will
find the first non-transaction price post which matches one of the two
amounts, and will add a transaction price to that, and associate them.
