jonestristand / hledger-parser

A parser for ledger/hledger journal files based on Chevrotain
MIT License
13 stars 2 forks source link

Doesn't support ledger tags #1

Open tbm opened 2 years ago

tbm commented 2 years ago

Ledger and hledger have a number of subtle differences. In particular, tags in ledger have this syntax:

    ; :tag1:tag2:

this is different to metadata which is

    ; key: value

In hledger the same syntax is used for both (basically tags are metadata without a value)

It's up to you whether you want to support ledger syntax but the description mentions both ledger and hledger.

const sourceCode = `2022-01-02 * Food   
    ; :foo:                                        
    Expenses:Nutrition:Dining            90.00 PHP
    Assets:Cash                         -90.00 PHP 
`;                                                 

gives:

/home/tbm/tt/node_modules/@jones.tristand/hledger-parser/build/main/index.js:155
    const rawJournal = cst_to_raw_1.default.journal(cstJournal.children);
                                                               ^

TypeError: Cannot read property 'children' of undefined
    at parseLedgerToRaw (/home/tbm/tt/node_modules/@jones.tristand/hledger-parser/build/main/index.js:155:64)
    at parseLedgerToCooked (/home/tbm/tt/node_modules/@jones.tristand/hledger-parser/build/main/index.js:225:52)
    at file:///home/tbm/tt/e.js:11:21
jonestristand commented 2 years ago

Thanks for pointing this out, I had missed implementing this. I'm unsure how to report this back in the resulting parsed object. The options that spring to mind are:

1) report it as a ledger_tags field in the object alongside the tags field: adds some somewhat ugly 'ledger'-specific fields 2) report it within the tags field: tidy, but means you can't reproduce the original document again, or necessarily tell which tag format was used in the source, or differentiate metadata from tags in ledger files 2a) as in 2, but each tag has a 'style' field that can be 'ledger' or 'hledger' - getting very busy deep in the object tree here... 3) Have an option in the call to the parser to enable hledger or ledger parsing - makes the parser itself much more complex as have to check which parser paths to go down, and may prevent parsing files that are a ledger/hledger hybrid.

Any thoughts on preferable solutions?

As an aside, these bugs point out that I've missed an error check, as this should return an empty result alongside the parser/lexer errors, rather than throwing.

tbm commented 2 years ago

I was sort of thinking about option 3, but it's really up to you. I'm honestly not sure what's best.

There are a number of subtle differences between ledger and hledger. Unfortunately they are not fully documented anywhere. This is a start: https://github.com/simonmichael/hledger/issues/1306

darylwright commented 8 months ago

I'd probably be in favour of not implementing ledger tags since they're not compatible with hledger. Adding support for ledger tags would mean that hledger-parser would support a 'tertiary' format that's a mix of hledger and ledger and compatible with neither. I think the best course of action here is to use an external utility to convert an hledger journal to ledger format if that's required, and let hledger-parser do what it's intended to be best at, which is parse hledger journals.