* C++ is not accepted for SRC block evaluation @ 2018-05-26 12:15 Van L 2018-05-26 14:50 ` John Kitchin 0 siblings, 1 reply; 9+ messages in thread From: Van L @ 2018-05-26 12:15 UTC (permalink / raw) To: emacs-orgmode Hello. The `m-x customize’ path to `org-babel-load-languages’ or the following method won’t accept C++. #+BEGIN_SRC elisp :results none (org-babel-do-load-languages 'org-babel-load-languages '((C++ . t))) #+END_SRC The messages buffer has the following. executing Elisp code block... org-babel-do-load-languages: Cannot open load file: No such file or directory, ob-C++ M-x org-version Org mode version 9.1.9 M-x emacs-version GNU Emacs 26.1 rc1 Section 14.7 Languages in the Org Mode working with source code infopages lists C++. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-26 12:15 C++ is not accepted for SRC block evaluation Van L @ 2018-05-26 14:50 ` John Kitchin 2018-05-27 2:50 ` Van L 0 siblings, 1 reply; 9+ messages in thread From: John Kitchin @ 2018-05-26 14:50 UTC (permalink / raw) To: Van L; +Cc: org-mode-email [-- Attachment #1: Type: text/plain, Size: 1007 bytes --] It should be (C . t) it looks like ob-C also handles C++. John ----------------------------------- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sat, May 26, 2018 at 5:15 AM, Van L <van@scratch.space> wrote: > Hello. > > The `m-x customize’ path to `org-babel-load-languages’ or the following > method won’t accept C++. > > #+BEGIN_SRC elisp :results none > (org-babel-do-load-languages > 'org-babel-load-languages > '((C++ . t))) > #+END_SRC > > The messages buffer has the following. > > executing Elisp code block... > org-babel-do-load-languages: Cannot open load file: No such file or > directory, ob-C++ > > M-x org-version > Org mode version 9.1.9 > > M-x emacs-version > GNU Emacs 26.1 > rc1 > > Section 14.7 Languages in the Org Mode working with source code infopages > lists C++. > [-- Attachment #2: Type: text/html, Size: 2852 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-26 14:50 ` John Kitchin @ 2018-05-27 2:50 ` Van L 2018-05-27 20:24 ` Nicolas Goaziou 0 siblings, 1 reply; 9+ messages in thread From: Van L @ 2018-05-27 2:50 UTC (permalink / raw) To: John Kitchin; +Cc: org-mode-email > John Kitchin writes: > > It should be (C . t) > > it looks like ob-C also handles C++. > Section 14.7 Languages in the Org Mode working with source code infopages lists C++. Thanks. How about the following to update the documentation: #+BEGIN_EXAMPLE diff --git a/doc/misc/org.texi b/doc/misc/org.texi index cf1c037..7b00f0a 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -15522,7 +15522,8 @@ Languages @multitable @columnfractions 0.25 0.25 0.25 0.25 @headitem @b{Language} @tab @b{Identifier} @tab @b{Language} @tab @b{Identifier} @item Asymptote @tab asymptote @tab Awk @tab awk -@item C @tab C @tab C++ @tab C++ +@c @item C @tab C @tab C++ @tab C++ +@item C++ @tab C @tab C @tab C @item Clojure @tab clojure @tab CSS @tab css @item D @tab d @tab ditaa @tab ditaa @item Graphviz @tab dot @tab Emacs Calc @tab calc #+END_EXAMPLE Combining C/C++ to C in one field frees up a slot for Texinfo, texi. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-27 2:50 ` Van L @ 2018-05-27 20:24 ` Nicolas Goaziou 2018-05-27 20:48 ` Aaron Ecay 0 siblings, 1 reply; 9+ messages in thread From: Nicolas Goaziou @ 2018-05-27 20:24 UTC (permalink / raw) To: Van L; +Cc: org-mode-email, John Kitchin Hello, Van L <van@scratch.space> writes: >> John Kitchin writes: >> >> It should be (C . t) >> >> it looks like ob-C also handles C++. > > How about the following to update the documentation: > > #+BEGIN_EXAMPLE > diff --git a/doc/misc/org.texi b/doc/misc/org.texi > index cf1c037..7b00f0a 100644 > --- a/doc/misc/org.texi > +++ b/doc/misc/org.texi > @@ -15522,7 +15522,8 @@ Languages > @multitable @columnfractions 0.25 0.25 0.25 0.25 > @headitem @b{Language} @tab @b{Identifier} @tab @b{Language} @tab @b{Identifier} > @item Asymptote @tab asymptote @tab Awk @tab awk > -@item C @tab C @tab C++ @tab C++ > +@c @item C @tab C @tab C++ @tab C++ > +@item C++ @tab C @tab C @tab C > @item Clojure @tab clojure @tab CSS @tab css > @item D @tab d @tab ditaa @tab ditaa > @item Graphviz @tab dot @tab Emacs Calc @tab calc > #+END_EXAMPLE No, that's not correct. It should be (C++ . t), but "ob-C.el" should provide "ob-C++" feature, too. I pushed a fix along those lines in master. Thank you. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-27 20:24 ` Nicolas Goaziou @ 2018-05-27 20:48 ` Aaron Ecay 2018-05-27 21:09 ` Nicolas Goaziou 0 siblings, 1 reply; 9+ messages in thread From: Aaron Ecay @ 2018-05-27 20:48 UTC (permalink / raw) To: Nicolas Goaziou, Van L; +Cc: org-mode-email, John Kitchin Hi Nicolas, 2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen: [...] > No, that's not correct. It should be (C++ . t), but "ob-C.el" should > provide "ob-C++" feature, too. 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... -- Aaron Ecay ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-27 20:48 ` Aaron Ecay @ 2018-05-27 21:09 ` Nicolas Goaziou 2018-05-28 15:57 ` Aaron Ecay 0 siblings, 1 reply; 9+ messages in thread From: Nicolas Goaziou @ 2018-05-27 21:09 UTC (permalink / raw) To: Van L; +Cc: org-mode-email, John Kitchin Aaron Ecay <aaronecay@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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-27 21:09 ` Nicolas Goaziou @ 2018-05-28 15:57 ` Aaron Ecay 2018-05-30 11:11 ` Nicolas Goaziou 0 siblings, 1 reply; 9+ messages in thread From: Aaron Ecay @ 2018-05-28 15:57 UTC (permalink / raw) To: Nicolas Goaziou, Van L; +Cc: org-mode-email, John Kitchin Hi Nicolas, 2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen: [...] > > 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? Improved documentation is never a bad thing. OTOH, I personally would not spend time on implementing the mapping you propose. org-babel-do-load-languages is IMO a relic. I think that all babel languages should be autoloaded, just like normal lisp libraries are. 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) ...)) The intent of the last one would be to get rid of all the (fboundp (intern (concat "org-babel-thingy:" language))) stuff. The org-babel-define-language call(s) in each ob-foo.el file would be marked as autoloads, so that the relevant alists would all be fully populated on emacs startup. org-babel-(do-)load-languages would disappear. 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. (OTOH, I see other benefits as well. In the longer term, it would be nice to solve the longstanding problems with e.g. the python backend by communicating with a jupyter kernel, rather than trying to drive a python repl attached to a pipe. A more manageable API for babel languages than (fboundp (intern "magic-name")) would probably make it easier to implement this.) ...in any case, the mapping that you propose is not an unreasonable idea in the abstract. But the problem only arises (AFAIK) for the C++/D languages, and itʼs been with us for a long time. My own opinion is that we can just document and live with the situation until something much better comes along. But I also donʼt want to stop you from implementing a small and reasonable fix if you are motivated to do so. :) -- Aaron Ecay ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-28 15:57 ` Aaron Ecay @ 2018-05-30 11:11 ` Nicolas Goaziou 2018-05-30 16:35 ` Berry, Charles 0 siblings, 1 reply; 9+ messages in thread From: Nicolas Goaziou @ 2018-05-30 11:11 UTC (permalink / raw) To: Van L; +Cc: org-mode-email, John Kitchin Hello, Aaron Ecay <aaronecay@gmail.com> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation 2018-05-30 11:11 ` Nicolas Goaziou @ 2018-05-30 16:35 ` Berry, Charles 0 siblings, 0 replies; 9+ messages in thread From: Berry, Charles @ 2018-05-30 16:35 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Van L, org-mode-email, John Kitchin > On May 30, 2018, at 4:11 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > > Hello, > > Aaron Ecay <aaronecay@gmail.com> 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: >> It would be nice to have a concurrent update to template.el for this scheme. https://code.orgmode.org/bzg/worg/raw/master/org-contrib/babel/ob-template.el Chuck ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-05-30 16:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-26 12:15 C++ is not accepted for SRC block evaluation Van L 2018-05-26 14:50 ` John Kitchin 2018-05-27 2:50 ` Van L 2018-05-27 20:24 ` Nicolas Goaziou 2018-05-27 20:48 ` Aaron Ecay 2018-05-27 21:09 ` Nicolas Goaziou 2018-05-28 15:57 ` Aaron Ecay 2018-05-30 11:11 ` Nicolas Goaziou 2018-05-30 16:35 ` Berry, Charles
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).