[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] Re: Org-Babel and Ledger
Re: [Orgmode] Re: Org-Babel and Ledger
Thu, 12 Aug 2010 16:57:23 -0600
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
Sébastien Vauban <address@hidden> writes:
> Hi Eric(s),
>>>> As you can see, the tables are completely wrongly made, because they're
>>>> based on spaces ("à la Awk") and not on fixed position of fields ("à la
>>>> What can I do about this?
>>>> - Post-process every ledger command with some awk or cut command that will
>>>> do whatever is needed
>>>> - Exploit the CSV export format (never tried, don't have Ledger 3
>>>> installed yet -- and I'm also using hledger...)
>>> Couldn't you use ledger's format strings for fine-tuned control of the
>>> command output? I don't know how you're snarfing the output, but it seems
>>> like you could using formatting to produce something that already looks
>>> very much like an org table, or perhaps CSV.
> That anser is not really applicable in my case, as I would like to use at
> least `ledger' and `hledger' for different reports, and they don't share the
> same exporting capabilities.
> Plus the problem would come back for any other command-line tool...
>> Many languages import tabular contents into elisp tables which are then
>> inserted into Org-mode buffers as Org-formatted tables. This should be
>> possible by replacing the call to `buffer-string' at the end of the
>> `org-babel-execute:ledger' function with something analogous to the
>> following (copied from ob-sqlite.el).
>> (if (or (member "scalar" result-params)
>> (member "html" result-params)
>> (member "code" result-params)
>> (equal (point-min) (point-max)))
>> (org-table-convert-region (point-min) (point-max))
> That's, then, the interesting line for me...
>> (org-table-to-lisp) headers-p)))
>> I would recommend this approach over shell-script post-processing.
> That seems not to work for me, as input data is, for example:
> 09-Aug-21 CHEQUE : 9953055 Expenses:Unknown
> 166.70 EUR 166.70 EUR
> 09-Sep-17 CHEQUE : 7691785 Expenses:Unknown
> 100.00 EUR 266.70 EUR
> 09-Oct-16 REMISE CHEQUE N 8686318 001 105 Expenses:Unknown
> -525.00 EUR -258.30 EUR
> and as =org-table-convert-region= can't convert fixed positioned fields
> (when SPC are used instead of TAB):
> (org-table-convert-region beg0 end0 &optional separator)
> Convert region to a table.
> The region goes from beg0 to end0, but these borders will be moved
> slightly, to make sure a beginning of line in the first line is included.
> separator specifies the field separator in the lines. It can have the
> following values:
> '(4) Use the comma as a field separator
> '(16) Use a TAB as field separator
> integer When a number, use that many spaces as field separator
> nil When nil, the command tries to be smart and figure out the
> separator in the following way:
> - when each line contains a TAB, assume TAB-separated material
> - when each line contains a comma, assume CSV material
> - else, assume one or more SPACE characters as separator.
> Should that function be smarter, or do I still need pre-processing, then?
Neither, notice that if you pass an integer as the third argument to
org-table-convert-region it will parse on that many consecutive spaces.
The following works for me, on the case your provided although I suppose
it may not work on all cases.
09-Aug-21 CHEQUE : 9953055 Expenses:Unknown
166.70 EUR 166.70 EUR
09-Sep-17 CHEQUE : 7691785 Expenses:Unknown
100.00 EUR 266.70 EUR
09-Oct-16 REMISE CHEQUE N 8686318 001 105 Expenses:Unknown
-525.00 EUR -258.30 EUR
#+begin_src emacs-lisp :var ledger=ledger-output
(org-table-convert-region (point-min) (point-max) 2)
| 09-Aug-21 CHEQUE : 9953055 | Expenses:Unknown | 166.70 EUR |
166.70 EUR |
| 09-Sep-17 CHEQUE : 7691785 | Expenses:Unknown | 100.00 EUR |
266.70 EUR |
| 09-Oct-16 REMISE CHEQUE N 8686318 001 105 | Expenses:Unknown | -525.00 EUR |
-258.30 EUR |
Hope this helps -- Eric
> Thanks for your comments...
> Best regards,