ledger-add-xact fails in an empty buffer ignoring main ledger file

[mikeonly]

Hi, I am having issues running C-c C-a bound to ledger-add-transaction in a new file that has no transaction. The issue is that ledger xact executed from ledger-add-transaction returns no matches.

Relevant setup is the following:

• main.journal with includes files and contains historical transactions
• new.journal which I create and would like to fill with new transaction using C-c C-a functionality

I use ledger-mode in Doom Emacs through straight. I have set these variables for ledger-mode:

(setq ledger-init-file-name (expand-file-name "~/Documents/Finances/Private/main.journal")
        ledger-accounts-file (expand-file-name "~/Documents/Finances/Private/meta.journal")
        ledger-binary-path "/opt/homebrew/bin/ledger"
        ledger-default-date-format ledger-iso-date-format
        ledger-highlight-xact-under-point nil)

When I run C-c C-a with any date and uber, ledger-mode raises error:

Error: No accounts, and no past transaction matching 'uber'

However, in cli, ledger xact 2023-11-11 uber would give a match

2024-03-20 Uber
    Expenses:Transport:Cabs                EUR 53.36
    Assets:Visa

I suspect the error occurs here in ledger-exec-ledger code. In fact, (ledger-master-file) resolves to the current buffer, new.journal, which is empty, and so as far as I see ledger xact is called via call-process-region with just contents of the new.journal file, i.e. with no historical transactions.

Am I missing anything to make C-c C-a work in the config, that is, to receive ledger-init-file-name or have ledger-master-file properly resolved? I tried setting it as a variable, but that leads to C-c C-a just failing with an error Ledger execution failed. Thanks :)

[bcc32]

ledger-init-file-name is supposed to be the path to your ledger configuration, e.g., ~/.ledgerrc, not a journal file.

ledger-master-file is (in addition to being a function) a buffer-local variable that is designed to be set file-locally. E.g., use M-x add-file-local-variable to set ledger-master-file to main.journal in new.journal.

See the docstring of ledger-master-file:

Return the master file for a ledger file.

The master file is either the file for the current ledger buffer or the
file specified by the buffer-local variable ledger-master-file. Typically
this variable would be set in a file local variable comment block at the
end of a ledger file which is included in some other file.

[mikeonly]

Thanks for clarifying the confusion, indeed. However, even when I set these values to proper values, I still get error Ledger execution failed.

Here's what I add to new.journal:

; Local Variables:
; ledger-master-file: "/Users/mf/Documents/Finances/Private/main.journal"
; End:

and I see that the variable ledger-master-file is set properly locally. I then adjust ledger-init-file-name and point it to ~/.ledgerrc which contains just --sort date line.

If you could suggest how I can pin point exactly what fails and give more debugging info, I'd really appreciate that!

[bcc32]

Ah, I see. Looking at it now, it looks like ledger-master-file is simply not used for ledger-add-transaction (it is used for reports and flymake). I don't know if this is necessarily on purpose, but it seems that ledger-add-transaction always uses the current buffer. It seems useful to have it use the master file (if such a variable is set), but one nice thing about having it use the current buffer's contents is that you can add the same transaction twice in a row really easily without having to save the file in between, so it's not 100% clear if changing the behavior is the right move. @purcell, do you have thoughts on this issue?

[purcell]

Not sure there's an objectively best choice, sorry. You wouldn't necessarily want to force the current file to be saved, nor should you necessarily need all the other files included by ledger-master-file to be well-formed. I feel like the master file is more about operations where it's important that everything is balanced/reconciled appropriately. I guess I'd probably lean towards preserving the current behaviour, then, but I don't feel strongly about it.