From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric H. Neilsen, Jr." Subject: Re: A tool for creating source code files from example and src blocks in org files Date: Wed, 03 Jun 2009 08:27:15 -0500 Message-ID: <4A267A33.6080908@fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBqV0-0007Ob-7z for emacs-orgmode@gnu.org; Wed, 03 Jun 2009 09:27:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBqUv-0007Nz-Dl for emacs-orgmode@gnu.org; Wed, 03 Jun 2009 09:27:21 -0400 Received: from [199.232.76.173] (port=43455 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBqUv-0007Nw-8G for emacs-orgmode@gnu.org; Wed, 03 Jun 2009 09:27:17 -0400 Received: from mailgw2.fnal.gov ([131.225.111.12]:48887) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBqUu-00051L-Vb for emacs-orgmode@gnu.org; Wed, 03 Jun 2009 09:27:17 -0400 Received: from mailav1.fnal.gov (mailav1.fnal.gov [131.225.111.18]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KKO006U201BKS@mailgw2.fnal.gov> for emacs-orgmode@gnu.org; Wed, 03 Jun 2009 08:27:16 -0500 (CDT) Received: from mailgw2.fnal.gov ([131.225.111.12]) by mailav1.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009060308271631395 for ; Wed, 03 Jun 2009 08:27:16 -0500 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KKN00A01ZTD8Y@mailgw2.fnal.gov> (original mail from neilsen@fnal.gov) for emacs-orgmode@gnu.org; Wed, 03 Jun 2009 08:27:16 -0500 (CDT) Received: from sdsslnx33.fnal.gov (sdsslnx33.fnal.gov [131.225.7.7]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTPSA id <0KKO00L0W01FJF@mailgw2.fnal.gov> for emacs-orgmode@gnu.org; Wed, 03 Jun 2009 08:27:16 -0500 (CDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Chris, Yes, I am also unhappy with the use of numbering to order chunks, but the traditional LP mechanism of using substitution of named chunks has some major flaws I have not figured out how to address. The basic problem is that it can be used as a mechanism for code reuse, probably will be if it is present. This is not necessary (code reuse like this probably means poor use of the code reuse mechanisms of the programming language in any case), hides the fact that the code is reused from debugging and performance tools that rely on the source code, and makes the task of untangling much harder, and impossible to completely automate. Consider a program in which the same chunk appears twice in the tangled source code. Using a debugger, you find a bug in the chunk. You fix it in the source code, but only in one place. You then find another bug, or even the same bug in a different guise, and fix it differently in the other appearance. What is the untangler supposed to do with the result? Which new version do you want? Do you want the changes merged? Do you actually want both versions, and if so, how does it edit the org-mode document to include them? Yes, I know, from an LP purists point of view, the untangler is an abomination. Unfortunately, few (if any) code development tools (debuggers, performance analyzers, etc.) support debugging or analysis of source code embedded in CWEB, noweb, or org-mode text files. This, to me, is a deal-breaker. With an untangle command, I can write my code in an org-mode file, tangle it and get emacs buffers with all C, headers, makefiles, java, or whatever code in it, use emacs's extensive code development tools (eg the emacs front end to gdb) to build and debug it, and pull the source code back into the org-mode file when the bugs are fixed. In fact, the code development tools do not even need to be embedded in emacs; anything tools can look at a traditional source file becomes useful. There is an additional problem, although one that can be solved by "just doing more work." At present, org-tangle can use the existing org-mode export code to do all necessary weaving. org-mode, in turn, takes advantage of the many independently supported modes for each language to format them properly. If we introduce a new syntax (for substitution) inside the literal blocks, it means that we will need an org-weave that can properly format each language. I am not sure how practical this is; I am certainly not that ambitious. It may be a little while before my itself makes an appearance. Not only do I need to wait for my employer to figure the legal stuff, I have also received enough feedback that I want to address issues better before anyone else is tempted to use the code. -Eric -- Eric H. Neilsen, Jr. http://home.fnal.gov/~neilsen