Re: [O] [babel] Specified colnames

[Sebastien Vauban]

Eric,

Eric Schulte wrote:
>> Here the patch you asked for.
>
> I've applied this patch.

Thanks a lot for reviewing my test, and fixing it!

> Please review the changes I had to make for it to work correctly. Your
> version wasn't working because when org-babel-execute-src-block was called
> the point was not inside of the code block.

Isn't there something to fix, in order to avoid an uncontrolled error to be
generated, such as the one I had?

> My changes search forward in the text to place the point at the beginning of
> the code block before executing.

OK!

> I also had to uppercase RESULTS for the string equality to return true.

OK. That's true I've set:

--8<---------------cut here---------------start------------->8---
  ;; keep lower-case
  (setq org-babel-results-keyword "results")
--8<---------------cut here---------------end--------------->8---

since we've got nice keyword fontification -- as Carsten once said, he only
choose uppercase keywords, a while ago, when it was much more difficult to
clearly view the distinction between text, code and results (before the nice
fontification we now have). Otherwise, he'd have chosen lower-case keywords.

Because of that feature, which I completely had out of my mind, I'm thinking
at another thing that could help reduce the size of the tests. Currently, we
copy once the code block, and once the code block + its results.

Maybe we could have a function to locate (via a regexp for
#+results/#+RESULTS) the results, and only check (for strict or loose
equality [1]) on the results.

So, something along those lines:

--8<---------------cut here---------------start------------->8---
(should
 (equal (results-part (org-babel-execute-src-block "code block only"))
        "results only"))
--8<---------------cut here---------------end--------------->8---

No duplication of the input...

Does this make sense?

> In the future more flexible tests (such as regular expression searches)
> rather than strict equality should be preferable.
>
> Thanks for contributing this test!

My pleasure.

Best regards,
  Seb

[1] Regexp match

-- 
Sebastien Vauban