Permalink
Switch branches/tags
hledger-web-1.11.1 hledger-web-1.11 hledger-web-1.10 hledger-web-1.9.2 hledger-web-1.9.1 hledger-web-1.9 hledger-web-1.5.1 hledger-web-1.5 hledger-web-1.4 hledger-web-1.3.2 hledger-web-1.3.1 hledger-web-1.3 hledger-web-1.2 hledger-web-1.1 hledger-web-1.0.1 hledger-web-1.0 hledger-web-0.27 hledger-web-0.26 hledger-web-0.25.1 hledger-web-0.25 hledger-web-0.24.1 hledger-web-0.24 hledger-web-0.23.3 hledger-web-0.23.2 hledger-web-0.23.1 hledger-web-0.23 hledger-web-0.21.3 hledger-web-0_19 hledger-web-0_17_1 hledger-web-0_16_5 hledger-web-0_16_4 hledger-web-0_16_3 hledger-web-0_16_2 hledger-web-0_15_3 hledger-web-0_15_1 hledger{,-vty,-chart}-0_15_1,_hledger-web-0_15_2 hledger-ui-1.11.1 hledger-ui-1.11 hledger-ui-1.10.1 hledger-ui-1.10 hledger-ui-1.9.1 hledger-ui-1.9 hledger-ui-1.5 hledger-ui-1.4 hledger-ui-1.3.1 hledger-ui-1.3 hledger-ui-1.2 hledger-ui-1.1.2 hledger-ui-1.1.1 hledger-ui-1.1 hledger-ui-1.0.5 hledger-ui-1.0.4 hledger-ui-1.0.3 hledger-ui-1.0.2 hledger-ui-1.0.1 hledger-ui-1.0 hledger-ui-0.27.5 hledger-ui-0.27.4 hledger-ui-0.27.3 hledger-ui-0.27.2 hledger-ui-0.27.1 hledger-ui-0.27 hledger-lib-1.11.1 hledger-lib-1.11 hledger-lib-1.10 hledger-lib-1.9.1 hledger-lib-1.9 hledger-lib-1.5.1 hledger-lib-1.5 hledger-lib-1.4 hledger-lib-1.3.2 hledger-lib-1.3.1 hledger-lib-1.3 hledger-lib-1.2 hledger-lib-1.1 hledger-lib-1.0.1 hledger-lib-1.0 hledger-lib-0.27.1 hledger-lib-0.27 hledger-lib-0.26 hledger-lib-0.25.1 hledger-lib-0.25 hledger-lib-0.24.1 hledger-lib-0.24 hledger-lib-0.23.3 hledger-lib-0.23.2 hledger-lib-0.23.1 hledger-lib-0.23 hledger-irr-0.1.1.4 hledger-irr-0.1.1.3 hledger-irr-0.1.1.2 hledger-irr-0.1.1.1 hledger-irr-0.1.1 hledger-api-1.11.1 hledger-api-1.11 hledger-api-1.10 hledger-api-1.9.1 hledger-api-1.9 hledger-api-1.5 hledger-api-1.4
Nothing to show
Commits on Oct 15, 2018
Commits on Oct 13, 2018
  1. lib: journal: account: allow whitespace or a comment after the accoun…

    simonmichael committed Oct 13, 2018
    …t name
Commits on Oct 12, 2018
  1. doc: update hledger-irr mention

    simonmichael committed Oct 12, 2018
    [ci skip]
  2. journal: split up the parts of journalFinalise, and use them as needed.

    jkr authored and simonmichael committed Oct 12, 2018
    `journalFinalise` is only used in the `parseAndFinaliseJournal`
    functions, but it needs to be run differently at different stages when
    transaction modifiers are applied. This change breaks it into smaller
    functions, and uses those smaller parts in `parseAndFinaliseJournal`
    as needed.
  3. read: only run finalise twice if there are modifiers

    jkr authored and simonmichael committed Oct 12, 2018
    Previously we ran if `--auto` was set. But this adds a small
    performance hit if `--auto` becomes default. Now we only run twice if
    there are transactionModifiers AND `--auto` is set. So even if auto is
    specified, there will be no penalty if there are no modifiers.
  4. read: Integrate transaction modifiers with journal finalization

    jkr authored and simonmichael committed Oct 11, 2018
    Currently, automated transactions are added before the journal is
    finalized. This means that no inferred values will be picked up. We
    change the procedure, if `auto_` is set, to
    
     1. first run `journalFinalise` without assertion checking (assertions
        might be wrong until automated transactions), but with reordering
     2. Insert transaction modifiers
     3. Run `journalFinalise` again, this time with assertion checking as
        set in the options, and without reordering.
    
    If `auto_` is not set, all works as before.
    
    Closes: #893
  5. Journal: make reordering optional in `journalFinalise`

    jkr authored and simonmichael committed Oct 11, 2018
    Currently `journalFinalise` always reverses the order of
    entries. However, if there are automated transactions, we might need
    to run it twice. This adds a boolean flag to make reordering
    optional. This will be used in the `parseAndFinaliseJournal`
    functions.
Commits on Oct 11, 2018
  1. Anonymize original postings

    cocreature authored and simonmichael committed Oct 11, 2018
  2. tests: clean up directives test files

    simonmichael committed Oct 11, 2018
    [ci skip]
Commits on Oct 10, 2018
  1. bs/bse/cf/is: use account type declarations if any

    simonmichael committed Sep 27, 2018
    These commands now detect the account types declared by account directives.
    Whenever such declarations are not present, built-in regular expressions
    are used, as before.
  2. journal: account directives can declare account types

    simonmichael committed Sep 27, 2018
    Previously you had to use one of the standard english account names
    (assets, liabilities..) for top-level accounts, if you wanted to use
    the bs/bse/cf/is commands.
    Now, account directives can specify which of the big five categories
    an account belongs to - asset, liability, equity, revenue or expense -
    by writing one of the letters A, L, E, R or X two or more spaces after
    the account name (where the numeric account code used to be).
    
    This might change. Some thoughts influencing the current syntax:
    - easy to type and read
    - does not require multiple lines
    - does not depend on any particular account numbering scheme
    - allows more types later if needed
    - still anglocentric, but only a little
    - could be treated as syntactic sugar for account tags later
    - seems to be compatible with (ignored by) current Ledger
    
    The current design permits unlimited account type declarations anywhere
    in the account tree. So you could declare a liability account somewhere
    under assets, and maybe a revenue account under that, and another asset
    account even further down. In such cases you start to see oddities like
    accounts appearing in multiple places in a tree-mode report. In theory
    the reports will still behave reasonably, but this has not been tested
    too hard. In any case this is clearly too much freedom. I have left it
    this way, for now, in case it helps with:
    
    - modelling contra accounts ?
    - multiple files. I suspect the extra expressiveness may come in handy
      when combining multiple files with account type declarations,
      rewriting account names, apply parent accounts etc.
      If we only allowed type declarations on top-level accounts, or
      only allowed a single account of each type, complications seem likely.
Commits on Oct 9, 2018
  1. lib: fix home path expansion in includes

    ony authored and simonmichael committed Oct 9, 2018
    fixes #896
  2. lib: fix my wrong merge of #880 more

    simonmichael committed Oct 9, 2018
  3. Merge pull request #880 from awjchen/ExceptTLayer

    simonmichael committed Oct 9, 2018
    Re-implement the 'ExceptT' layer of the parser and switch to megaparsec 7 [WIP]
  4. lib: document SmartDate

    simonmichael committed Oct 9, 2018
    [ci skip]
  5. lib: revise comments for "final" parse errors

    awjchen committed Oct 9, 2018
    - also simplify their implementation a bit