compare compare_items<T>
handler item_handler<T>
iterators used to iterators sets of journal objects
filters derived from item_handler, they morph the result set
output derived from item_handler, these do the printing
Also, created a new 'help' files which contains just Ledger's help text.
What this means is that the utility code, basic math, value expressions,
string formatting and option handling are now entirely decoupled from the rest
of the code. This decoupling not only greatly simplifies the more basic parts
of Ledger, but makes it much easier to test and verify its completeness.
For example, when the formatting code %X is seen by the format parser, it
turns into a call to the expression function fmt_X, which must be defined when
the format string is first compiled against an object. If that object is a
transaction, the transaction's scope will be the first to have a chance at
providing a definition. If an account is being reported, it will. If neither
does, the next scope in sequence -- soon to be the current report -- will, and
then the session object that "owns" the current Ledger session.
In 2.6, the formatting code new everything about transaction and accounts, and
relied on flags to communicate special details between them. Now the
transaction will offer the details for its own reporting, while the formatter
worries only about strings and how to output them.
This means transactions can only have day-level granularity -- which has
always been the case from an data file point of view. The advantage to this
restriction is that reports will now be immune from daylight savings related
bugs, where a transaction falls to the wrong side of a --monthly report, for
example.
complicated string of pointers, it's now just a global block of text that gets
appended to as the error is being thrown up, and can be displayed at the catch
point if desired. There are almost no cases where a thrown exception will not
result in an error message being displayed to the user.
except for several unused parameter warnings (because there is so much code
still #if 0'd out), and one implicit conversion from long long to long which
still has to be dealt with.
old system (for example, the meaning of 'a') has yet to be restored. In the
new scheme, this will be done by definition a function outside of the value
expression logic, rather than the tight coupling between journal innards and
value expressions that occurred in 2.x.
XML-related bits -- I just wanted the better infrastructure that had been
created during the rewrite. It doesn't work, but it compiles and links now.
This means that all of the previous 3.0 code has been moved over, although
there are still snippets of code in pending/old that need to be restored.
entries. The new format strings %xB %xE %xb %xe can be used to
display those values relative to a transaction. The Emacs module now
relies on this support to exactly determine where a transaction is,
rather than the Elisp logic it relied on previously.
choose which output style they want (truncation at beginning, middle
or end of the string). (export_format): Expose following handlers to
Python: FormatTransactions, FormatEntries, FormatXmlEntries,
FormatAccount, FormatEquity.
at the beginning and middle of a string (neither of which seems better
than truncating at the front). (output_xml_string): Change xml_string
to output_xml_string, for simplicity's sake. Also, < and > are now
output as < and >. (format_last_entry): Use output_xml_string
for the account name as well as the code, payee and note.
