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
This makes it possible to internationalize strings while still using
I/O streams. For example:
std::cout << ACCUM(_("Hello to %1 and %2!") << "me" << "you")
<< std::endl;
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.
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.
The old implementation used an account formatter, and was very
specialized. The new is done as a transaction filter, and works along
with everything else, eliminating bugs special to the equity report.
When enabled, if any accounts or commodities are seen in an uncleared
transaction, which were not seen previously in a cleared or pending
transaction or a textual directive dealing with accounts or commodities,
a warning is generated about the unknown item.
This way, if two account values are BALANCE types containing only a
single AMOUNT, then it will do the sorting comparison of the amounts --
since otherwise balances are ignored for the purposes of sorting.
