| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This means that final balance valuations (with -V or -X) will be done in
terms of the date given to --end, rather than based on the current day.
Fixes 647D5DB9-DBBB-47C8-80CE-F3F70E3B0253
|
| |
|
|
|
|
|
|
| |
This is necessary in order to redden negative amounts correctly under
all circumstances, such as component amounts of a multi-commodity
balance.
Fixes 727B2DF8-A2A1-4716-9C15-547F20D5F933
|
| |
|
|
|
| |
This reports which options are in place before invoking a command, and
where exactly each option value came from.
|
| | |
|
| |
|
|
|
|
|
| |
It is no longer done in calc_posts, but recursively on each account.
This allows value expressions to ask statistical questions, like
"earliest cleared posting?" (TBD) from any specific account, computed
lazily.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although %(amount) inserts an item's amount, it only does exactly that.
There is no special consideration like stripping of lot details, or
reduction to the base commodity, etc. For those things, and to make
sure it was display in red if negative, the canonical form would be:
%(ansify_if(justify(scrub(amount), 12, -1, true), red if amount < 0))
You can now use the special %{} form as an alternate to this:
%12{amount, red if amount < 0}
The two expand to the same underlying expression.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Everything beyond the show modifies the --display predicate, and
everything before modifies the --limit predicate.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The last commit did not contain the majority of changes because of a
slight mishap. This contains the real changeset.
|
| | |
|
| |
|
|
| |
These are for dealing with sequences.
|
| | |
|
| |
|
|
| |
Also, --exchange now accepted multiple, comma-separated commodities.
|
| |
|
|
| |
They must be separated by a comma, and all whitespace is ignored.
|
| |
|
|
|
|
|
| |
This is like -V, except it lets you specify the goal commodity to report
in terms of, for example:
reg -x CAD
|
| | |
|
| | |
|
| |
|
|
| |
This option was for outputting <total> elements in 2.x's XML output.
|
| |
|
|
|
|
|
|
|
| |
The following colors are applied in the balance and register reports:
GREEN To a date, if it occurs in the future
BOLD If a payee name relates to an uncleared entry
BLUE For account names
RED For negative values
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of this class is much like Emacs' (interactive) form: it
allows a value expression function to declare exactly how many
arguments, and of what type, it intends to receive. It then offers
type-safe access to theese arguments in a consistent manner.
An example value expression function definition in C++:
value_t fn_foo(call_scope_t& scope) {
// We expect a string, an integer, and an optional date
interactive_t args(scope, "sl&d");
std::cout << "String = " << args.get<string>(0)
<< "Integer = " << args.get<long>(1) << std::endl;
if (args.has(2)) // was a date provided?
std::cout << "Date = " << args.get<date_t>(2) << std::endl;
return NULL_VALUE;
}
There is also an in_context_t<T> template, which finds the context type
T in the current scope hierarchy. The in_context_t then also acts as a
smart pointer to reference this context object, in addition to serving
the same duty as interactive_t. This combination of intent is solely
for the sake of brevity.
value_t fn_bar(call_scope_t& scope) {
in_context_t<account_t> env(scope, "sl&d");
std::cout << "Account name = " << env->fullname()
<< "String arg = " << env.get<string>(0)
<< std::endl;
return NULL_VALUE;
}
As you can see here, 'env' acts as a smart pointer to the required
context, and an object to extract the typed arguments.
|
| | |
|
| |
|
|
|
| |
For example, --start-of-week=monday can be used to report weeks that
begin on Mondays.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The purpose of this option is that usually when you do a --monthly
periodic report, you see dates ranges from the first day of each month,
to the last day. With --exact, the first day of each range will be the
date of the first transaction found in that range, and likewise with the
end of the range. Essentially it "contracts" the reported period dates
to reflect the exact begin and end dates.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
