There are now six man pages, one for each main executable and file
format, generated from markdown by the mighty pandoc. They are basically
the content of the user manual, split up and moved into the appropriate
package directory. I've also committed the generated man files.
The man pages' markdown source (hledger/hledger.1.md,
hledger-lib/hledger_journal.5.md etc.) are now the master documentation
files. The plan is to concatenate them (with a little munging) to form
the all-in-one user manual for the website, at release time. This also
separates the hledger.org user manual from the latest doc commits, which
should simplify website management.
I really don't see why that extra x parameter is needed or works..
rewrite it in simpler form.
I also might be introducing breakage for older GHC's by using
unconditionally <$>, but I'm not seeing that for some reason
(tested back to ghc 7.6).
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.
Simple (non-multicolumn) balance reports containing wide characters
should now align correctly (in apps and fonts that show wide chars as
double width). Likewise, the print command.
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.
This adds a accountNameApplyAliasesMemo, which memoises the result of
applying a set of aliases (simple and regex) to an account name. In
theory this should reduce more repetitive work, but in practice it
doesn't seem to make a difference, so it's unused for now.
Roughly speaking, the time to apply regular expression account aliases
was O(aliases x transactions), and should now be O(aliases x accounts).
Also, the constant factor was reduced a lot by the recent commit
memoising toRegex. So now, regex aliases should be "free" like simple
aliases - use as many as you want, the slowdown shouldn't be noticeable.
The regex helpers were converting strings to regex-tdfa regular
expressions on the fly every time, but this appears to be quite
expensive. The simplest memoisation lib seems to solve it nicely.
hledger-lib-0.24's "track the commodity of zero amounts when
possible (useful eg for hledger-web's multi-commodity charts)" preserved
the commodity when normalising a zero mixed amount, but not the amount
style. This showed up as occasionally incorrect amount style (commodity
symbol placement, decimal point character, etc.) in balance reports with
certain journals, like this:
$ hledger bal
€3000.00 a <------ not using the canonical € style
4000,58€ 1
-1000,58€ D
-3000,00€ e
--------------------
0
I thought this would require a big rewrite of amount arithmetic, but it
seems that just being a little more careful is enough. When normalising
a mixed amount containing multiple zeros in the same commodity, we now
preserve the last zero with its amount style, instead of replacing them
all with a new one.
Make these modules' names more like the heavily-used types they
define (CliOpts, UIOpts, WebOpts). This is consistent with
RawOptions and ReportOptions, and helps with code navigation.
To reduce noise in the "other accounts" field of hledger-ui's and
hledger-web's account register: if there are both real and virtual
postings to other accounts, show only the accounts posted to by real
postings.
Use case: in many transactions I have extra balanced-virtual postings
which adjust budget envelopes (subaccounts of checking). These clutter
up the register's other accounts field making it useless. Excluding them
(when there are also real postings) makes it more useful for me and
probably others.
The register screen is now like the register view in hledger-web (and
other accounting systems), rather than hledger's register command.
This means:
- it shows transactions affecting a particular current account, rather
than postings matching a pattern.
- Each line represents a whole transaction.
- The account field shows the *other* account being transacted with.
When there is more than one, they are all listed, abbreviated and
marked with "(split)".
- The amount field shows the effect of the transaction on the current
account; positive for an inflow to this account, negative for an
outflow.
- The balance field should usually show the current account's historic
balance as of the transaction date, even when you change the report
start date. (Not working yet - currently it always shows the running
total).
- Transactions are listed most recent first, currently.
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.
The --format option's OutputFormat type was named confusingly like the
--output-format option. It has been renamed StringFormat to distinguish
it from StorageFormat (aka the data file format, referenced by
--output-format). Related code and types have been consolidated.
Also the (single-column) balance report's item rendering has had
some cleanup.
so we can benchmark things more easily with criterion.
As well as NFData, the Generic instance and a bunch more GHC extensions
seemed necessary. This is a little scary, impact unknown.
