Re: [O] Syntax error warnings? (Especially important with :noweb-ref's)

[Eric Schulte]

Have you tried using the `org-babel-noweb-error-langs' variable that I
mentioned previously?  It should help in these situations.

Yu <address@hidden> writes:

> Hello again!
>
> I thought about the *noweb* part again. I tried the following:
>
> ======================================
> #+begin_src sh :tangle test.out :noweb tangle
>   <<task1>>
>   cat << test.org >> test.out2
> #+end_src
> #+begin_src sh :noweb-ref task1
>   echo "hello world"
> #+end_src
> ======================================
>
> The tangled output file "test.out" looked like this:
> ======================================
> /bin/sh
>
> echo "hello world"
> cat  test.out2
> ======================================
>
> i.e. the syntactically valid "<< test.org >>" construct was omitted.
> Thus a separate syntax for forcing a literal "<<" in the tangled
> output is needed anyway (if not yet implemented) and if so, warning
> about undefined code blocks should be possible too.
>
> The big relevance of warning about undefined and never used code
> blocks struck me, when recently I tried to use it again. The natural
> work flow to me would have been to write something like
>
>  : The task at hand has an overall structure
>  : #+begin_src python :tangle foo.py :noweb tangle
>  :   <<read the data>>
>  :   <<generate derived information>>
>  :   <<output the results>>
>  : #+end_src
>
> When proceeding after this however I would have to keep in mind open
> tasks or (slightly better) to instantly create TODO sections for said
> blocks. However, having this order of working imposed on me sort of
> defeats the purpose for my understanding. I'd rather prefer to do an
> `M-x org-babel-tangle' tell me, that I forgot to implement one of the
> partial tasks, rather than having to find out missing code blocks from
> the output file (where, as mentioned, they result in "nothing" rather
> than an unresolved "<<...>>" construct).
>
> kind regards, Yu
>
>
>
> 2012/1/14 Eric Schulte <address@hidden>:
>> Yu <address@hidden> writes:
>>
>>> Hello!
>>>
>>> I was wondering, if there is a way to get warnings for typos (e.g.
>>> when specifying invalid properties or header arguments). It can just
>>> easily happen that I mix up e.g. ":exports" and ":export" (though
>>> that's probably a very harmless example).
>>>
>>
>> While there is currently no way to do this there are two related
>> functions which should help.
>>
>> ,----[org-babel-view-src-block-info] bound to C-c C-v I
>> | org-babel-view-src-block-info is an interactive Lisp function in
>> | `ob.el'.
>> |
>> | (org-babel-view-src-block-info)
>> |
>> | Display information on the current source block.
>> | This includes header arguments, language and name, and is largely
>> | a window into the `org-babel-get-src-block-info' function.
>> `----
>>
>> and
>>
>> ,----[org-babel-check-src-block] bound to C-c C-v c
>> | org-babel-check-src-block is an interactive Lisp function in `ob.el'.
>> |
>> | (org-babel-check-src-block)
>> |
>> | Check for misspelled header arguments in the current code block.
>> `----
>>
>> This problem is not trivial because new language are permitted to create
>> and use *any* header arguments they like, so there are no /wrong/ header
>> arguments, there are only /suspicious/ header arguments (like the
>> :exports option you suggest).  The above function reports any suspicious
>> header arguments.  Perhaps there would be a way to integrate the above
>> function with flyspell for automatic highlighting of suspicious header
>> arguments.  I'll put looking into such integration on my long-term Org
>> task queue.
>>
>>>
>>> More important it gets though, when trying to use the literate
>>> programming facilities.
>>>
>>> Say I have a source code
>>>
>>> #+begin_src sh :noweb tangle :tangle foo.sh
>>>   <<foo>>
>>> #+end_src
>>> #+begin_src sh :noweb-ref fo
>>>   echo '... how are you?';
>>> #+end_src
>>>
>>> then tangling would run through without any indication of the typo in
>>> the name of the "foo" block. Such errors might be hard to debug,
>>> because there is no indication of the error, maybe nothing other than
>>> runtime errors.
>>>
>>> An error message for the /use/ of undefined references only wouldn't
>>> avoid such problems either, e.g. consider
>>>
>>> #+begin_src sh :noweb tangle :tangle foo.sh
>>>   <<foo>>
>>> #+end_src
>>> #+begin_src sh :noweb-ref foo
>>>   echo 'Hello World...';
>>> #+end_src
>>> #+begin_src sh :noweb-ref fo
>>>   echo 'Hello World...';
>>> #+end_src
>>>
>>> where the only detectable error is, that "fo" was never used anywhere.
>>>
>>> A similiar question (though without the second part) was asked here:
>>> http://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg00273.html
>>> As far as I can tell, it stands unanswered.
>>>
>>
>> Yes, although in many languages constructs like <<foo>> are valid code,
>> so it would be inappropriate for tangling to raise errors by default.
>> It is possible to turn on such errors on a language-by-language basis,
>> by customizing the following variable.
>>
>> ,----[org-babel-noweb-error-langs]
>> | org-babel-noweb-error-langs is a variable defined in `ob.el'.
>> | Its value is nil
>> |
>> | Documentation:
>> | Languages for which Babel will raise literate programming errors.
>> | List of languages for which errors should be raised when the
>> | source code block satisfying a noweb reference in this language
>> | can not be resolved.
>> `----
>>
>>>
>>> On a side note: What is the customary way to mention the
>>> noweb-relevant name of a source block in the html/pdf export? After
>>> all, if a code-block states
>>>     : <<task1>>
>>>     : <<task2>>
>>> the reader needs to know, which code blocks define these.
>>>
>>
>> Currently there is no automated support for this, so you should simply
>> name code blocks manually, however this topic has been raised recently
>> in another thread and there does seem to be interest for automated
>> support.
>>
>> Best,
>>
>>>
>>>
>>> kind regards, Yu
>>>
>>
>> --
>> Eric Schulte
>> http://cs.unm.edu/~eschulte/
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/