| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following details of a posting contribute to its hash:
fullname of account
string representation of amount
Each posting hashes contributes to the transaction hash, which is compromised
of:
previous transaction’s hash (as encountered in parsing order)
actual date
optional auxiliary date
optional code
payee
hashes of all postings
Note that this means that changes in the “code” or any of the comments
|
|
|
|
| |
[skip ci]
|
| |
|
|
|
|
| |
[ci skip]
|
|
|
|
| |
[ci skip]
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
| |
The following script makes it a no-brainer:
% NEXT_YEAR=2015; ag -l 'Copyright.*Wiegley' \
| xargs sed -i '' -e "s/\(Copyright.*\)-20[0-9]\{2\}/\1-${NEXT_YEAR}/"
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now instead of ledger reg expense -p "this month", you can say:
ledger reg expense for this month
And as a shorthand for "for until this month", you can just say "until
this month" or "since this month".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
ledger bal assets bold checking
Or you can use expressions:
ledger bal assets bold '=total > 1000'
This last is identical to saying:
ledger bal -l 'account =~ /assets/' --bold-if='total > 1000'
|
|
|
|
|
|
|
|
|
|
| |
With -n, the first argument is parsed as a string containing
subarguments. Otherwise, each argument is parsed as a separate
argument.
In short, the -n mode mimicks what happens when the query expr after "="
is parsed for automated expressions. The non -n mode mimicks what
happens at the command line for users.
|
|
|
|
|
| |
Now when the Y directive sets the current year for a region, it affects
everything, as if the clock really were set back to that year.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The metadata construct 'Key: Value' is now just a special case for
'Key:: "Value"'. Another after a :: in metadata setting is parsed as a
full value expression and typed as such. For example:
; Key:: $400 + $500
ledger -l 'tag("Key") < $1000'
|
| |
|
| |
|
| |
|
|
|
|
| |
It's always possible the user only specified a display predicate.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It is now a full parser that parses report queries directly into value
expression trees. These then get rendered into text so that other
options may extend the expression.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Everything beyond the show modifies the --display predicate, and
everything before modifies the --limit predicate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These strings are now collected automagically in the file po/ledger.pot.
If you'd like to produce a translation, just run this command after
building Ledger:
msginit -l LOCALE -o LANG.po -i po/ledger.pot
Where LOCALE is a string like de or en_GB, and LANG is a short
descriptive word for your language.
Then send me this .po file so I can commit it to the Ledger sources
(alternatively, you could maintain the file in a fork on GitHub), and
setup the build script to format and install your new message catalog
during a "make install".
|
|
|
|
|
| |
The last commit did not contain the majority of changes because of a
slight mishap. This contains the real changeset.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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 the value shown follows the current reporting options.
|
|
|
|
|
| |
It now shows the formatted result against a sample entry, similar to
what "parse" now does.
|
| |
|
| |
|
| |
|
| |
|