emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [feature request] tangle on org-special-edit
@ 2011-07-21 13:38 Dirk Scharff
  2011-07-21 17:19 ` Eric Schulte
  0 siblings, 1 reply; 5+ messages in thread
From: Dirk Scharff @ 2011-07-21 13:38 UTC (permalink / raw)
  To: emacs-orgmode

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

best regards,
Dirk.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [feature request] tangle on org-special-edit
  2011-07-21 13:38 [feature request] tangle on org-special-edit Dirk Scharff
@ 2011-07-21 17:19 ` Eric Schulte
  2011-07-21 18:55   ` Dirk Scharff
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Schulte @ 2011-07-21 17:19 UTC (permalink / raw)
  To: Dirk Scharff; +Cc: emacs-orgmode

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

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [feature request] tangle on org-special-edit
  2011-07-21 17:19 ` Eric Schulte
@ 2011-07-21 18:55   ` Dirk Scharff
  2011-07-21 19:10     ` Eric Schulte
  0 siblings, 1 reply; 5+ messages in thread
From: Dirk Scharff @ 2011-07-21 18:55 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 4901 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [feature request] tangle on org-special-edit
  2011-07-21 18:55   ` Dirk Scharff
@ 2011-07-21 19:10     ` Eric Schulte
  0 siblings, 0 replies; 5+ messages in thread
From: Eric Schulte @ 2011-07-21 19:10 UTC (permalink / raw)
  To: Dirk Scharff; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 51 bytes --]

Hi Dirk,

Using the simple attached Org-mode file,

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: something.org --]
[-- Type: text/x-org, Size: 133 bytes --]

#+source: def-something
#+begin_src sh
  SOMETHING=nothing
#+end_src

#+begin_src sh
  <<def-something>>
  echo $SOMETHING
#+end_src

[-- Attachment #3: Type: text/plain, Size: 5159 bytes --]


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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [feature request] tangle on org-special-edit
       [not found] <A675877D-AA91-43CB-9F33-10B92F4A4701@googlemail.com>
@ 2011-07-21 20:53 ` Dirk Scharff
  0 siblings, 0 replies; 5+ messages in thread
From: Dirk Scharff @ 2011-07-21 20:53 UTC (permalink / raw)
  To: Org mailing list

[-- Attachment #1: Type: text/plain, Size: 6885 bytes --]

Sorry, I forgot to forward this Mail to the list. 

regards,
Dirk.

Anfang der weitergeleiteten E-Mail:

> Von: Dirk Scharff <dirk.scharff@googlemail.com>
> Betreff: Re: [O] [feature request] tangle on org-special-edit
> Datum: 21. Juli 2011 22:32:13 MESZ
> An: Eric Schulte <schulte.eric@gmail.com>
> 
> Hi Eric,
> 
> playing with your file I found out that setting :noweb to yes does the trick. It doesn't work here without setting it. It was set to tangle in the file I tested this with, which seemed the problem. Thank you for helping me with this. I still got problems with :vars on exporting, but I'll answer to the other mail for this to not mix the threads up. 
> 
> As for the detangeling part: Its theoretically impossible to do that without comments. There is no reliable way to tell which block is which (after it was edited) without some sort of reference in the file. Some sort of probabilistic method could yield somewhat useable results but I'd go for determinism (with comments) here. 
> 
> Am 21.07.2011 um 21:10 schrieb Eric Schulte:
> 
>> Hi Dirk,
>> 
>> Using the simple attached Org-mode file,
>> #+source: def-something
>> #+begin_src sh
>> SOMETHING=nothing
>> #+end_src
>> 
>> #+begin_src sh
>> <<def-something>>
>> echo $SOMETHING
>> #+end_src
>> 
>> 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/
> 


[-- Attachment #2: Type: text/html, Size: 19108 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-07-21 20:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-21 13:38 [feature request] tangle on org-special-edit Dirk Scharff
2011-07-21 17:19 ` Eric Schulte
2011-07-21 18:55   ` Dirk Scharff
2011-07-21 19:10     ` Eric Schulte
     [not found] <A675877D-AA91-43CB-9F33-10B92F4A4701@googlemail.com>
2011-07-21 20:53 ` Dirk Scharff

Code repositories for project(s) associated with this 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).