Re: [Orgmode] Re: [babel] ledger tutorial on Worg

[Eric Schulte]

Hi Seb,

Sébastien Vauban <address@hidden> writes:

> Hi Eric,
>
> "Eric Schulte" wrote:
>> Sébastien Vauban <address@hidden> writes:
>>
>>> Hi Eric(s),
>>>
>>
>> Hi Seb,
>>
>> [...]
>>>
>>> 1. I find it weird to have all the parameters of =:cmdline= not enclosed
>>>    between quotes. What should be the best option, here?  That was a 
>>> subject,
>>>    long ago, on Org-Babel: to quote or not to quote...
>>>
>>
>> I don't know that this was ever explicitly discussed, I believe that the
>> no-quoting behavior may have simply fallen out of the initial
>> implementation.  I'd certainly like to hear other people's opinions on
>> this, but I've personally enjoyed not having to place quotes in every
>> instance.
>
> In december 2009, I wrote:
>
>     "I'm a bit confused (as you may have seen in my last posts) about when we
>     do have to quote strings and when we do have to avoid doing it. Would you
>     have a one-liner explanation about when we have to use quotes?"
>
> See http://www.mail-archive.com/address@hidden/msg20265.html for
> contextual information.
>
> I remembered "you" (Dan or you) answered it somehow, but it must have been
> (around that same period) in another thread. Though, I don't find pointers
> anymore...
>
> Question is more: is it clear to mix parameters names (such as =:cmdline=) and
> long values which are unquoted (such as =registry unknown credit-card= and
> many much more options)?
>
> Shouldn't we properly begin and end where the given value is?
>

Through extensive person use I've not run into any instances where the
lack of quotes has actually caused a problem, or where there has been a
valid combination of header arguments which could not be successfully
parsed.  Without such an example I don't find it motivating to require
quotes.

>
>
>>> 2. When the evaluation produces no output, but had well produced output
>>>    before, shouldn't Babel have to delete the previously written results in
>>>    the Org buffer?
>>
>> This is a good point. Currently Babel just quits if it receives a nil
>> result, but I think you're right that we should replace existing results
>> when a nil result has been returned. I'll add this as PROPOSED to the babel
>> task list.
>
> I consider this kind of mandatory, for the sake of coherency, and to really
> make use of Org-babel every time I want to run some shell commands (and change
> them, eventually getting no results then).
>

I've just pushed up a change that implements this behavior.

>
> Thanks a lot for everything you did and do for us.
>

My pleasure -- Eric

>
> Best regards,
>   Seb