emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* #+PROPERTY: header-args:C++ will not work
@ 2019-04-15 12:53 Alexandre Duret-Lutz
  2019-04-15 14:08 ` Alexandre Duret-Lutz
  0 siblings, 1 reply; 3+ messages in thread
From: Alexandre Duret-Lutz @ 2019-04-15 12:53 UTC (permalink / raw)
  To: emacs-orgmode

Hi,

I'm currently simplifying some documentation that evaluates a lot of
sh/python/C++ blocks by defining the :results and :exports flags
commonly used in header-args properties like so:

#+PROPERTY: header-args:sh :results verbatim :exports both
#+PROPERTY: header-args:python :results output :exports both
#+PROPERTY: header-args:C++ :results verbatim :exports both

Unfortunately, this does not work for C++ blocks.

Looking at the contents of org-file-properties in a file with the
above lines shows

org-file-properties is a variable defined in ‘org.el’.
Its value is
(("header-args:C+" . ":results verbatim :exports both")
 ("header-args:python" . ":results output :exports both")
 ("header-args:sh" . ":results verbatim :exports both"))

Note how C++ is truncated to C+.

The documentation states:

1. Language-specific header arguments are also read from properties
‘header-args:<LANG>’ where <LANG> is the language identifier.
(https://orgmode.org/manual/Using-Header-Arguments.html#Code-block-specific-header-arguments)

2. If you want to add to the value of an existing property, append a
‘+’ to the property name.
(https://orgmode.org/manual/Property-Syntax.html#Property-Syntax)

Unfortunately it seems statement 2 breaks statement 1 when LANG ends
with '+', and header-args:C++ is understood as appending
header-args:C+.

I currently work around this problem by using header-args:C+++
instead, but this only works assuming that property header-args:C++
has not been set by other means.

I there other way to assign (not append) some value to the header-args
property from the some org file?

-- 
Alexandre Duret-Lutz

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: #+PROPERTY: header-args:C++ will not work
  2019-04-15 12:53 #+PROPERTY: header-args:C++ will not work Alexandre Duret-Lutz
@ 2019-04-15 14:08 ` Alexandre Duret-Lutz
  2019-04-23  8:28   ` Nicolas Goaziou
  0 siblings, 1 reply; 3+ messages in thread
From: Alexandre Duret-Lutz @ 2019-04-15 14:08 UTC (permalink / raw)
  To: emacs-orgmode

On Mon, Apr 15, 2019 at 2:53 PM Alexandre Duret-Lutz <adl@lrde.epita.fr> wrote:
> Unfortunately, this does not work for C++ blocks.

I just noticed that I could change all my C++ blocks into cpp blocks and
then use header-args:cpp without any problem.  The org-mode manual
states that the identifier for the C++ language is "C++"
(https://orgmode.org/manual/Languages.html) but the same page links to
some babel documentation
(https://orgmode.org/worg/org-contrib/babel/languages.html)
where it is listed as "cpp".

ORG-NEWS has one example using C++, but the test suite only has cpp examples.

There is some hint on
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html#orgea7b004
that using cpp might not fully work (?).   And clearly while lisp/org-src.el has
many functions implemented for both cpp and C++, its not always complete.
For instance it defines org-babel-header-args:C++
but there is no org-babel-header-args:cpp, meaning incomplete completion for
cpp blocks header-args.

From all that it feels like the documentation wants us to use C++, and that
the code is trying to keep cpp for backward compatibility (?), but that each
option has different drawbacks.

I'll stick to C++ and header-args:C+++...

--
Alexandre Duret-Lutz

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: #+PROPERTY: header-args:C++ will not work
  2019-04-15 14:08 ` Alexandre Duret-Lutz
@ 2019-04-23  8:28   ` Nicolas Goaziou
  0 siblings, 0 replies; 3+ messages in thread
From: Nicolas Goaziou @ 2019-04-23  8:28 UTC (permalink / raw)
  To: Alexandre Duret-Lutz; +Cc: emacs-orgmode

Hello,

Alexandre Duret-Lutz <adl@lrde.epita.fr> writes:

> On Mon, Apr 15, 2019 at 2:53 PM Alexandre Duret-Lutz <adl@lrde.epita.fr> wrote:
>> Unfortunately, this does not work for C++ blocks.
>
> I just noticed that I could change all my C++ blocks into cpp blocks and
> then use header-args:cpp without any problem.  The org-mode manual
> states that the identifier for the C++ language is "C++"
> (https://orgmode.org/manual/Languages.html) but the same page links to
> some babel documentation
> (https://orgmode.org/worg/org-contrib/babel/languages.html)
> where it is listed as "cpp".
>
> ORG-NEWS has one example using C++, but the test suite only has cpp examples.
>
> There is some hint on
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html#orgea7b004
> that using cpp might not fully work (?).   And clearly while lisp/org-src.el has
> many functions implemented for both cpp and C++, its not always complete.
> For instance it defines org-babel-header-args:C++
> but there is no org-babel-header-args:cpp, meaning incomplete completion for
> cpp blocks header-args.
>
> From all that it feels like the documentation wants us to use C++, and that
> the code is trying to keep cpp for backward compatibility (?), but that each
> option has different drawbacks.
>
> I'll stick to C++ and header-args:C+++...

I think we should use enforce using cpp everywhere instead of C++, since
it is more consistent. Patches welcome, of course :)

Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-04-23  8:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-15 12:53 #+PROPERTY: header-args:C++ will not work Alexandre Duret-Lutz
2019-04-15 14:08 ` Alexandre Duret-Lutz
2019-04-23  8:28   ` Nicolas Goaziou

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).