Hello!
Thanks for the reply. The problem was, that I assumed the list
`org-babel-noweb-error-langs' to require the same form as
`org-babel-load-languages', i.e. something like
: ( (latex . t) (python . t) (sh . t) )
I didn't expect it to require a plain list of strings.
Now, that this misunderstanding is cleared though, the next problem
becomes visible: The common workflow I excepted is:
1. Define an overall structure of the task.
2. Run org-babel-tangle
3. If there are no errors: Finished.
Else:
- Choose the next block to implement from the list of unresolved blocks.
- Rerun from "1."
In the current implementation, the first unresolved code block stops
at the `error' statement.
Idea
------------
Instead of throwing an error, just a warning should be given. A simple
implementation could be replacing, in ob.el,
`org-babel-expand-noweb-references',
(error "%s" (concat
(org-babel-noweb-wrap source-name)
"could not be resolved (see "
"`org-babel-noweb-error-langs')"))
by
(progn
(lwarn 'tangle :warning "%s"
(concat (org-babel-noweb-wrap source-name)
" could not be resolved (see "
"`org-babel-noweb-error-langs')"))
"")
(the (progn-wrapping) is needed to ensure the enclosing if statement
returns a string as expected by `split-string').
The solution has the weakness though, that the warning buffer doesn't
show up automatically (due to the save-excursion I assume, so probably
the warnings should be thrown in one go /after/ the save excursion and
be collected into a list until then. (Multiple advantages:
`add-to-list' can take care of multipli occuring warnings and a single
warning is more clear by far then several warnings).
king regards, Yu
2012/1/30 Eric Schulte <eric.schu...@gmx.com>:
> Yu <yu_...@gmx.at> writes:
>
>> I tried my test file just again with a fresh pull from git:
>>
>> : `cat << file1 >> file2'
>> now expands as expected, but otherwise I don't see a change. Because I
>> thought, well, maybe it's language specific, I made a new example.
>>
>> == test.org ==================================
>> #+begin_src emacs-lisp :tangle test.out :noweb tangle
>> (progn
>> <<task1>>
>> <<task2>>
>> (setq << 1 >> 2)
>> (setq <<symbol>> 1)
>> )
>> #+end_src
>> #+begin_src emacs-lisp :noweb-ref task1 :noweb tangle
>> (princ "Hallo Welt!\n")
>> #+end_src
>> ============================================
>>
>> exports to
>> == test.out ==================================
>>
>> (progn
>> (princ "Hallo Welt!\n")
>>
>> (setq << 1 >> 2)
>> (setq 1)
>> )
>> ==========================================
>>
>> still without any error message.
>>
>
> When I add emacs-lisp to the `org-babel-noweb-error-langs' variable then
> errors are raised for both <<task2>> and <<symbol>>.
>
> #+BEGIN_SRC emacs-lisp
> (add-to-list 'org-babel-noweb-error-langs "emacs-lisp")
> #+END_SRC
>
>>
>> As for the (here pretty artificial) case of "<<symbol>>", I suppose
>> avoiding that problem would require being able to suppress the special
>> meaning of the construct, which would render the source less readable,
>> so I guess one will just want to avoid this clash (e.g. inserting the
>> spaces in shell scripts before/after the filename in a "cmd << EOF >>
>> target" construct, so here your solution is certainly sufficient for
>> all but very exotic cases :-)
>>
>
> Also, see the recent emails on list in which the ability to set custom
> alternatives for << and >> we added. The example used in the email was
> the utf8 symbols « and » which should not occur in code.
>
> Best,
>
>>
>> ---- Suggestion ----
>> For cases, where a corresponding code block is not found: It would
>> probably help in debugging and prevent compilers/interpreters from
>> ignoring the missing code, if instead of an empty string, the
>> "<<foo>>" construct itself was inserted, i.e. effectively not expanded
>> at all. E.g. my sample code would result in the lisp interpreter
>> trying to get the value for an undefined variable "<<task2>>", which
>> would be a quite obvious cause of failure.
>>
>> kind regards, Yu
>>
>>
>> 2012/1/24 Eric Schulte <eric.schu...@gmx.com>:
>>> Yu <yu_...@gmx.at> writes:
>>>
>>>> Actually, I set `org-babel-noweb-error-langs' to be the same as
>>>> `org-babel-load-languages' (forgot to mention that). Specifically it
>>>> contains
>>>> By the way, I retested it again today with the latest version from
>>>> git. Still the same result.
>>>>
>>>
>>> OK, Thanks for your persistence on this. I've just pushed up a fix for
>>> two issues.
>>>
>>> 1. noweb reference names (e.g., that which is between the <<>>s) must
>>> both start and end with non-whitespace characters
>>>
>>> 2. some of my recent changes broke the error reporting behavior
>>> associated with `org-babel-noweb-error-langs', I've fixed this
>>> behavior.
>>>
>>> Please do let me know if you continue to experience any problems.
>>>
>>> Best,
>>>
>>>>
>>>> 2012/1/23 Eric Schulte <eric.schu...@gmx.com>:
>>>>> Have you tried using the `org-babel-noweb-error-langs' variable that I
>>>>> mentioned previously? It should help in these situations.
>>>>>
>>>>> Yu <yu_...@gmx.at> 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 <eric.schu...@gmx.com>:
>>>>>>> Yu <yu_...@gmx.at> 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/
>>>
>>> --
>>> Eric Schulte
>>> http://cs.unm.edu/~eschulte/
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
