From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Genovese Subject: Re: Four issues with org-babel-tangle Date: Fri, 16 Sep 2011 00:31:58 -0400 Message-ID: References: <87litphkf9.fsf@gmail.com> <87k4998nx5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec53961807de4fa04ad077a17 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:35150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Q69-0000QM-R7 for emacs-orgmode@gnu.org; Fri, 16 Sep 2011 00:32:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Q68-0001So-51 for emacs-orgmode@gnu.org; Fri, 16 Sep 2011 00:32:21 -0400 Received: from mail-yi0-f41.google.com ([209.85.218.41]:49368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Q67-0001Si-Qm for emacs-orgmode@gnu.org; Fri, 16 Sep 2011 00:32:20 -0400 Received: by yia25 with SMTP id 25so2456080yia.0 for ; Thu, 15 Sep 2011 21:32:19 -0700 (PDT) In-Reply-To: <87k4998nx5.fsf@gmail.com> 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: emacs-orgmode@gnu.org --bcaec53961807de4fa04ad077a17 Content-Type: text/plain; charset=ISO-8859-1 > I'll write up this change as it may end up being longer than 10 lines, > and if I write it we don't have to wait for your FSF assignment to clear > (which can sometimes take months) before applying the patch. That sounds good, thanks. > In fact... if this attached patch looks good to you (i.e., allows the > behavior you originally intended) then please let me know and I'll apply > it immediately. Ideally, I'd like to combine the customizable processing with the simple fix code (which eliminates the two related bugs and the extra *s). Something like the following in place of the corresponding section in the patch you sent. The extra (match-end 0) and (point-min)'s prevent those problems. Otherwise, it all looks great. + (funcall + org-babel-process-comment-text + (buffer-substring + (max (condition-case nil + (save-excursion + (org-back-to-heading t) ; sets match data + (match-end 0)) + (error (point-min))) + (save-excursion + (if (re-search-backward + org-babel-src-block-regexp nil t) + (match-end 0) + (point-min)))) + (point))))) I'm happy to take a look at the patch again anytime. > Hmm, but #+tangle is not an official Org-mode directive in the same way > that #+source:, #+headers:, and #+call: are. Unless I'm forgetting > something #+tangle: lines would have no functional effect, in which case > why not just use a normal org-mode comment (e.g., a line starting with > "# "). You're right, I agree. I'm just being particular about indentation. I don't like to have a line starting with # when everything else is indented. And I don't like having to put a space after the #+ to prevent export, so I just wanted #+tangle (or #+noop or #+comment or whatever) to count as a non-exported comment too, just like #+ tangle would. But I can see that it's not worth the effort or the confusion with a functional directive that it would cause. I'll just suck it up and use the extra space. Thanks again, Eric. Best, Christopher On Thu, Sep 15, 2011 at 18:02, Eric Schulte wrote: > - Show quoted text - > Christopher Genovese writes: > > > Hi Eric, > > > > Thanks for your note. > > > >> I would encourage you to begin the FSF assignment process if > >> you anticipate potentially contributing more fixes in the > >> future. Could you please send a git format-patch version of > >> the simple fix to the list so that I might apply it? > > > > I will begin the FSF assignment process, and I will send a git-format > > patch based on the simple fix. (I'll send that tonight.) > > > > Fantastic. > > > > >> I like the idea of introducing a customizable function for > >> comment text transformation, however ... rather perhaps we > >> should just leave the default value of this function as > >> simple as possible and allow users to customize it .... > > > > That makes sense, and I like the way you did it. In particular, > > I absolutely agree that the org-babel-trim should be removed > > from org-babel-spec-to-string (to allow flexibility in the > customization). > > Making it the default processor works well, I think. > > > > Would you like me to submit a separate patch based on this change > > or should I include that as part of the patch with the simple fix? > > > > I'll write up this change as it may end up being longer than 10 lines, > and if I write it we don't have to wait for your FSF assignment to clear > (which can sometimes take months) before applying the patch. > > In fact... if this attached patch looks good to you (i.e., allows the > behavior you originally intended) then please let me know and I'll apply > it immediately. > > > > > > >> Finally I'm not sure I fully understand what you mean by ... > > > > Sorry, I wasn't clear. It's a small thing. If you put > > '#+tangle' in column 0, the line is not exported because it > > begins with #; if you put #+ tangle on a line (spaces > > after + and possibly before #), the line is not exported > > because it begins with #+; but if you put #+tangle (no > > spaces after the + but spaces before the #), the line is > > exported. I think it would be useful if something like > > #+tangle's (with no spaces between the # and +) were > > *not* exported because such lines can support > > useful customizations. Having to put the spaces after the + > > is a bit bothersome and looks uglier to me. > > > > Hmm, but #+tangle is not an official Org-mode directive in the same way > that #+source:, #+headers:, and #+call: are. Unless I'm forgetting > something #+tange: lines would have no functional effect, in which case > why not just use a normal org-mode comment (e.g., a line starting with > "# "). > > > > > >> ..., it was a long email. > > > > Yeah, sorry. :) Thanks for slogging through. > > > > no problem at all, didn't mean this as a complaint :) > > Cheers -- Eric > > > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/ > > --bcaec53961807de4fa04ad077a17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I'll write up this change as it may end up being= longer than 10 lines,
> and if I write it we don't have to wait = for your FSF assignment to clear
> (which can sometimes take months) = before applying the patch.

That sounds good, thanks.

> In fact..= . if this attached patch looks good to you (i.e., allows the
> behavior you originally intended) then please let me know and I'll= apply
> it immediately.

Ideally, I'd like to combine the customizable processing with the
si= mple fix code (which eliminates the two related bugs and the
extra *s).= =A0 Something like the following in place of the corresponding
section i= n the patch you sent.=A0 The extra (match-end 0) and (point-min)'s
prevent those problems. Otherwise, it all looks great.

+=A0=A0=A0=A0= =A0=A0 (funcall
+=A0=A0=A0=A0=A0=A0=A0 org-babel-process-comment-text
+=A0=A0=A0=A0=A0=A0=A0 (buffer-substring
+=A0=A0=A0= =A0=A0=A0=A0=A0 (max (condition-case nil
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 (save-excursion
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (org-back-to-hea= ding t)=A0=A0=A0 ; sets match data
+=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (match-end 0))
+=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (error (point-min)))
+=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 (save-excursion
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 (if (re-search-backward
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 org-babel-src= -block-regexp nil t)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 (match-end 0)
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (point-min))))
+=A0=A0=A0=A0=A0=A0=A0=A0 (point)))))
I'm happy to take a look at the patch again anytime.

> Hmm, but #+tangle is not an official Org-mode directive in the sam= e way
> that #+source:, #+headers:, and #+call: are. =A0Unless I'= m forgetting
> something #+tangle: lines would have no functional eff= ect, in which case
> why not just use a normal org-mode comment (e.g., a line starting with=
> "# ").

You're right, I agree. I'm just be= ing particular about indentation.
I don't like to have a line start= ing with # when everything else is indented.
And I don't like having to put a space after the #+ to prevent export, = so I
just wanted #+tangle (or #+noop or #+comment or whatever) to count =
as a non-exported comment too, just like #+ tangle would.=A0 But I can = see
that it's not worth the effort or the confusion with a functional direc= tive that
it would cause. I'll just suck it up and use the extra spa= ce.

Thanks again, Eric.

=A0=A0 Best,

=A0=A0=A0=A0 Chri= stopher


On Thu, Sep 15, 2= 011 at 18:02, Eric Schulte <schulte.eric@gmail.com> wro= te:
=
- Show quoted text -
Christopher Genovese <genovese.cr@gmail.com> writes:

> Hi Eric,
>
> =A0 =A0Thanks for your note.
>
>> I would encourage you to begin the FSF assignment process if
>> you anticipate potentially contributing more fixes in the
>> future. Could you please send a git format-patch version of
>> the simple fix to the list so that I might apply it?
>
> =A0 =A0I will begin the FSF assignment process, and I will send a git-= format
> patch based on the simple fix. (I'll send that tonight.)
>

Fantastic.

>
>> I like the idea of introducing a customizable function for
>> comment text transformation, however ... rather perhaps we
>> should just leave the default value of this function as
>> simple as possible and allow users to customize it ....
>
> =A0 =A0That makes sense, and I like the way you did it. In particular,=
> I absolutely agree that the org-babel-trim should be removed
> from org-babel-spec-to-string (to allow flexibility in the customizati= on).
> Making it the default processor works well, I think.
>
> =A0 =A0Would you like me to submit a separate patch based on this chan= ge
> or should I include that as part of the patch with the simple fix?
>

I'll write up this change as it may end up being longer than 10 l= ines,
and if I write it we don't have to wait for your FSF assignment to clea= r
(which can sometimes take months) before applying the patch.

In fact... if this attached patch looks good to you (i.e., allows the
behavior you originally intended) then please let me know and I'll appl= y
it immediately.



>
>> Finally I'm not sure I fully understand what you mean by ... >
> Sorry, I wasn't clear. It's a small thing. If you put
> '#+tangle' in column 0, the line is not exported because it > begins with #; if you put #+ tangle on a line (spaces
> after + and possibly before #), the line is not exported
> because it begins with #+; but if you put #+tangle (no
> spaces after the + but spaces before the #), the line is
> exported. I think it would be useful if something like
> =A0#+tangle's (with no spaces between the # and +) were
> *not* exported because such lines can support
> useful customizations. Having to put the spaces after the +
> is a bit bothersome and looks uglier to me.
>

Hmm, but #+tangle is not an official Org-mode directive in the same way
that #+source:, #+headers:, and #+call: are. =A0Unless I'm forgetting something #+tange: lines would have no functional effect, in which case
why not just use a normal org-mode comment (e.g., a line starting with
"# ").


>
>> ..., it was a long email.
>
> Yeah, sorry. :) Thanks for slogging through.
>

no problem at all, didn't mean this as a complaint :)

Cheers -- Eric



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

--bcaec53961807de4fa04ad077a17--