emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nick Dokos <ndokos@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Bug: Proposed new version of ob-C.el [8.3beta (release_8.3beta-944-g830cf3 @ /Users/snapp/.emacs.d/vendor/org/)]
Date: Tue, 31 Mar 2015 18:14:59 -0400	[thread overview]
Message-ID: <87ego46cgs.fsf@alphaville.usersys.redhat.com> (raw)
In-Reply-To: 551AFB1A.9020504@free.fr

Thierry Banel <tbanelwebmin@free.fr> writes:

> Le 31/03/2015 12:07, Nicolas Goaziou a écrit :
>>> IMO, it would be better than the current situation, but I wonder if
>>> it makes sense to have a global default setting containing the
>>> three files, but one which the user can customize; any :includes
>>> parameters would augment the default.
>>> That would satisfy the OP's requirements, but would also allow for
>>> a shorter #+BEGIN_SRC line.
>> I think this suggestion makes sense. While you're at it, would you mind
>> implementing it?
> Well, actually the global default setting feature may already be available
>   1) through properties in drawers
>   2) through the org-babel-default-header-args global variable
> * Property in drawer
>   :includes: <stdio.h> <myheader.h>
>   :END:
> Any C++ babel block below this tree will inherit the <stdio.h> and
> <myheader.h>#includes
> * The org-babel-default-header-argsvariable
> This variable holds global defaults. For C++ do something like that:
> (add-to-list 'org-babel-default-header-args '(:includes  "<stdio.h>"
> "<myheader.h>"))
> Any babel C++ block anywhere will inherit from the global variable.
> Nick, are those the kinds of settings you were thinking about?

I was thinking of an ob-C.el customizable variable that is set by
default to some useful list of includes, not file-settable things.
But I'm probably the last person you should ask about what is useful
here. Real users should speak up.

> The "augment" feature may be missing though:
> local :includes overwrite global ones.

I think augmentation might be nice, but if people are willing to live
with replacement, I'm not going to argue. And if augmentation carries
the day, there always is the vexing question of what to do when you
really *want* replacement, not augmentation.


  reply	other threads:[~2015-03-31 22:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25  2:28 Bug: Proposed new version of ob-C.el [8.3beta (release_8.3beta-944-g830cf3 @ /Users/snapp/.emacs.d/vendor/org/)] Robert Snapp
2015-03-29 20:48 ` Thierry Banel
2015-03-30 14:39   ` Nick Dokos
2015-03-30 19:53     ` Thierry Banel
2015-03-31 10:07       ` Nicolas Goaziou
2015-03-31 19:52         ` Thierry Banel
2015-03-31 22:14           ` Nick Dokos [this message]
2015-04-02 21:30             ` Thierry Banel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ego46cgs.fsf@alphaville.usersys.redhat.com \
    --to=ndokos@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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