Aaron Ecay <aarone...@gmail.com> writes: > Is this right? Even if the feature is provide-d by the file, the require > in org-babel-do-load-languages will not find it (because the file name > does not match). C++ is not a valid choice for the variable AFAICT. The > customize interface makes that clear by not offering it as an option, but > if the variable is customized outside of customize (so to speak...) chaos > reigns...
You are right, the change is not sufficient, although it doesn't make things worse. We could modify `org-babel-load-languages' defcustom and add lines: (const :tag "C++" C) (const :tag "D" C) which would do the job from Customize, but not for a user changing the variable outside it, as you point out. We probably need to implement a mapping between languages symbols and files and use it in `org-babel-do-load-languages'. The implicit mapping it uses currently has shortcomings. We could also leave it like this (even with my patch reverted), and document it somehow. Maybe a third column per language in (info "(org) Languages") to hold the file name. WDYT?
