emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Org-Babel and Ledger


From: Sébastien Vauban
Subject: [Orgmode] Re: Org-Babel and Ledger
Date: Thu, 12 Aug 2010 13:45:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

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
>>> Cut").
>>>
>>> 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)))
>         (buffer-string)
>       (org-table-convert-region (point-min) (point-max))

That's, then, the interesting line for me...


>       (org-babel-sqlite-table-or-scalar
>        (org-babel-sqlite-offset-colnames
>         (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:

--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---

and as =org-table-convert-region= can't convert fixed positioned fields
(when SPC are used instead of TAB):

--8<---------------cut here---------------start------------->8---
(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.
--8<---------------cut here---------------end--------------->8---

Should that function be smarter, or do I still need pre-processing, then?

Thanks for your comments...

Best regards,
  Seb

-- 
Sébastien Vauban




reply via email to

[Prev in Thread] Current Thread [Next in Thread]