Hi Daniele,
Daniele Pizzolli writes:
> On 2014-11-24 12:12, Daniele Pizzolli wrote:
>> On 2014-11-24 11:18, Andreas Leha wrote:
>>> Hi Daniele,
>>>
>>> I think your wishlist is somewhere further down the road. I usually
>>> implement some of your points in the src_language. I see that it
>>>
On 2014-11-24 12:12, Daniele Pizzolli wrote:
On 2014-11-24 11:18, Andreas Leha wrote:
Hi Daniele,
I think your wishlist is somewhere further down the road. I usually
implement some of your points in the src_language. I see that it
would
be nice if org supported these use cases, but I would
On 2014-11-24 11:18, Andreas Leha wrote:
Hi Daniele,
I think your wishlist is somewhere further down the road. I usually
implement some of your points in the src_language. I see that it would
be nice if org supported these use cases, but I would see them as part
of the LOB or maybe in some pac
Hi Daniele,
I think your wishlist is somewhere further down the road. I usually
implement some of your points in the src_language. I see that it would
be nice if org supported these use cases, but I would see them as part
of the LOB or maybe in some package in contrib rather than in core
org/bab
On 2014-11-17 00:23, Nicolas Goaziou wrote:
"Charles C. Berry" writes:
For now, I'd be willing to make patches that will allow removal of the
inline src block results that do *not* involve these header args:
[]
IMO, we're too much focused on the implementation details. We ought to
agree on
"Charles C. Berry" writes:
> For now, I'd be willing to make patches that will allow removal of the
> inline src block results that do *not* involve these header args:
>
> - :file
> - :wrap
> - :results latex html drawer org code
>
> which I can do barely touching `org-babel-insert-result' and
Hello,
Aaron Ecay writes:
> This is a step back from the present situation, where a user can get
> a custom format applied by default to all inline results by setting
> ‘org-babel-inline-result-wrap’. I think it’s reasonable for users to
> want to set off babel results in a special font (to ind
On Fri, 14 Nov 2014, Nicolas Goaziou wrote:
"Charles C. Berry" writes:
More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
are patched.
Thanks.
[skipping to the bottom - omitting useful critiques of code and
opinions about strategy and tactics from Nicolas]
WDYT?
Aft
Hi Chuck, Hi Nicolas,
I had a response to Chuck’s earlier message that was sitting around
waiting to be finished...time marches on however. Apologies. I think
the following bit is the only part that’s potentially still relevant:
>
> I don't think the usual #+MACRO works here, as the definition
"Charles C. Berry" writes:
> More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
> are patched.
Thanks.
> Also, the user can customize org-babel-inline-result-wrap to always
> get verbatim or otherwise wrap the contents of the macro.
I don't think this is a good idea.
If we re
Nicolas,
More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el are
patched.
A few examples of how they render various src_[headers]{code} setups
are also attached.
Discussion inline below.
On Thu, 13 Nov 2014, Nicolas Goaziou wrote:
Hello,
"Charles C. Berry" writes:
I
Hi,
Nicolas Goaziou writes:
> Hello,
>
> "Charles C. Berry" writes:
>
>> I like the flexibility that macros would allow.
>
> I like it too. Macros are much better than export snippets for the task.
>
>> I don't think the usual #+MACRO works here, as the definition would be
>> found in `org-macro
Hello,
"Charles C. Berry" writes:
> I like the flexibility that macros would allow.
I like it too. Macros are much better than export snippets for the task.
> I don't think the usual #+MACRO works here, as the definition would be
> found in `org-macro-templates' by the first call and existing
On Wed, 12 Nov 2014, Aaron Ecay wrote:
Hi Chuck,
2014ko azaroak 12an, "Charles C. Berry"-ek idatzi zuen:
Inline src blocks cannot update their results --- causing some of us
heaadaches [1].
These patches fix that by placing the result of an inline src block in an
export snippet with a faux :
Hi Chuck,
2014ko azaroak 12an, "Charles C. Berry"-ek idatzi zuen:
>
> Inline src blocks cannot update their results --- causing some of us
> heaadaches [1].
>
> These patches fix that by placing the result of an inline src block in an
> export snippet with a faux :back-end called 'babel'.
>
>
On Wed, 12 Nov 2014, Andreas Leha wrote:
Hi Chuck,
"Charles C. Berry" writes:
Inline src blocks cannot update their results --- causing some of us
heaadaches [1].
[deleted announcement of fix]
First of all: Thanks a lot! I'll (try to find time to) test these
patches.
Yes. Please try
Hi Chuck,
"Charles C. Berry" writes:
> Inline src blocks cannot update their results --- causing some of us
> heaadaches [1].
>
> These patches fix that by placing the result of an inline src block in
> an export snippet with a faux :back-end called 'babel'.
>
> So C-c C-c with point on src_R{1+2
Inline src blocks cannot update their results --- causing some of us
heaadaches [1].
These patches fix that by placing the result of an inline src block in an
export snippet with a faux :back-end called 'babel'.
So C-c C-c with point on src_R{1+2} will insert `@@babel:3@@'. Updating
the co
18 matches
Mail list logo
