When I call C-c C-v ' in the second code block I get a buffer containing

--8<---------------cut here---------------start------------->8---
<<def-something>>
echo $SOMETHING
--8<---------------cut here---------------end--------------->8---

but when I call C-c C-v v in the second code block I get a buffer
containing

--8<---------------cut here---------------start------------->8---
SOMETHING=nothing
echo $SOMETHING
--8<---------------cut here---------------end--------------->8---

with the noweb reference expanded.  I would suggest making sure you are
on the latest version of Org-mode, and if you still don't get this
behavior then I would recommend starting emacs with the -Q option to see
if part of your config is changing this behavior.

I agree with your points below, I think the main complication is
introduced when the restriction to work w/o comments is added (to allow
working with non-lp/org users).  The main limiting factor right now is
simply developer time to implement and test the debugging behavior
you've described below.  You may want to try the existing
org-babel-detangle function, as (if you don't have nested blocks) it
should be sufficient to be useful in your current situation.

Best -- Eric

Dirk Scharff <dirk.scharff@googlemail.com> writes:

> On Thu, Jul 21, 2011 at 7:19 PM, Eric Schulte <schulte.eric@gmail.com>wrote:
>
>> Dirk Scharff <dirk.scharff@googlemail.com> writes:
>>
>> > Hello,
>> >
>> > Org-mode provides the function to edit code blocks in their languages
>> > native environment. If you want do literate programming you'll end up
>> > with web-syntax (<<the-block-to-be-included-here>> ) in the
>> > environment org-special-edit started.
>> >
>> > I'd like to purpose, that before opening the special language
>> > environment, the code-block should be tangled to a temporary
>> > file. Then a buffer should be stated with that file loaded in its
>> > native language environment. If you'd do that the code would really be
>> > executable and therefore debuggable and analyzable with the tools the
>> > programming language provides.
>> >
>> > You'll have to keep track on the tangled code blocks then. I think
>> > some info in comments should do the trick. I uploaded a mockup of what
>> > I mean here: http://dl.getdropbox.com/u/3503145/org-feature-mockup.pdf
>> >
>>
>> Hi Dirk,
>>
>> If you would like to pop to a code block *with* the noweb references
>> expanded try the `org-babel-expand-src-block' command, which is bound to
>> "C-c C-v v".  This view of code blocks is not editable however because
>> there would be no way to propagate edits back into the original code
>> blocks -- consider an edit taking placed on the boundary between two
>> code blocks, or multiple nested noweb references.
>>
>> There has been some interest in propagating changes back from tangled
>> code to Org-mode blocks (search these list archives for the term
>> "detangle") however such functionality is currently not implemented --
>> an `org-babel-detangle' function does exist but is not fully functional.
>>
>> Best -- Eric
>
>
> Hi Eric,
> thanks for your answer.
>
> org-babel-expand-src-block doesn't seem to work for me (it does the same as
> C-c ' in my case). The noweb references are not expanded. Could be a local
> problem here, I don't know. Have you tried it recently? Tangeling the file
> works fine.
>
> I didn't search the List for detangleing for now. I'll look into it later.
> But I'll still drop my thoughts on it:
>
> I'm well aware of the "detangleing problems" you point out. But if you know
> you are not to edit between boundaries of two code blocks and still do it
> its your own fault right? Well not even that, its just not defined how
> org-mode should handle it right now. As for nested code blocks I don't see a
> problem at all. Consider the following (already tangled) file with block
> markers:
>
> !!mark_begin_outer_block_1
> do something here
> !!mark_end_outer_block_1
>
> << you shouldn't edit here! (but it could be a new block added to the org
> file if you do couldn't it?) >>
>
> !!mark_begin_outer_block_2
>   do something in the outer block
>   edit something here
>   !!mark_begin_inner_block
>     do something in the inner block
>     edit inner block
>   !!mark_end_inner_block
>   do something else
> !!mark_end_outer_block_2
>
> From the theoretical point of view I don't see an issue here besides the
> region I marked with "<< you shouldn't edit here! >>". I guess you could
> even tell emacs to protect the !!marks against modification if you wanted.
>
> If I had knowledge in Lisp programming and time I'd consider giving it a
> shot. But as I'm writing my thesis in the moment (and time is of the
> essence) my "hobby-programming-time" is very limited.
>
> I requested the feature because I think C-c ' isn't as useful as it could be
> right now. (And of cause I could realy make great use of this for my thesis
> writing ;)).
>
> Its still useful to me but I have to tangle the code to debug it and
> "detangle" the changes manualy, what pretty much defeats the purpose in my
> opinion.
>
> regards,
> Dirk.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/