Robert Klein writes:
> If you revert the second patch, please put a note in the release notes
> for the next org release, so the other babel users know a migration
> path.
I reverted the second patch, and slightly changed documentation. I'm not
sure about ORG NEWS as using data from a COMMENT su
Hi,
On 03/27/2015 12:02 PM, Nicolas Goaziou wrote:
> Andreas Leha writes:
>> I completely agree. My question was, what a use case would be that
>> requires a COMMENT that behaves different from #'ing the individual
>> lines (and is not covered by :noexport: already).
>
> I don't think there is
Hi Nicolas,
Nicolas Goaziou writes:
> Andreas Leha writes:
>
>> I see. I did not consider any possible slow-downs. I'd expect COMMENT
>> to behave exactly like # in every regard -- not only export. That is a
>> clearly defined behaviour, that should not produce confusion.
>
> As explained, th
Andreas Leha writes:
> I see. I did not consider any possible slow-downs. I'd expect COMMENT
> to behave exactly like # in every regard -- not only export. That is a
> clearly defined behaviour, that should not produce confusion.
As explained, this is not realistic.
> If COMMENT is only vali
Hi Nicolas,
Nicolas Goaziou writes:
> Andreas Leha writes:
>
>> FWIW, I agree that COMMENT should be equivalent to individual line # .
>
> I hope you mean it should be equivalent during export only. Otherwise,
> it would introduce some serious slowdown as COMMENT can be inherited.
>
I see. I d
Andreas Leha writes:
> FWIW, I agree that COMMENT should be equivalent to individual line # .
I hope you mean it should be equivalent during export only. Otherwise,
it would introduce some serious slowdown as COMMENT can be inherited.
> Sections that should be accessible without being exported
Sebastien Vauban
writes:
> Can't we say that a COMMENT'ed subtree is like having all of its
> contents commented, line by line? IOW, nothing "accessible"?
There is, at least, one problem. Comments are always comments (really).
However COMMENT keyword is only active during export. That means t
Hi all,
Sebastien Vauban writes:
> Robert Klein wrote:
>> On 03/24/2015 10:04 AM, Sebastien Vauban wrote:
>>
>>> Can't we say that a COMMENT'ed subtree is like having all of its
>>> contents commented, line by line? IOW, nothing "accessible"?
>>
>> This would probably break a lot of babel stuff.
Robert Klein wrote:
> On 03/24/2015 10:04 AM, Sebastien Vauban wrote:
>
>> Can't we say that a COMMENT'ed subtree is like having all of its
>> contents commented, line by line? IOW, nothing "accessible"?
>
> This would probably break a lot of babel stuff.
Could you elaborate why?
> If there was
Hi,
On 03/24/2015 10:04 AM, Sebastien Vauban wrote:
> Can't we say that a COMMENT'ed subtree is like having all of its
> contents commented, line by line? IOW, nothing "accessible"?
This would probably break a lot of babel stuff.
If there was an option to disable exports for #+NAME:-ed stuff (
Nicolas Goaziou wrote:
> Robert Klein writes:
>
>> this patch also breaks this kind of construct where not the table is
>> exported, but the one created from the booktabs() call:
>>
>>
>> ---> begin example <---
>> * Grundlagen
>> *** COMMENT unexported subtree with table source
>> #+tblname
Hello,
Robert Klein writes:
> this patch also breaks this kind of construct where not the table is
> exported, but the one created from the booktabs() call:
>
>
> ---> begin example <---
> * Grundlagen
> *** COMMENT unexported subtree with table source
> #+tblname: masse
This is deprecate
On 03/24/2015 12:36 AM, Nicolas Goaziou wrote:
> Hello,
>
> Andreas Leha writes:
>
>> If there are `#+latex_header:' entries in a section and that section is
>> `COMMENT'ed out, I'd expect the #+latex_header entries to be
>> uneffective. As they are when I comment them out one by one as in
>> `
Nicolas Goaziou writes:
> Hello,
>
> Andreas Leha writes:
>
>> If there are `#+latex_header:' entries in a section and that section is
>> `COMMENT'ed out, I'd expect the #+latex_header entries to be
>> uneffective. As they are when I comment them out one by one as in
>> `# #+latex_header:'.
>>
>
Hello,
Andreas Leha writes:
> If there are `#+latex_header:' entries in a section and that section is
> `COMMENT'ed out, I'd expect the #+latex_header entries to be
> uneffective. As they are when I comment them out one by one as in
> `# #+latex_header:'.
>
> Is this a bug? (I'd say, yes)
Hi Rasmus,
Rasmus writes:
> Andreas Leha writes:
>
>> Hi Rasmus,
>>
>> Rasmus writes:
>>> Andreas Leha writes:
>>>
Hi all,
If there are `#+latex_header:' entries in a section and that section is
`COMMENT'ed out, I'd expect the #+latex_header entries to be
uneffective.
Andreas Leha writes:
> Hi Rasmus,
>
> Rasmus writes:
>> Andreas Leha writes:
>>
>>> Hi all,
>>>
>>> If there are `#+latex_header:' entries in a section and that section is
>>> `COMMENT'ed out, I'd expect the #+latex_header entries to be
>>> uneffective. As they are when I comment them out one
Rasmus wrote:
> Andreas Leha writes:
>>
>> If there are `#+latex_header:' entries in a section and that section is
>> `COMMENT'ed out, I'd expect the #+latex_header entries to be
>> uneffective. As they are when I comment them out one by one as in
>> `# #+latex_header:'.
>>
>> Is this a bug? (I'd
Hi Rasmus,
Rasmus writes:
> Andreas Leha writes:
>
>> Hi all,
>>
>> If there are `#+latex_header:' entries in a section and that section is
>> `COMMENT'ed out, I'd expect the #+latex_header entries to be
>> uneffective. As they are when I comment them out one by one as in
>> `# #+latex_header:'
Andreas Leha writes:
> Hi all,
>
> If there are `#+latex_header:' entries in a section and that section is
> `COMMENT'ed out, I'd expect the #+latex_header entries to be
> uneffective. As they are when I comment them out one by one as in
> `# #+latex_header:'.
>
> Is this a bug? (I'd say, yes...
Hi all,
If there are `#+latex_header:' entries in a section and that section is
`COMMENT'ed out, I'd expect the #+latex_header entries to be
uneffective. As they are when I comment them out one by one as in
`# #+latex_header:'.
Is this a bug? (I'd say, yes)
Regards,
Andreas
PS:
ECM
--8<
21 matches
Mail list logo