Since market price amounts didn't contribute to the canonical commodity
styles, they were being reset to the null style. And this propagated to
the reported amounts when -V was in effect, causing much confusion.
Now, market prices contribute to canonicalisation and the expected
styles are preserved even with -V.
cf https://github.com/simonmichael/hledger/issues/131#issuecomment-133545140
print now always right-aligns the amounts in an entry, even when they
are wider than 12 characters.
If there is a price, it's considered part of the amount for
right-alignment. Maybe it would be nicer to put amounts and prices in
separate columns ? That will get a little complicated, needs more
discussion/design.
Also some cleanup of postingAsLines.
The print command wasn't lining up amounts with wide chars in account
names, fixed it properly this time. Transaction and Posting's Show instances
should also be wide-char-aware now.
Wide characters, eg chinese/japanese/korean characters, are typically
rendered wider than latin characters. In some applications (eg gnome
terminal or osx terminal) and fonts (eg monaco) they are exactly double
width. This is a start at making hledger aware of this. A register
report containing wide characters (in descriptions, account names, or
commodity symbols) should now align its columns correctly, when viewed
with a suitable font and application.
The balance command's --format option (in single-column mode) can now
adjust the rendering of multi-line strings, such as amounts with multiple
commodities. To control this, begin the format string with one of:
%_ - renders on multiple lines, bottom-aligned (the default)
%^ - renders on multiple lines, top-aligned
%, - render on one line, comma-separated
Also the final total (and the line above it) now adapt themselves to a
custom format.
Using "hledgerdev" was a hack to help ensure that tests used a fresh
developer build by default. Now they specify "hledger" again, which fits
better with stack. It's up to the tester to make sure the desired
executable is first in PATH or specified with -w. (Note a couple of
tests currently don't obey -w and will always run "hledger", see addons.test).
When a transaction posts to two commodities without specifying the
conversion price, we generate a price which makes it balance
(cf http://hledger.org/manual.html#prices).
Until now, these generated prices were always shown with full precision
(all available decimal digits) so that a manual calculation with the
displayed numbers would agree.
If there's just one posting in the commodity being priced, we can use an
exact total price and the precision is no problem.
But if there are multiple postings in the commodity being priced, we
must show the averaged unit price. This can be an irrational number,
which with our current Decimal-based implementation would display an
excessive 255 decimal digits. So in this case we now set the price's
display precision to the sum of the (max) display precisions of the
commodities involved. An example:
hledgerdev -f- print
<<<
1/1
c C 10.00
c C 11.00
d D -320.00
>>>
2015/01/01
c C 10.00 @ D 15.2381
c C 11.00 @ D 15.2381
d D -320.00
>>>=0
There might still be cases where this will show more price decimal
places than necessary. For now, YAGNI.
The regex account aliases added in 0.24 trip up people switching between
hledger and Ledger. (Also they are currently slow).
This change makes the old non-regex aliases the default; they are
unsurprising, useful, and pretty close in functionality to Ledger's.
The new regex aliases are also available; they must be enclosed in
forward slashes. Ledger effectively ignores these, which is ok.
Also clarify docs, refactor, and use the same parser for alias
directives and alias options
alias match patterns (the part left of the =) are now case-insensitive
regular expressions matching anywhere in the account name. The
replacement string (the part right of the =) can replace multiple
matches within the account name. The replacement string does not yet
support any of the usual syntax like backreferences.
Previously, a depth:0 query produced an empty report (since there are no
level zero accounts). Now, it aggregates all data into one summary item
with account name "...".
This makes it easier to see the kind of data Gwern was looking for from
register-csv (net worth over time). Eg this shows one line per month
summarising the total of assets and liabilities:
hledger register-csv -- -MHE ^assets ^liabilities depth:0
Single and multi-column balance reports behave similarly.
In periodic multicolumn balance reports, column headings now show a more
compact description of common periods (years, half-years, quarters,
months, weeks) for better readability and screen space efficiency.
This is a workaround for a cmdargs limitation. Having "--debug 2"
or "--width 100" produce no output (because the number is parsed
as a separate argument) is too annoying.
Amount display styles have been reworked a bit; they are now calculated
after journal parsing, not during it. This allows the fix for #196:
we now search through the amounts until a decimal point is detected,
instead of just looking at the first one; likewise for digit groups.
Digit groups are now implemented with a better type.
Digit group size detection has been improved a little:
1000,000 now gives group sizes [3,4,4,...], not [3,3,...], and
10,000 gives groups sizes [3,3,...] not [3,2,2,..].
(To get [3,2,2,...] you'd use eg 00,00,000.)
There are still some old (or new ?) issues; I don't think we handle
inconsistent decimal points & digit groups too well. But for now all
tests pass.
This change means you can make assertions on a multi-commodity account
balance (asserting one commodity at a time). On the flip side, you can
no longer assert the complete balance of an account (new unexpected
commodities will not be detected.) We might restore that ability later,
using the == syntax.
As with balance. For example, register -p 'weekly in jan' generates
these intervals: 2013/12/30-2014/01/05, 2014/01/06-2014/01/12,
2014/01/13-2014/01/19, 2014/01/20-2014/01/26, 2014/01/27-2014/02/02.
With this change, postings on 2013/12/30-31 and 2014/2/1-2 will be
included in the report, so all period totals are complete and
comparable.
