From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yu Subject: Re: Syntax error warnings? (Especially important with :noweb-ref's) Date: Mon, 30 Jan 2012 18:59:31 +0100 Message-ID: References: <87sjji5g3e.fsf@gmx.com> <8739b6s34c.fsf@gmx.com> <87ehuphy7a.fsf@gmx.com> <87sjixyx7m.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:45105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrvWX-0006oX-M9 for emacs-orgmode@gnu.org; Mon, 30 Jan 2012 13:00:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrvWQ-0002Lr-PV for emacs-orgmode@gnu.org; Mon, 30 Jan 2012 13:00:13 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:50709) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RrvWQ-0002HH-AP for emacs-orgmode@gnu.org; Mon, 30 Jan 2012 13:00:06 -0500 Received: by lagj5 with SMTP id j5so710785lag.0 for ; Mon, 30 Jan 2012 10:00:01 -0800 (PST) In-Reply-To: <87sjixyx7m.fsf@gmx.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte , org-mode mailing list 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 bloc= ks. - 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 : > Yu writes: > >> I tried my test file just again with a fresh pull from git: >> >> : =C2=A0`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. >> >> =3D=3D test.org =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> #+begin_src emacs-lisp :tangle test.out :noweb tangle >> =C2=A0 (progn >> =C2=A0 =C2=A0 <> >> =C2=A0 =C2=A0 <> >> =C2=A0 =C2=A0 (setq << 1 >> 2) >> =C2=A0 =C2=A0 (setq <> 1) >> =C2=A0 ) >> #+end_src >> #+begin_src emacs-lisp :noweb-ref task1 :noweb tangle >> =C2=A0 (princ "Hallo Welt!\n") >> #+end_src >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> exports to >> =3D=3D test.out =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> (progn >> =C2=A0 (princ "Hallo Welt!\n") >> >> =C2=A0 (setq << 1 >> 2) >> =C2=A0 (setq =C2=A01) >> ) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> still without any error message. >> > > When I add emacs-lisp to the `org-babel-noweb-error-langs' variable then > errors are raised for both <> and <>. > > #+BEGIN_SRC emacs-lisp > =C2=A0(add-to-list 'org-babel-noweb-error-langs "emacs-lisp") > #+END_SRC > >> >> As for the (here pretty artificial) case of "<>", 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. =C2=A0The example used in the email = was > the utf8 symbols =C2=AB and =C2=BB 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 >> "<>" 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 "<>", which >> would be a quite obvious cause of failure. >> >> kind regards, Yu >> >> >> 2012/1/24 Eric Schulte : >>> Yu 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. =C2=A0I've just pushed up a fi= x for >>> two issues. >>> >>> 1. noweb reference names (e.g., that which is between the <<>>s) must >>> =C2=A0 both start and end with non-whitespace characters >>> >>> 2. some of my recent changes broke the error reporting behavior >>> =C2=A0 associated with `org-babel-noweb-error-langs', I've fixed this >>> =C2=A0 behavior. >>> >>> Please do let me know if you continue to experience any problems. >>> >>> Best, >>> >>>> >>>> 2012/1/23 Eric Schulte : >>>>> Have you tried using the `org-babel-noweb-error-langs' variable that = I >>>>> mentioned previously? =C2=A0It should help in these situations. >>>>> >>>>> Yu writes: >>>>> >>>>>> Hello again! >>>>>> >>>>>> I thought about the *noweb* part again. I tried the following: >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> #+begin_src sh :tangle test.out :noweb tangle >>>>>> =C2=A0 <> >>>>>> =C2=A0 cat << test.org >> test.out2 >>>>>> #+end_src >>>>>> #+begin_src sh :noweb-ref task1 >>>>>> =C2=A0 echo "hello world" >>>>>> #+end_src >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>> The tangled output file "test.out" looked like this: >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> /bin/sh >>>>>> >>>>>> echo "hello world" >>>>>> cat =C2=A0test.out2 >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>> 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 >>>>>> >>>>>> =C2=A0: The task at hand has an overall structure >>>>>> =C2=A0: #+begin_src python :tangle foo.py :noweb tangle >>>>>> =C2=A0: =C2=A0 <> >>>>>> =C2=A0: =C2=A0 <> >>>>>> =C2=A0: =C2=A0 <> >>>>>> =C2=A0: #+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 sai= d >>>>>> 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 th= e >>>>>> partial tasks, rather than having to find out missing code blocks fr= om >>>>>> the output file (where, as mentioned, they result in "nothing" rathe= r >>>>>> than an unresolved "<<...>>" construct). >>>>>> >>>>>> kind regards, Yu >>>>>> >>>>>> >>>>>> >>>>>> 2012/1/14 Eric Schulte : >>>>>>> Yu 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 ju= st >>>>>>>> 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 c= reate >>>>>>> and use *any* header arguments they like, so there are no /wrong/ h= eader >>>>>>> arguments, there are only /suspicious/ header arguments (like the >>>>>>> :exports option you suggest). =C2=A0The above function reports any = suspicious >>>>>>> header arguments. =C2=A0Perhaps there would be a way to integrate t= he above >>>>>>> function with flyspell for automatic highlighting of suspicious hea= der >>>>>>> arguments. =C2=A0I'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 >>>>>>>> =C2=A0 <> >>>>>>>> #+end_src >>>>>>>> #+begin_src sh :noweb-ref fo >>>>>>>> =C2=A0 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 t= han >>>>>>>> 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 >>>>>>>> =C2=A0 <> >>>>>>>> #+end_src >>>>>>>> #+begin_src sh :noweb-ref foo >>>>>>>> =C2=A0 echo 'Hello World...'; >>>>>>>> #+end_src >>>>>>>> #+begin_src sh :noweb-ref fo >>>>>>>> =C2=A0 echo 'Hello World...'; >>>>>>>> #+end_src >>>>>>>> >>>>>>>> where the only detectable error is, that "fo" was never used anywh= ere. >>>>>>>> >>>>>>>> A similiar question (though without the second part) was asked her= e: >>>>>>>> http://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg00273.h= tml >>>>>>>> As far as I can tell, it stands unanswered. >>>>>>>> >>>>>>> >>>>>>> Yes, although in many languages constructs like <> are valid c= ode, >>>>>>> so it would be inappropriate for tangling to raise errors by defaul= t. >>>>>>> It is possible to turn on such errors on a language-by-language bas= is, >>>>>>> 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? Afte= r >>>>>>>> all, if a code-block states >>>>>>>> =C2=A0 =C2=A0 : <> >>>>>>>> =C2=A0 =C2=A0 : <> >>>>>>>> the reader needs to know, which code blocks define these. >>>>>>>> >>>>>>> >>>>>>> Currently there is no automated support for this, so you should sim= ply >>>>>>> name code blocks manually, however this topic has been raised recen= tly >>>>>>> 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/