emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] C++ is not accepted for SRC block evaluation


From: Nicolas Goaziou
Subject: Re: [O] C++ is not accepted for SRC block evaluation
Date: Wed, 30 May 2018 13:11:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hello,

Aaron Ecay <address@hidden> writes:

> Improved documentation is never a bad thing.  OTOH, I personally would
> not spend time on implementing the mapping you propose.

I simply added a footnote about C++ and D languages.

> org-babel-do-load-languages is IMO a relic.  I think that all babel
> languages should be autoloaded, just like normal lisp libraries are.

But we still need a mechanism to selectively allow evaluation of some
source blocks based on their language. I guess some users expect to have
this.

Otherwise, it sounds good.

> If I had to sketch a design for this, it would be a macro like:
>
> (org-babel-define-language R
>   :evaluate org-babel-R-evaluate
>   :session org-babel-R-creaete-session
>   :language-name "R"              ;; Both these Could be optional, with the
>   :language-mode R-mode           ;; default calculated from the language name
>   ...)
>
> This macro would expand to:
>
> (add-to-list org-src-lang-modes ...)
> (add-to-list org-babel-tangle-lang-exts ...)
> ;; Possibly some others ...
> (add-to-list org-babel-languages-alist
>              '(R . (evaluate . org-babel-R-evaluate)
>                    (session . org-babel-R-create-session)
>                    ...))

On the implementation side of things, I suggest to stay away from macros
whenever possible. It would make sense, however, to define a language as
a defstruct, much like we do for export back-ends.

In any case, I like this idea.

> Iʼve held back on implementing this (among other reasons) because it
> would be a big disruption to the babel ecosystem.  For all the languages
> in core and contrib it would be manageable, but there are third-party
> libraries that would have to be transitioned as well, plus the growing
> pains of user config files, etc.  It would not be a small project.

This change would entail a new major release, indeed. I think it is
largely worth the incompatible changes it would introduce. BTW, we could
still support old variables and functions. E.g., if language Foo is not
defined as a proper defstruct, look for the old system to load it and
send a deprecation warning about it.

Regards,

-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]