From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Literate Programming - Continue a Source Block? Date: Wed, 08 Jun 2011 13:40:16 -0600 Message-ID: <87mxhsnmcf.fsf@gmail.com> References: <87pqmokh6d.fsf@fester.com> <80k4cw22uf.fsf@somewhere.org> <87fwnkjqoh.fsf@fester.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:49374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUOc6-0003JP-1J for emacs-orgmode@gnu.org; Wed, 08 Jun 2011 15:40:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QUOc3-000599-O7 for emacs-orgmode@gnu.org; Wed, 08 Jun 2011 15:40:25 -0400 Received: from mail-pv0-f169.google.com ([74.125.83.169]:58758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUOc2-00058b-V4 for emacs-orgmode@gnu.org; Wed, 08 Jun 2011 15:40:23 -0400 Received: by pvc12 with SMTP id 12so488223pvc.0 for ; Wed, 08 Jun 2011 12:40:21 -0700 (PDT) In-Reply-To: <87fwnkjqoh.fsf@fester.com> (Neeum Zawan's message of "Wed, 08 Jun 2011 08:20:14 -0700") 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: Neeum Zawan Cc: emacs-orgmode@gnu.org > > The above is somewhat artificial, but in a proper programming project > something like this will occur frequently: A new feature will be added > at some later point and I'll want to update various blocks of code. > Currently the best method is that suggested previously/below of using named references in the target code block, as suggested below. While it shouldn't be overly difficult to add the behavior your described with something like a ":noweb-append" header argument, e.g., #+begin_src emacs-lisp :noweb-append visual-config ... #+end_src This behavior is not currently implemented. > >> Second solution: create one sole block that will be tangled, and which >> contains your other blocks (using the <> syntax), in the order you want. > > I had thought of this, but I find it somewhat lacking. Consider my > example above. I could have created a <> in my > <> block. However: > > 1. That requires me to know I'm going to need it later when I write > visual-config. > nit picking here, but while this does require a small edit to <>, there is no need for prior knowledge of the need for <>. > > 2. If I didn't know I'd need it, I'd have to continually modify various > parts of the org document every time I add a new feature to my code. I > find this suboptimal and error prone. > Technically only one edit per new block introduced, which does not seem overly onerous. > > 3. For me, one of the main motivations to do LP is to document the > evolution of the project, such that someone else can read the document > and understand. Part of this is that I want all aspects of a single > feature to appear under a single heading. When the reader reads the > document, he shouldn't have to see too many aspects of the code early on > that will be explained much later in the document. > I agree, this is a motivating example. > > Now the original noweb allows what I'm asking for. If you begin a > source block with a name of an existing block but append an "=" > symbol, it knows to append to that source block. > > It would be great if org-mode could add that capability. I agree, and the functionality you describe shouldn't be overly difficult to implement. I like the concision of the "=original-name" syntax used by noweb, but I would lean towards the use of a ":noweb-append" type header argument as suggested above because currently the names of blocks in Babel carry no semantic content and I'd prefer to leave it this way. > Another approach is that if multiple source blocks with the same name > are found, the default behavior is to concatenate all those source > blocks together (and then add a header option for overwrite if the > user wanted to overwrite instead of append). > > Thoughts? > Thanks for the motivating example and the thorough explanation of behavior. I'll certainly put this on my long-term development queue, however, that does not guarantee an implementation in the near future. If anyone is interested in this functionality and is up for writing some elisp I am happy to offer advice and code pointers immediately. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/