I was negligent and did not test enough. This should ignore
transaction comments in auto posting rules more safely.
It also adds support for trailing comments on the first line of auto
posting rules, which previously were misparsed as part of the query.
'fail' will just terminate the current parse branch, whereas here
we have encountered a definite error. Also bring the code to
get the current working directory inside 'getFilePaths', as it
logically belongs there.
- inline `spaceamountormissingp` into `postingp`
- combine `rightsymbolamountp` and `nosymbolamountp`
- the multiplier symbol '*' for an amount must now always preceed a sign '-'
[breaking change]
- make amount parser labels more generic to simplify error messages
For Data/Dates.hs in particular:
- Changed `SimpleTextParser` to `TextParser m` for all parsers
- Changed `string` to the case-insensitive `string'` to match the
behaviour of `T.toLower` found in `parsePeriodExpr`
- export `periodexprp` for "direct" use
base-compat-batteries provides the same API across more ghc versions
than base-compat does, at the cost of more dependencies. Eg it exports
Prelude.Compat ((<>)) with ghc 7.10/base 4.8, which we expect.
My belief is that several of our deps already require it so the added
cost is not too great. We should probably go back to base-compat when
possible though, eg when we stop supporting ghc 7.10.
The new version of our package set apparently contains both base-compat and
base-compat-batteries in its transitive closure. This breaks the doctest suite,
which just imports everything into scope when the tests are run, thereby making
module names like Prelude.Compat ambiguous.
We don't need to import Data.Monoid because Prelude.Compat exports "<>"
already. In fact, importing that module causes build failures:
Hledger/Read/Common.hs:725:62: error:
Ambiguous occurrence ‘<>’
It could refer to either ‘Sem.<>’,
imported from ‘Prelude.Compat’ at Hledger/Read/Common.hs:97:1-39
(and originally defined in ‘Data.Semigroup’)
or ‘Data.Monoid.<>’,
imported from ‘Data.Monoid’ at Hledger/Read/Common.hs:110:1-18
Fixes https://github.com/simonmichael/hledger/issues/794.
A commodity directive that doesn't specify the decimal point character
increases ambiguity and the chance of misparsing numbers, especially
as it overrides all style information inferred from the journal amounts.
In some cases it caused amounts with a decimal point to be parsed as if
with a digit group separator so 1.234 became 1234.
We could augment it with extra info from the journal amounts, when available,
but it would still be possible to be ambiguous, and that won't be obvious.
A commodity directive is what we recommend to nail down the style.
It seems the simple and really only way to do this reliably is to require
an explicit decimal point character. Most folks probably do this already.
Unfortunately, it makes another potential incompatiblity with ledger and
beancount journals. But the error message will be clear and easy to
work around.
