emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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/

  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).