emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Org-Babel and Ledger
@ 2010-07-29  9:40 Sébastien Vauban
  2010-07-29 16:33 ` Eric Abrahamsen
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Vauban @ 2010-07-29  9:40 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hello,

I'm trying to really begin working with Ledger for my personal accounting.
Of course, trying to do it with as much Org as possible...

Though, results of 3 small requests (whose results is snipped, for brievety)
is the following:

--8<---------------cut here---------------start------------->8---
#+TITLE:     Scorpios-Ledger
#+LANGUAGE:  en_US

* Balance

#+srcname: bal
#+begin_src sh
ledger -f scorpios-ledger.dat bal
#+end_src

#+results: bal
|             -1117.47 | EUR | Assets:Bank             |
|              1036.15 | EUR | Checking:FR04304429459  |
|              -631.62 | EUR | Savings:FR00307599427   |
|              -1522.0 | EUR | Transferred             |
|             -2036.52 | EUR | Expenses                |
|                20.25 | EUR | Bank:Charges            |
|               175.09 | EUR | Insurance:House         |
|              -2838.1 | EUR | Unknown                 |
|               606.24 | EUR | Utilities:Electricity   |
|              3153.99 | EUR | Liabilities:Loans:Cecaz |
| -------------------- |     |                         |
|                 -0.0 | EUR |                         |

* Registry

#+srcname: reg
#+begin_src sh
ledger -f scorpios-ledger.dat reg unknown
#+end_src

#+results: reg
| 2009/08/21 | CHEQUE   | :           | 9953055          | Expenses:Unknown | 166.7            |              EUR | 166.7    |      EUR |          |     |
| 2009/09/17 | CHEQUE   | :           | 7691785          | Expenses:Unknown | 100.0            |              EUR | 266.7    |      EUR |          |     |
| 2009/10/16 | REMISE   | CHEQUE      | N                | 86..             | Expenses:Unknown |           -525.0 | EUR      |   -258.3 | EUR      |     |
| 2009/11/06 | CHEQUE   | :           | 7691786          | Expenses:Unknown | 192.0            |              EUR | -66.3    |      EUR |          |     |
| 2009/11/24 | CHEQUE   | :           | 7691787          | Expenses:Unknown | 833.0            |              EUR | 766.7    |      EUR |          |     |
| 2009/11/25 | REMISE   | CHEQUE      | N                | 92..             | Expenses:Unknown |           -970.0 | EUR      |   -203.3 | EUR      |     |
| 2009/12/31 | INTERETS | CAPITALISES | Expenses:Unknown | -8.48            | EUR              |          -211.78 | EUR      |          |          |     |
| 2010/01/05 | CHEQUE   | :           | 7691789          | Expenses:Unknown | 733.0            |              EUR | 521.22   |      EUR |          |     |
| 2010/01/05 | REMISE   | CHEQUE      | N                | 93..             | Expenses:Unknown |           -525.0 | EUR      |    -3.78 | EUR      |     |
| 2010/01/14 | REMISE   | CHEQUE      | N                | 98..             | Expenses:Unknown |           -525.0 | EUR      |  -528.78 | EUR      |     |
| 2010/01/16 | FRAIS    | PRELEVEMENT | ..               | Expenses:Unknown | 10.73            |              EUR | -518.05  |      EUR |          |     |

* Reporting monthly expenses

#+srcname: monthly-exp
#+begin_src sh
ledger -f scorpios-ledger.dat -M reg ^expenses
#+end_src

#+results: monthly-exp
| 2009/08/01         |        0 | 2009/08/31 | Expenses:Bank:Charges | 3.05  | EUR |     3.05 | EUR |
| Expenses:Unknown   |    166.7 | EUR        |                169.75 | EUR   |     |          |     |
| 2009/09/01         |        0 | 2009/09/30 | Expenses:Bank:Charges | 1.1   | EUR |   170.85 | EUR |
| Ex:Insurance:House |     15.9 | EUR        |                186.75 | EUR   |     |          |     |
| Expenses:Unknown   |    100.0 | EUR        |                286.75 | EUR   |     |          |     |
| 2009/10/01         |        0 | 2009/10/31 | Expenses:Bank:Charges | 5.85  | EUR |    292.6 | EUR |
| Ex:Insurance:House |     15.9 | EUR        |                 308.5 | EUR   |     |          |     |
| Expenses:Unknown   |   -525.0 | EUR        |                -216.5 | EUR   |     |          |     |
| Ex:Ut:Electricity  |    28.38 | EUR        |               -188.12 | EUR   |     |          |     |
| 2009/11/01         |        0 | 2009/11/30 | Expenses:Bank:Charges | 1.1   | EUR |  -187.02 | EUR |
| Ex:Insurance:House |     15.9 | EUR        |               -171.12 | EUR   |     |          |     |
| Expenses:Unknown   |     55.0 | EUR        |               -116.12 | EUR   |     |          |     |
--8<---------------cut here---------------end--------------->8---

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...)

- Other ideas?

Do you have suggestions about the best way to go?

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Org-Babel and Ledger
  2010-07-29  9:40 Org-Babel and Ledger Sébastien Vauban
@ 2010-07-29 16:33 ` Eric Abrahamsen
  2010-07-30 20:47   ` Eric Schulte
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Abrahamsen @ 2010-07-29 16:33 UTC (permalink / raw)
  To: emacs-orgmode

On Thu, Jul 29 2010, Sébastien Vauban wrote:


[...]

>
> 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...)
>
> - Other ideas?

 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.

Eric

>
> Do you have suggestions about the best way to go?
>
> Best regards,
>   Seb

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Re: Org-Babel and Ledger
  2010-07-29 16:33 ` Eric Abrahamsen
@ 2010-07-30 20:47   ` Eric Schulte
  2010-08-12 11:45     ` Sébastien Vauban
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Schulte @ 2010-07-30 20:47 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

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).

--8<---------------cut here---------------start------------->8---
(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))
	(org-babel-sqlite-table-or-scalar
	 (org-babel-sqlite-offset-colnames
	  (org-table-to-lisp) headers-p)))
--8<---------------cut here---------------end--------------->8---

I would recommend this approach over shell-script post-processing.

Best -- Eric

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On Thu, Jul 29 2010, Sébastien Vauban wrote:
>
>
> [...]
>
>>
>> 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...)
>>
>> - Other ideas?
>
>  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.
>
> Eric
>
>>
>> Do you have suggestions about the best way to go?
>>
>> Best regards,
>>   Seb
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Org-Babel and Ledger
  2010-07-30 20:47   ` Eric Schulte
@ 2010-08-12 11:45     ` Sébastien Vauban
  2010-08-12 22:57       ` Eric Schulte
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Vauban @ 2010-08-12 11:45 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

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


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Re: Org-Babel and Ledger
  2010-08-12 11:45     ` Sébastien Vauban
@ 2010-08-12 22:57       ` Eric Schulte
  2010-08-13  9:23         ` Sébastien Vauban
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Schulte @ 2010-08-12 22:57 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

Hi Seb,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> 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
>>>> 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:
>
> 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.

--8<---------------cut here---------------start------------->8---
#+results: ledger-output
#+begin_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
#+end_example

#+begin_src emacs-lisp :var ledger=ledger-output
  (with-temp-buffer
    (insert ledger)
    (message ledger)
    (org-table-convert-region (point-min) (point-max) 2)
    (org-table-to-lisp))
#+end_src

#+results:
| 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---

Hope this helps -- Eric

>
> Thanks for your comments...
>
> Best regards,
>   Seb

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Org-Babel and Ledger
  2010-08-12 22:57       ` Eric Schulte
@ 2010-08-13  9:23         ` Sébastien Vauban
  2010-08-13 11:33           ` Sébastien Vauban
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Vauban @ 2010-08-13  9:23 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>>>>> 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
>>>
>>> 	(org-table-convert-region (point-min) (point-max))
>>>
>>> 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.
>
> #+results: ledger-output
> #+begin_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
> #+end_example
>
> #+begin_src emacs-lisp :var ledger=ledger-output
>   (with-temp-buffer
>     (insert ledger)
>     (message ledger)
>     (org-table-convert-region (point-min) (point-max) 2)
>     (org-table-to-lisp))
> #+end_src
>
> #+results:
> | 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

Of course, it does, Eric!

I misunderstood the above DOCSTRING because, IMHO, it's not that clear:

"When a number, use that many spaces as field separator" meant, for me, that
if using the number 2 (as you do), it would consider a new field every 2
consecutive spaces, and leave me with a lot of empty fields...

In fact, it should be written "consider any amount of whitespaces (above the
given number) as a field separator" or something like that, if you understand
me right.

I was blocked on the fact that every 2 spaces would be a new field separator,
and not every string of 2 or more spaces...

Thanks a lot (once again)!!

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Org-Babel and Ledger
  2010-08-13  9:23         ` Sébastien Vauban
@ 2010-08-13 11:33           ` Sébastien Vauban
  2010-08-13 17:41             ` Eric Schulte
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Vauban @ 2010-08-13 11:33 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

Sébastien Vauban wrote:
> "Eric Schulte" wrote:
>> Sébastien Vauban writes:
>>>
>>>>>> 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
>>>>
>>>> 	(org-table-convert-region (point-min) (point-max))

As you adviced, I can play with the optional parameter in ob-ledger's code.

But what about the results of sh code?

Imagine now that I'm forced to use =sh= instead of =ledger=, in the following
pratical case:

#+srcname: reg
#+begin_src sh
m4 scorpios-ledger.dat | ledger -f - reg unknown
#+end_src

I'm using =m4= (and thus make some pre-processing) because I need (or want) to
be able to switch between =ledger= and =hledger= and comment in or out the
directives that are accepted by one but not by the other.

Then, such a result is still problematic:

--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---

I've looked in =org-babel-execute:sh= and =org-babel-reassemble-table=, among
others, to look for similar constructs (calls to =org-table-convert-region=)
but did not find any.

Is there still a solution to get such results?

--8<---------------cut here---------------start------------->8---
#+results:
| 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---

Couldn't we specify somehow the field separator as an extra header argument?
I've looked for such an already existing in
http://orgmode.org/manual/Specific-header-arguments.html#Specific-header-arguments,
but that does not seem to be available yet. Though, I do not know if this is
the right solution. I'm sure you'll tell me... ;-)

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Re: Org-Babel and Ledger
  2010-08-13 11:33           ` Sébastien Vauban
@ 2010-08-13 17:41             ` Eric Schulte
  2010-08-13 19:04               ` Sébastien Vauban
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Schulte @ 2010-08-13 17:41 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

Hi Seb,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> Sébastien Vauban wrote:
>> "Eric Schulte" wrote:
>>> Sébastien Vauban writes:
>>>>
>>>>>>> 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

This might actually be a good solution for the shell block you mention
below.

>>>>>
>>>>> 	(org-table-convert-region (point-min) (point-max))
>
> As you adviced, I can play with the optional parameter in ob-ledger's code.
>
> But what about the results of sh code?
>
> Imagine now that I'm forced to use =sh= instead of =ledger=, in the following
> pratical case:
>
> #+srcname: reg
> #+begin_src sh
> m4 scorpios-ledger.dat | ledger -f - reg unknown
> #+end_src
>
> I'm using =m4= (and thus make some pre-processing) because I need (or want) to
> be able to switch between =ledger= and =hledger= and comment in or out the
> directives that are accepted by one but not by the other.
>
> Then, such a result is still problematic:
>
> 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
>
> I've looked in =org-babel-execute:sh= and =org-babel-reassemble-table=, among
> others, to look for similar constructs (calls to =org-table-convert-region=)
> but did not find any.
>
> Is there still a solution to get such results?
>

As an interim solution you could add a :results scalar header argument
to your sh code block, then pass the output of that code block to a
parsing code block (namely the one from my previous email).  That's
certainly not idea, but it should work for the moment.

Alternately if ledger supports a more clearly delimited output format
(e.g. csv) then that would probably work as well.

>
> #+results:
> | 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 |
>
> Couldn't we specify somehow the field separator as an extra header
> argument?  I've looked for such an already existing in
> http://orgmode.org/manual/Specific-header-arguments.html#Specific-header-arguments,
> but that does not seem to be available yet.

This would probably be a good addition to ob-sh (and any other language
which doesn't have a defined list syntax).  I'll add this idea to the
babel dev stack, but I'm swamped for the next week or so.

Best -- Eric

> Though, I do not know if this is the right solution. I'm sure you'll
> tell me... ;-)
>
> Best regards,
>   Seb

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Org-Babel and Ledger
  2010-08-13 17:41             ` Eric Schulte
@ 2010-08-13 19:04               ` Sébastien Vauban
  0 siblings, 0 replies; 9+ messages in thread
From: Sébastien Vauban @ 2010-08-13 19:04 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Sébastien Vauban wrote:
>>> "Eric Schulte" wrote:
>>>> Sébastien Vauban writes:
>>>>>
>>>>>>>> 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
>
> This might actually be a good solution for the shell block you mention
> below.
>
>>>>>>
>>>>>> 	(org-table-convert-region (point-min) (point-max))
>>
>> As you adviced, I can play with the optional parameter in ob-ledger's code.
>>
>> But what about the results of sh code?
>>
>> Imagine now that I'm forced to use =sh= instead of =ledger=, in the
>> following pratical case:
>>
>> #+srcname: reg
>> #+begin_src sh
>> m4 scorpios-ledger.dat | ledger -f - reg unknown
>> #+end_src
>>
>> I'm using =m4= (and thus make some pre-processing) because I need (or want)
>> to be able to switch between =ledger= and =hledger= and comment in or out
>> the directives that are accepted by one but not by the other.
>>
>> Then, such a result is still problematic:
>>
>> 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
>>
>> I've looked in =org-babel-execute:sh= and =org-babel-reassemble-table=,
>> among others, to look for similar constructs (calls to
>> =org-table-convert-region=) but did not find any.
>>
>> Is there still a solution to get such results?
>
> As an interim solution you could add a :results scalar header argument to
> your sh code block, then pass the output of that code block to a parsing
> code block (namely the one from my previous email). That's certainly not
> idea, but it should work for the moment.
>
> Alternately if ledger supports a more clearly delimited output format (e.g.
> csv) then that would probably work as well.
>
>> #+results:
>> | 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 |
>>
>> Couldn't we specify somehow the field separator as an extra header
>> argument? I've looked for such an already existing in
>> http://orgmode.org/manual/Specific-header-arguments.html#Specific-header-arguments,
>> but that does not seem to be available yet.
>
> This would probably be a good addition to ob-sh (and any other language
> which doesn't have a defined list syntax).

I'll have a deep look in the proposed direction.

> I'll add this idea to the babel dev stack, but I'm swamped for the next week
> or so.

If it's for holidays, enjoy it!  (and, accessorily, come back full of
energy ;-))

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2010-08-13 19:04 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-29  9:40 Org-Babel and Ledger Sébastien Vauban
2010-07-29 16:33 ` Eric Abrahamsen
2010-07-30 20:47   ` Eric Schulte
2010-08-12 11:45     ` Sébastien Vauban
2010-08-12 22:57       ` Eric Schulte
2010-08-13  9:23         ` Sébastien Vauban
2010-08-13 11:33           ` Sébastien Vauban
2010-08-13 17:41             ` Eric Schulte
2010-08-13 19:04               ` Sébastien Vauban

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).