From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Scharff Subject: Re: [feature request] tangle on org-special-edit Date: Thu, 21 Jul 2011 22:53:35 +0200 Message-ID: References: Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_42D6D651-5603-43CD-BAAC-0008F6D9449C" Return-path: Received: from eggs.gnu.org ([140.186.70.92]:41241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qk0Fc-0000aD-5y for emacs-orgmode@gnu.org; Thu, 21 Jul 2011 16:53:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qk0Fa-00018k-Bv for emacs-orgmode@gnu.org; Thu, 21 Jul 2011 16:53:44 -0400 Received: from mail-fx0-f52.google.com ([209.85.161.52]:47017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qk0FZ-00018f-QQ for emacs-orgmode@gnu.org; Thu, 21 Jul 2011 16:53:42 -0400 Received: by fxd18 with SMTP id 18so3335273fxd.39 for ; Thu, 21 Jul 2011 13:53:41 -0700 (PDT) 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: Org mailing list --Apple-Mail=_42D6D651-5603-43CD-BAAC-0008F6D9449C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry, I forgot to forward this Mail to the list.=20 regards, Dirk. Anfang der weitergeleiteten E-Mail: > Von: Dirk Scharff > Betreff: Re: [O] [feature request] tangle on org-special-edit > Datum: 21. Juli 2011 22:32:13 MESZ > An: Eric Schulte >=20 > Hi Eric, >=20 > 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.=20 >=20 > 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.=20 >=20 > Am 21.07.2011 um 21:10 schrieb Eric Schulte: >=20 >> Hi Dirk, >>=20 >> Using the simple attached Org-mode file, >> #+source: def-something >> #+begin_src sh >> SOMETHING=3Dnothing >> #+end_src >>=20 >> #+begin_src sh >> <> >> echo $SOMETHING >> #+end_src >>=20 >> When I call C-c C-v ' in the second code block I get a buffer = containing >>=20 >> --8<---------------cut here---------------start------------->8--- >> <> >> echo $SOMETHING >> --8<---------------cut here---------------end--------------->8--- >>=20 >> but when I call C-c C-v v in the second code block I get a buffer >> containing >>=20 >> --8<---------------cut here---------------start------------->8--- >> SOMETHING=3Dnothing >> echo $SOMETHING >> --8<---------------cut here---------------end--------------->8--- >>=20 >> 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. >>=20 >> 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. >>=20 >> Best -- Eric >>=20 >> Dirk Scharff writes: >>=20 >>> On Thu, Jul 21, 2011 at 7:19 PM, Eric Schulte = wrote: >>>=20 >>>> Dirk Scharff writes: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> 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 (<> ) in the >>>>> environment org-special-edit started. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>>>=20 >>>>=20 >>>> Hi Dirk, >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Best -- Eric >>>=20 >>>=20 >>> Hi Eric, >>> thanks for your answer. >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> 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: >>>=20 >>> !!mark_begin_outer_block_1 >>> do something here >>> !!mark_end_outer_block_1 >>>=20 >>> << you shouldn't edit here! (but it could be a new block added to = the org >>> file if you do couldn't it?) >> >>>=20 >>> !!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 >>>=20 >>> =46rom 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. >>>=20 >>> 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. >>>=20 >>> 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 ;)). >>>=20 >>> 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. >>>=20 >>> regards, >>> Dirk. >>=20 >> --=20 >> Eric Schulte >> http://cs.unm.edu/~eschulte/ >=20 --Apple-Mail=_42D6D651-5603-43CD-BAAC-0008F6D9449C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Von: Dirk Scharff <dirk.scharff@googlemail.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=3Dnothing
#+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=3Dnothing
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

=46rom 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/
=


= --Apple-Mail=_42D6D651-5603-43CD-BAAC-0008F6D9449C--