Re: noweb syntax clashing with shell here document syntax

2021-03-23 Thread Sebastian Miele
Hi Immanuel,

Immanuel Litzroth  writes:

> You can choose which delimiters signal noweb.
> see the documentation of org-babel-noweb-wrap-start and
> org-babel-noweb-wrap-end.

Thank you!  That indeed should make my problem solvable in a perfect
way.

Best wishes
Sebastian



Re: noweb syntax clashing with shell here document syntax

2021-03-22 Thread Immanuel Litzroth
You can choose which delimiters signal noweb.
see the documentation of org-babel-noweb-wrap-start and
org-babel-noweb-wrap-end.
Immanuel

On Mon, Mar 22, 2021 at 5:35 PM Sebastian Miele
 wrote:
>
> Hello!
>
> The noweb syntax seems to clash with the syntax of here documents in
> shell scripts.  In the block like
>
> #+BEGIN_SRC shell :noweb yes
>   echo a
>   <>
>   echo b
> #+END_SRC
>
> everything following the line with the the noweb reference does not
> get fontified properly.  I suspect that the problem already is known
> for a long time.  Is that true?  If yes, what is the status of this
> issue?  Is there a known workaround?
>
> At least in ZSH it may very well be the case that a line ending with
> '>>' never is valid, except in cases where something like an '< before it is not an opening of a here document.  So it possibly is
> something that could be fixed in sh-script.el.  But I do not know
> exactly.
>
> Anybody who already knows more about this?
>
> Best wishes
> Sebastian
>


-- 
-- Researching the dual problem of finding the function that has a
given point as fixpoint.



noweb syntax clashing with shell here document syntax

2021-03-22 Thread Sebastian Miele
Hello!

The noweb syntax seems to clash with the syntax of here documents in
shell scripts.  In the block like

#+BEGIN_SRC shell :noweb yes
  echo a
  <>
  echo b
#+END_SRC

everything following the line with the the noweb reference does not
get fontified properly.  I suspect that the problem already is known
for a long time.  Is that true?  If yes, what is the status of this
issue?  Is there a known workaround?

At least in ZSH it may very well be the case that a line ending with
'>>' never is valid, except in cases where something like an '<