From: Eric Schulte <eric.schulte@gmx.com>
To: Yu <yu_icq@gmx.at>
Cc: org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: Syntax error warnings? (Especially important with :noweb-ref's)
Date: Mon, 23 Jan 2012 11:04:31 -0700 [thread overview]
Message-ID: <8739b6s34c.fsf@gmx.com> (raw)
In-Reply-To: CANtbJLHS2koEYV_pATKNVcgWNdH9dnPJxKkjt36wfHZVv=RSUQ@mail.gmail.com
Have you tried using the `org-babel-noweb-error-langs' variable that I
mentioned previously? It should help in these situations.
Yu <yu_icq@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.schulte@gmx.com>:
>> Yu <yu_icq@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/
next prev parent reply other threads:[~2012-01-23 18:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 21:38 Syntax error warnings? (Especially important with :noweb-ref's) Yu
2012-01-14 17:49 ` Eric Schulte
2012-01-21 15:21 ` Yu
2012-01-23 18:04 ` Eric Schulte [this message]
[not found] ` <CANtbJLEo-Bb3erMVRivdQYa=au81ExDJdSYRbQzXqx9F5V=VVw@mail.gmail.com>
[not found] ` <87ehuphy7a.fsf@gmx.com>
[not found] ` <CANtbJLH65=-mhZO0U0Snys=4xEDxL1mFm4JR+Gy7RDHFBTGsgw@mail.gmail.com>
[not found] ` <87sjixyx7m.fsf@gmx.com>
2012-01-30 17:59 ` Yu
2012-01-31 1:10 ` Eric Schulte
2012-01-22 21:25 ` Sebastien Vauban
2012-01-23 18:07 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8739b6s34c.fsf@gmx.com \
--to=eric.schulte@gmx.com \
--cc=emacs-orgmode@gnu.org \
--cc=yu_icq@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).