Re: org-babel-load-file support elisp

[Troy Hinckley]

Wow. Thanks for the quick resolution!
On Feb 12, 2020, 2:42 PM -0700, Bastien , wrote:
> Hi Troy,
>
> Troy Hinckley  writes:
>
> > I tracked down an issue trying to load a literate config file.
> > org-babel-load-file calls org-babel-tangle-file with lang set to
> > "emacs-lisp". This means that it won't tangle any blocks with
> > language set to "elisp", which is equivalent.
>
> This is now fixed in master, will be in Org 9.4.
>
> --
> Bastien

Re: org-babel-load-file support elisp

[Troy Hinckley]

 > I think supporting "#+begin_src elisp" would be confusing

elisp is already supported in all other babel
functions. org-babel-load-file is the only function that makes a
distinction as far as I can tell. And since that function is outlier it
makes sense to document this limitation in its docstring.

Or even better would be to detect if the user had elisp blocks and throw
and error. Though I am not sure how to do that outside of seeing if
tangling elisp is successful.

-Troy Hinckley

On Feb 3, 2020, 12:23 PM -0700, Bastien , wrote:

Hi Troy,

I tracked down an issue trying to load a literate config file.
org-babel-load-file calls org-babel-tangle-file with lang set to
"emacs-lisp". This means that it won't tangle any blocks with
language set to "elisp", which is equivalent. I can't think of an
easy way to fix this since you would need to target both languages.
Maybe at very least we could add something to the doc string to draw
attention to this limitation.


I think supporting "#+begin_src elisp" would be confusing but I agree
we could give a hint somewhere about this.

Can you suggest which docstring should be updated and how?

Thanks,

--
Bastien

org-babel-load-file support elisp

[Troy Hinckley]

I tracked down an issue trying to load a literate config file.
org-babel-load-file calls org-babel-tangle-file with lang set to
"emacs-lisp". This means that it won't tangle any blocks with language set
to "elisp", which is equivalent. I can't think of an easy way to fix this
since you would need to target both languages. Maybe at very least we could
add something to the doc string to draw attention to this limitation.