• State "DONE" from "TODO" 2010-03-26 Fri 20:54
• State "TODO" from "TODO" 2010-01-18 Mon 13:39
• State "TODO" from "" 2009-12-31 Thu 12:57

simple fix, we just sort the language names by length, that way the longer names will be tried first and the shorter names won't have a chance to overshadow them.

(setq org-babel-interpreters
      (sort (cons interpreter org-babel-interpreters)
            (lambda (left right)
              (> (length left) (length right)))))

DED: I think this requires tightening up of org-babel-src-block-regexp, so that the language identifiers have appropriate delimiters around them.

Thanks to Daniel Doherty for submitting the following report

I'm not on this mailing list, but thought this would be the right place to pass along a bug in org-babek that had me baffled for a long time.

I was initializing org-babel with the following from my init.el file

(require 'org-babel-init)
(require 'org-babel-ruby)
(require 'org-babel-R)
(require 'org-babel-python)
(org-babel-load-library-of-babel)

When executing a ruby src block, I would get an error saying that the "r" language was not a babel-interpreter.

When I change the order of the language initializations, the error goes away:

(require 'org-babel-init)
(require 'org-babel-R)
(require 'org-babel-ruby)
(require 'org-babel-python)
(org-babel-load-library-of-babel)

Now, ruby is recognized.  Looks like the function for parsing the src block is seeing the 'r' in ruby and stopping because 'R" is a valid language, but then choking when it tries to run 'r'.