Tom,
>I just checked and it induces a syntax error, which I did not know,
> but turns out to be quite useful because it means that an untangled or
> incorrectly tangled file will fail to run beyond that point. Best!
:) cheers.
Hi Greg,
I just checked and it induces a syntax error, which I did not know,
but turns out to be quite useful because it means that an untangled or
incorrectly tangled file will fail to run beyond that point. Best!
Tom
On Sun, May 2, 2021 at 9:11 PM Greg Minshall wrote:
>
> Tom, that is quite
Tom, that is quite devious, actually. thank you very much! do you
know, by the way, what flycheck and/or the shell make the "<<&"
construct out to be? cheers, Greg
Hi Greg,
A slightly different suggestion that doesn't break other org
processors (which might not allow users to change
org-babel-noweb-wrap- values) is to prefix the names of the blocks
with & (e.g. <<&block-to-noweb-in>>) as I do in multiple places in
https://github.com/tgbugs/pyontutils/blob
Diego and Sébastien,
thank you both. in particular, i didn't know about
=org-babel-noweb-wrap-start=, and that's probably perfect for this
case.
cheers, Greg
Hi Greg,
Greg Minshall writes:
is there an obvious thing to do to either get whatever syntax checker is
running to ignore the <> reference, or some such?
From the org side of things, you could customize the variables
`org-babel-noweb-wrap-start` and `org-babel-noweb-wrap-end` to
something that
I don't think there's an easy way to fix this - since src blocks are
fontified using the mode for the corresponding language. Particularly in
shell script, since << has a meaning in the language ("here" input), I
assume this is why the rest of the block gets fontified differently.
Best,
--Diego
hi, all.
using a <> reference in a bash source block, the buffer's font
lock colors go south on lines folowing the <> reference. (in my
case, all remaining lines in the buffer are colored bright yellow). the
major and minor modes are as listed below.
is there an obvious thing to do to either ge
