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.
When the error message repeated the invalid date at the end,
it was possible to misinterpret that as a suggested fix (reported in chat).
Instead, date errors (most of them) now rely on the highlighted data
excerpt above. This is also preferable since it shows the original
date as written, not a reconstruction with a possibly different format.
Should this be the policy for all error messages going forward ?
It would be easier.
Can we assume the data excerpt is always visible along with the error message ?
It isn't shown by flycheck-hledger in emacs, eg.
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).
Adjust getEffectiveAssignment to compute an intermediary form of the
active assignments (with an additional Either wrapper to distinguish
top-level and conditional assignments) and move the remaining work to
its only caller, hledgerField.
Rework hledgerFieldValue. Instead of calling hledgerField, call
getEffectiveAssignment and--in the conditional block case--construct
a CsvRules scoped just to the active ConditionalBlock before calling
renderTemplate.
Adjust regexMatchValue to use rconditionalblocks to access conditional
blocks from the CsvRules, rather than rblocksassigning, since we haven't
narrowed the scope of that field.
The result is match group references are only expanded for match groups
that occur within the in-scope ConditionalBlock. Fixes: #2158.
Signed-off-by: Jonathan Dowland <jon@dow.land>
hledgerField is an alias to the function getEffectiveAssignment: both
names are used in various parts of RulesReader.
Treat hledgerField as the canonical name, and getEffectiveAssignment
as an implementation detail of hledgerField.
Replace all uses of getEffectiveAssignment with hledgerField (except the
one in hledgerField.)
Signed-off-by: Jonathan Dowland <jon@dow.land>
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.
Based on feedback in chat, I added support for several more kinds of
Unicode space character for separating digit groups, both when reading
and when displaying numbers. These are the spaces currently supported,
which are just my best guess at the ones that might show up in CSV files
now and then:
space,
no-break space,
en space,
em space,
punctuation space,
thin space,
narrow no-break space,
medium mathematical space
Parent accounts with no actual or goal amounts would ideally be shown
elided on the same line, but the budget report in tree mode was
omitting them completely. Now --budget always shows them.
The effect is much like forcing --no-elide on, except it might not
show goal amounts that --no-elide does show.
It's not a wonderful fix, but the budget report code is twisty and I
can't afford to spend more time on this.
When reading a symbolically-linked journal file,
relative paths in include directives are now evaluated
relative to the directory of the real linked file,
not the directory of the symlink.
This also seems to fix an obscure case where stats did not report
absolute included file paths in certain circumstances (stdin, maybe no
terminal..)
The previous #2153 fix used accountNameTreeFrom, but it turns out this
has always had O(n^2) performance, so our tests with 10k accounts ran
even slower than before. Now it's faster, the main #2153 slowdown
should really be fixed, and other commands which build an account tree
should also be free of this slowdown when there are very many accounts.
When processing costs and equity postings in transactions during
journal finalisation, we now pass just the conversion account name(s)
rather than the entire map of account types. This slowdown was severe
for some users/data/machines.
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).
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.
In field assignment values we now parse %FIELD references, \MATCHGROUP references
and "\n" newline markers more carefully, so all can coexist.
Parsing these values might be slower than before, but hopefully not noticeably so.
Hledger.Utils.Debug.traceOrLog was logging when it should trace and vice versa.
This affected a warning which Hledger.Data.Valuation.pricesShortestPath
should display if encountering a pathologically long (>1000) price chain.
Also note some oddities about that warning.
The hledger-web tests have been cleaned up and now allow more testing
of command line options like (though still not everything).
Note tests now run the app listening on its default host and port,
127.0.0.1 and 5000, instead of "any IPv4 or IPv6 hostname" and 3000.
This would seem to mean hledger-web tests can conflict more with
things running on port 5000, eg a normal hledger-web instance, but I
haven't been able to reproduce it.
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.)
Now using type: in account declarations or generating t: with timedot
letters won't cause the `tags` check to fail.
If a user declares any of these explicitly with a tag directive,
it does not cause an error.
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.
- 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
That 1.31 change was advertised as being for the print command only,
but it affected all commands. Now it affects only print and other
"print-like" commands (ie all commands that show whole journal entries
that we might want to re-parse).
Also three classes of hledger output, and how they modify the
commodity display styles' digit group marks and decimal marks
to suit different consumers, have been identified and documented
(under REPORTING CONCEPTS).
Strict checks now run only once, at end of the high level read operation,
and not for each individual file; this fixes some spurious --strict failures,
like account declarations not affecting a sibling file as they should.
And .latest file writing now happens as the last step, after passing
strict checks. This is mainly for the import command, but it also
means that hledger print --new now does not update .latest files
if strict checks are failing.
The file reading API has been improved and documented in more detail.
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.
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.
Replace occurrences of '\N' (where N is a positive number) in field
templates with the corresponding regular expression match group, if it
exists.
E.g. Warp the date to the first of the month for the second posting
if %date (....-..)-..
comment2 date:\1-01
E.g. Strip a prefix from an imported account name
if %account1 liabilities:jon:(.*)
account1 \1
Fixes#2009.
Signed-off-by: Jonathan Dowland <jon@dow.land>
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).
A quantity with a unit like "15m" was being parsed internally as
0.249999999... rather than 0.25 (and since hledger 1.21, printed that
way also). Now we round such quantities to two places during parsing,
to get exact quarter-hour amounts.
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).
Eg "1,000" (with , as a thousands separator and no decimal digits) is
now displayed with a decimal mark: "1,000.".
"1 000" (where space is a thousands separator) is less ambiguous,
but we do the same thing (eg "1 000.") for consistency, and also to
help disambiguate when forgetting to quote a numeric commodity symbol
(eg "1234 0" where 1234 is a symbol that should have been in double quotes).
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.
print now shows zero posting amounts with their original commodity
symbol and the corresponding style (instead of stripping the symbol).
If an inferred amount has multiple zeroes in different commodities,
a posting is displayed for each of these.
Possible breaking changes:
showMixedAmountLinesB, showAmountB, showAmountPrice now preserve
commodityful zeroes when rendering. This is intended to improve print output,
but it seems possible it might also affect balance and register reports,
though our tests show no change in those.
Equity conversion postings and cost amounts were being matched up too
exactly, causing valid entries with redundant conversion postings and
costs to be rejected. Now the amounts are compared with the precision
(number of decimal places) used in the conversion posting's amount.
Eg, here the first posting's 209.60495 GEL cost is recognised as a
match for the third posting's -209.60 GEL, using the latter's two
digit precision:
2023-01-01
Assets -84.01 USD @ 2.495 GEL ; 209.60495 GEL
Equity:Conversion 84.01 USD
Equity:Conversion -209.60 GEL
Assets 209.60 GEL
The suggested sample balance assertion now uses the same commodity
symbol as in the failing posting (the first, if there are more than
one). Also the cleared mark has been removed.
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.
Since 1.29, we unconditionally run part of the --infer-cost logic to
identify redundant costs/equity postings. This was too strict, raising
an error whenever it could not find postings matching the equity
postings. Now we do this (and also the explicit --infer-costs
operation) as a best effort, leaving transactions unchanged if we
can't detect matching postings. This is consistent with
--infer-equity, --infer-market-prices, -B and -V.
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.
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.
Inner empty lines were not being skipped automatically, contrary to
docs. Now all empty lines are skipped automatically, and the `skip`
rule is needed only for non-empty lines, as intended.
This may be a breaking change: it's possible that the `skip` count
might need to be adjusted in some CSV rules files.
This can be useful to override defaults in scripts.
These flags will now toggle when repeated on the command line:
--invert
--transpose
-r/--related
-%/--percent
-E/--empty
-N/--no-total
-T/--row-total
-A/--average
-S/--sort-amount
Since hledger 1.25, "every Nth day of month" period rules with N > 28
could be off by a couple of days if given certain forecast start dates.
Eg `~ every 31st day of month` with `--forecast='2023-03-30..'`.
Breaking change: previously timeclock descriptions could contain
semicolons. Now a semicolon in the description will end it and
start a comment (which may contain tags).
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.
When doing a type: match we now also check the original unaliased,
unpivoted posting, as when doing an acct: match. This is effectively
how things worked with the older account type detection in hledger <1.27.
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.
