It's clearer to write command-specific flags after the command name
argument, but that's no longer required.
(Writing non-builtin, addon-specific flags after -- is still required).
Also, give up on "obey help/doc/version flags even if there's a bad
command/flag", it's too hard to do well.
The Total: row headings are now configurable in one place,
and currently disabled for text output and enabled for csv & html.
The balance commands' HTML output no longer repeats the "total" and
"Net" headings when the totals row has multiple lines.
And the layout has been improved and made more consistent with the
text output.
Now, updating a command's docs (for hledger manual and for --help) requires
running the command (with stack exec -- hledger). The sequence is now
a bit recursive:
1. Run hledger CMD -h to update CMD.md with the latest cmdargs help output for CMD's flags.
CMD.md is included in the hledger manual, when rendering that.
2. Convert CMD.md to CMD.txt, with pandoc.
3. Build hledger, embedding CMD.txt for cmdargs to use as -h output.
This need only be done after changing command docs or flags, and
hopefully won't be a hassle. Shake cmddocs now shows progress output
to make things clearer.
and tweak command/screen headings.
This goes further in the direction of showing simple lists of topics
instead of outlines. mdbook-toc doesn't support configuring the TOC
depth this per page, so it has to be site wide.
Overall I feel this is better, see eg the hledger manual. It hides a
lot of interesting topic names but a shorter, linear list is less
scary and clearer than a huge scrolling outline. Once you click in to
a section and find a subsection of interest, it's still easy to
bookmark/share those by clicking their heading.
This enables a "relaxed" workflow where you delay balance assertions
checking until strict mode is turned on: always run hledger -I, and
add -s when you're ready.
When built with the ghcdebug flag and started with --debug=-1 (or -2
to pause at startup, or -3 to pause before exit), hledger can be
controlled by ghc-debug clients like ghc-debug-brick or a custom
ghc-debug query script.
Also, refactor version string code.
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.
They are `balances:` for assertion transactions,
`retain:` for retained earnings transactions,
and `start` for opening/closing transactions.
And some --help cleanups.
On MS Windows, trying to add or import or web add to a file whose name
ends with a dot could cause data loss, so in 2019 I made this raise an
error instead (in Hledger.Read.ensureJournalFileExists).
But, the logic was backward, so it did not do the check on Windows.
Now it does.
Also I have removed mention of this from add's doc; currently it's
not documented anywhere. It's obscure, but maybe this is not ideal.
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.)
- omit balance assertions
- replace more currency symbols, and match within symbols like C$
- do more account validation, and error if conversion is too hard
- backslash-escape double quotes and backslashes in payee and note
hledger import -s now runs strict checks on an in-memory copy of the
updated journal, before updating the journal file; if strict checks
fail, nothing is written to disk.
And hledger import now does not update any .latest files until it has
run without error (no failing strict checks, no failure while writing
the journal file). This makes it more idempotent, so you can run it
again after fixing problems.
With valuation now preserving more decimal digits, roi could show
excessively precise decimals if there was no known display precision
for the valuation commodity. Now in that situation it limits the
precision to a maximum of 8 digits.
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.
- The prices comand now more accurately lists the prices that hledger
uses when calculating value reports (similar to what you'd see with
eg `hledger bal -V --debug=2`).
- The prices command's --infer-reverse-prices flag was confusing since
we always infer and use reverse prices; it has been renamed to --show-reverse.
- --infer-market-prices and --show-reverse combine properly.
- --show-reverse now ignores all zero prices rather than giving an error.
- Reverse prices (which can be infinite decimals) are now displayed
with at most 8 decimal digits (rather than the internal precision of
255 digits).
- Filtering prices by cur: or amt: now works properly.
- Price amounts are styled, but all decimal digits are shown.
All commands that suport csv output now also support tsv output. The
data is identical, but the fields are separated by tab characters and
there is no quoting or escaping. Tab, carriage return, and newline
characters in data are converted to spaces (this should rarely if ever
happen in practice).
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).
hledger check recentassertions now reports the error at the first
posting that's more than 7 days later than the latest balance
assertion (rather than at the balance assertion). This is the thing
actually triggering the error, and it is more likely to be visible or
at least closer when you are working at the end of a journal file.
Pointed out by mauke in #haskell chat: this was incorrectly splitting
PATH on windows (splitting on the : in C:\...), which meant that
people using multiple drive letters on Windows might see hledger
failing to recognise installed add-on commands.
CSV rules files can now be read directly, eg you have the option of
writing `hledger -f foo.csv.rules CMD`. By default this will read data
from foo.csv in the same directory. But you can also specify a
different data file with a new `source FILE` rule. This has some
convenience features:
- If the data file does not exist, it is treated as empty, not an
error.
- If FILE is a relative path, it is relative to the rules file's
directory. If it is just a file name with no path, it is relative
to ~/Downloads/.
- If FILE is a glob pattern, the most recently modified matched file
is used.
This helps remove some of the busywork of managing CSV downloads.
Most of your financial institutions's default CSV filenames are
different and can be recognised by a glob pattern. So you can put a
rule like `source Checking1*.csv` in foo-checking.csv.rules,
periodically download CSV from Foo's website accepting your browser's
defaults, and then run `hledger import checking.csv.rules` to import
any new transactions. The next time, if you have done no cleanup, your
browser will probably save it as something like Checking1-2.csv, and
hledger will still see that because of the * wild card. You can choose
whether to delete CSVs after import, or keep them for a while as
temporary backups, or archive them somewhere.
I found at least one user for whom this would be a breaking change
(they generate forecast txns, and have auto posting rules, but don't
want the latter applied to the former). I guess it's better to keep
things as they were for now: if you need auto postings on your
forecast txns you must use two flags, --forecast --auto.
Previously, similarity completely outweighed recency, so a
slightly-more-similar transaction would always be selected no matter
how old it was. Now similarity and recency are more balanced,
and it should produce the desired transaction more often.
There is also new debug output (at debug level 1) for
troubleshooting.
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.
I was confused when using 'areg ACCT QUERY'. Now, the title will show
" (matching query)" as a hint when a QUERY is specified,
except when it is a date restriction (which is common and not confusing)
or a depth restriction (which is ignored).
