Errors for default syntax with enabled strict checks

[asyncink]

hi

1. when enabled strict check for payees, hledger emits errors for all transactions without payee:

   2023-11-30
     Account1  1 USD
     Account2
   

   Strict payee checking is enabled, and
   payee "" has not been declared.
   Consider adding a payee directive. Examples:
   
   payee
   

   this can not be fixed because there is no way to create empty tag

2. when enabled strict check for tags, hledger emits errors for accounts with implicit type:

   account Assets:Cash  ; type: C
   

   Strict tag checking is enabled, and
   tag "type" has not been declared.
   Consider adding a tag directive. Examples:
   
   tag type
   

   this can be fixed by type tag, but this feels more like temp workaround

p.s. thx for hledger!

[asyncink]

hledger --version
hledger 1.31, mac-x86_64

[simonmichael]

Thanks for the report. For 1, perhaps we should allow declaring payee "" ? This would be consistent with commodity. (I'm not sure why just commodity with no "" was not allowed...)

For 2, are you saying that type tag should always be accepted even without a tag declaration because it's one of the hard-coded built-in tag names ?

[asyncink]

thank you for fast reply! hledger is already cool, but with the opportunity to discuss its development and remaining errors - it’s amazing.

1. actually I don’t think that allowing payee "" directive is good enough. according to documentation, user can optionally divide transaction description into two parts with char |: on the left side payee and on the right side and till the end of the line — description. for me it feels consistent that omitting char | is the same that just leaving right side as description without payee:

   2023-10-30 Whole Foods | Groceries for dinner ; <~ it’s payee and description
     Account1 10 USD
     Account2
   
   2023-10-30 Cinema with friends ; <~ it’s just a description (since no payee was provided)
     Account1 10 USD
     Account2
   
   2023-10-30 ; <~ no payee and no decsription
     Account1 10 USD
     Account2
   

   so in my opinion the expected behavior is if strict payees check is fired only for transactions with payee provided (with char ‘|’) and is not firing if no description provided or provided without char ‘|’.

   otherwise (and it’s current behavior for now) enabling strict payees check will parse three transactions above as 3 different payees, but Cinema with friends is just a description. it can be solved like this:

   2023-10-30 | Cinema with friends ; <~ it’s just a description (since to payee was provided)
     Account1 10 USD
     Account2
   

   but then strict payees check will throw error for empty payee. and also users with existing journals have problems with all their transactions.

   to summarize: in my opinion, strict payees check should fire only if character | is provided AND only if left part (substring leftside from the |) is not empty.

2. are you saying that type tag should always be accepted even without a tag declaration because it's one of the hard-coded built-in tag names — yes, exactly!

[simonmichael]

In principle I think payee is "Whole Foods", "", and "" respectively in those three cases, and it should be checked consistently in each case. Because it should be possible to disallow writing an entry without one of the valid payees (as with accounts, commodities, etc.) Possibly some docs/functionality might need to be adjusted here.

[asyncink]

"Whole Foods", "", and "" respectively in those three cases

yes, agree

it should be possible to disallow writing an entry without one of the valid payees (as with accounts, commodities, etc.)

yes, got this point, that's right

[simonmichael]

I have added payee "" support.

Re automatically declaring the built-in tag names: type is the one you mentioned; t is another one I can think of (generated by timedot's letters notation).

Should it be an error if the user tries to declare these tags themselves with tag type or tag t ?

[simonmichael]

The built-in tags are now auto-declared, and it's not an error if user accidentally declares them explicitly. I think this is resolved.